Hamcrest is a set of matchers for writing more expressive code. It just so happens that these matchers are especially useful when writing tests. In this article, we'll look at Hamcrest for PHP. [...] Hamcret's expressiveness originated with JMock, but it wasn't until the addition of the unique assertThat() method that it was refactored into a self-contained library and independently usable in testing frameworks.

He talks about the "generations" of unit testing tools, a division based on their assertion functionality - simple, exact or using matchers. Installation instructions via PEAR are included (though there's also a composer package for it too) as well as code for an example test. More samples are given for comparing things like numeric values, strings and setting up inclusions and exclusions with the anyOf/noneOf matchers.

One backslash sequence that doesn't get much attention is K. What this handy little assertion does is match the position of whatever string comes before it in the pattern, then it in essence resets the match. At that point it starts a new match with whatever comes after K from the current location in the subject string.

They include a series of PHP code examples showing how use can use it to work around some of the issues with lookbehind assertions. They also include a few benefits and drawbacks of using them over lookbehinds.

Over the last two years, I've seen a variety of duplicate issues come into the issue tracker, which stem from two fundamental flaws in Zend_Acl [...] In this article, we'll explore the API changes that alleviate these two problems, and we'll demonstrate how to leverage the Zend_Acl assertion system to create expressive, dynamic assertions that work with your applications models.

He mentions some of the backwards compatible changes that have been made to the ACL API including changes in the add() method and the ability to create Zend_Acl_Role and Zend_Acl_Resource objects explicitly. The rest of the post gives a great example of setting up users in a role, creating an action to test them against (can they work with a blog post?) and running a series of checks against the ACL component as a guest, contributor and publisher.

Pádraic maintains that one assertion per test is a rule that should always be followed unless there is a specific good reason to break it. I prefer it as a guideline, as does Robert C. Martin in the book Clean Code. The reference is not intended as an appeal to authority to "prove" that I'm right. I'm just making the point that I think this reflects the current state of the art, which is not necessarily perfect, of course.

Dagfinn talks about behavior-driven development and illustrates how a two assertions could be combined into one but that the end result "isn't very pretty" - and that's just testing two proterties of a single object. Imagine what would happen if things got more complex.

Obviously, a ratio of 1:1 would be perfect - but I'm sure we can accept some multiple assertions within a tolerance level. A ratio of more than 1.1:1 would indicate creeping obscurity (a signal it's time for me to intervene, refactor, and do some mutation testing for extra assurance). A ratio of 2:1 indicates a lost cause.

He notes that it probably sounds like a bad idea from the start, but he reinforces the suggestion with a bit of reasoning:

It's this notion of complexity that is often used to justify multiple assertions - if you break it down into the simple components that that complexity was built out of, multiple assertions don't have a leg to stand on (just the rare instances out of your control because they absolutely must be done).

You can see response that's been posted over on the PHP in Action blog in response to Padraic's thoughts.

In short, every test you write requires that you setup the test environment, create a scenario for possible failure, add an assertion, and then ensure the source code makes that assertion pass. This requires code - sometimes a lot of code. So adding multiple assertions to each test minimizes the work needed to write tests, since using multiple assertions takes advantage of existing code to avoid writing new stuff to clutter your test classes. It can also help to tackle multiple but related results in the same test.

He gives brief examples of both instances and some of the problems associated with them. Multiple assertions, while nice for fine tuning the results of the testing, can also confuse since, if one assertion fails, the whole test fails too. The other end of the spectrum is a problem too - writing tests that don't do enough to really check the information passed in. These shallow tests can lead to issues down the line if unanticipated data might come along.

Really, its all about finding that "sweet spot" in developing tests - not too much, not too little - and keeping it simple while not missing out on assertions that need to be made.

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 [of bad test code] and its retroactive effects with a huge antiperspirant flagon, while also providing the chance to build a customer friendly and domain related test vocabulary.

His first assertion is simple, checking the contents of a bag object to be sure that there are no duplicate items and that its content count is reduced by one if something is removed. Then, he moves on to making the custom assertion for his "IdShouldFollowAgreedConvention" test. He explains how to use the assertion class and how it all fits together in the final, functional test case.

I suddenly remembered what assertions are and how they could make my code more readable, while making it shorter. I took a quick look at PHP's assert function, but decided that I don't like it. [...] What I ended up doing was basically to create a class called Assert, and abuse it as a name-space for a whole bunch of useful assertion functions.

He includes two examples of how this new class would look, checking to see if a value is empty and to see if a task ID exists in a given value. The code for the assertion class is also included and has methods for checking things like "not empty", "equals to", "is not numeric" and "is an object". And, no, it's not CakePHP specific, so you could take it an use it anywhere.

I was recently working on a command line PHP tool, and didn't have easy access to our normal PHP unit testing framework built around SimpleTest. [...] I didn't need support for mock objects or complicated assertions - just a bare basic assertTrue() would do the trick.

He includes the code (of course) and an example of it in action, three tests with their assertions. It's a simple little tool made of a simple purpose, a starting place for developers just learning unit testing to learn from.