Today i found a custom assertion that wasn't asserting quite what it ought to have been. It seems that this problem could have been avoided if i had written a unit test for the assertion itself. The only problem i see is that i'm not quite sure how to handle writing tests for an assertion that it ought to fail, without having that lead to the test itself failing. In other words, for a test that expects a string, 'foo', i want to do something like: of course, there is no asserttestfails assertion. But is there a clean way to do something like that? how can i write a custom assertion, like assertfoo $expected, $actual. That behaves like the built in assertions with respect to the error stack trace ? i currently have the following method defined within a class that extends phpunit_framework_testcase : if i call this from a test and the test fails, i get two items in the call stack: line 17 is where assertfoo calls the built in assertequals and fails line 136 is there assertfoo is called. If i change the test to call assertequals directly, i only get one: there's some documentation in the manual.

While developing php applications and applying developer testing the applications safety net will grow along the timeline, and as normal code, test code should be in a fresh, odour free state too. A common test code smell, amongst others, is the duplication of assertion logic which can reduce reusability, readability and thereby obscure the specific verification intention of tests. To subdue this special smell several patterns and refactorings are available to acquaint the test code with the dry principle. So in this blog post i'd like to set the focus on some of the aspects of the custom assertion pattern, by showing how to create custom phpunit assertions, which attacks the above mentioned smell and its retroactive effects with a huge antiperspirant flagon, while also providing the chance to build a customer friendly and domain related test vocabulary. The first introductive code snippet shows an example of unwanted code duplications and smells in a phpunit i.e. The first test code duplications smell is present when verifying that a given bag is having an expected item count and an explicit 'intent obscuration' smell can be spotted when verifying the bags stock id against an assumed convention via a 'distracting' regular expression.

mechanics of rolling custom assertions

the 'custom assertion' pattern can be applied from the very first test code creation activities, in sense of a prefactoring.

Or refactored towards by extracting the assert duplications and verification intention obscurations into tailormade and intent revealing named assertions. To define custom assertions are several approaches available, the first and easiest one is to define custom assertions merely for a single test class and make them private inline methods of this specific class by facading/wrapping the standard phpunit assertion. Another approach is to create/introduce an assert class to promote a cleaner reusability in other test case classes or scenarios, this approach might get chosen to collect and organize the evolving domain specific assertions.

Paying College Athletes Essay Research Paper

Other and more complex approaches would be the utilisation of phpunits' constraint feature which is available since release 3.0.0 or in the near future the use of the hamcrest test matcher features which might be available from phpunit 4.0.0. Either way the purpose specific assertions should further provide a default and convention conform assertion message, which will be raised on a verification failure, and also the feature to feed in a custom one to avoid gambling annoying assertion roulette rounds. A assert definition inside test case: b assert definition in assert class:

putting the custom assertions to work

now as the tailormade assertions are available all verification work can be delegated to them the same way it would be done with any of the standard phpunit assertions. In case the custom assertions are hosted in an 'assert class' they can be required_once or loaded via __autoload in the test setup, otherwise if they are defined inside the test case class itself they can be used like regular private methods of that class.

The last code extract illustrates the use of the prior outlined 'assert class' assertion for verifing the stock id format alongside the use of the 'inline' custom assertion for verifying the amount of items in a given bag.

adding value through a domain specific test vocabulary

as you might have noticed the readability and intention communication of the test code has been improved significantly from the introductive code snippet towards the last one. Furthermore by distilling a ubiquitous see domain driven design book by eric evans test language domain experts, which are mostly not fluent in the targeted programming language i.e. Php, are enabled to read test code and provide valuable feedback or contribute changes to test scenarios affecting their domain. Another common area where domain specific test vocabularies are used, by providing their own assertion and constraint sets, test case classes and additional test helpers.

Posted on feb 12th 2012 by matthias noback when you see yourself repeating a number of assertions in your unit tests, or you have to think hard each time you make some kind of assertion, it's time to create your own assertions, which wraps these complicated assertions into one single method call on your testcase class. In the example below, i will create a custom assertion which would recognize the following json string as a successful response: inside a testcase we could run the following lines of code to verify the successfulness of the given json response string: which means i convert the string i received into an array using json_decode . Then i check for a key named success and assert it's value is true which means, i am a successful response .