Ran into this xUnit test failure the other day:
Expected: Boolean [True, False, False]
Actual: SelectListIterator<Process, Boolean> [True, False, False]
Why the failure?
The values displayed for expected and actual match. The only difference visible in the error message are the collection types…but that can’t be the source of failure because xUnit’s
Assert.Equal<T>(IEnumerable<T> expected, IEnumerable<T> actual) doesn’t compare the collection types of its arguments, just elements and their positions.
So why the failure? Continue reading →
RSpec’s be true and be_true look deceptively similar. In fact, their naming suggests that they might be synonyms for the same assertion. Can the two clauses be used interchangeably to produce the same effect? No!
Both check trueness but from different perspectives. be true checks whether the compared-against value is true: “Does the value literally equal true?” be_true asserts that the test value evaluates to true: “Is the value truthy?” be false and be_false are the respective inverse match clauses. Continue reading →
Segmenting unit tests from release code by placing the tests in a separate assembly (e.g. in a separate Microsoft Visual Studio project) is a good idea. However, making release code classes public in order to allow the unit test assembly to access them isn’t a good practice. Continue reading →
If code written for Magento is executed outside of Magento—as occurs when running unit tests—Magento’s normal startup process (which registers its autoload functionality) is not run. Without the autoloader in place, the first time PHP encounters a request to initialize a class which it doesn’t recognize, it will error out with a “class not found” error. Also, without Magento’s startup process running, PHP doesn’t know about the Mage family of singleton methods (e.g. Mage::getModel(), Mage::helper()) which are commonly used to create class instances. Continue reading →