thePHP.cc is a company offering an education flat rate for PHP developer. Because we are on a good basis with them, they offered us a free seat and we are very happy to have one.
The following blog post is the experience our junior developer Bruno Correia has so far.
As a junior software developer, I am excited to get involved in tasks that will demand a new skill set. I had no real life experience with test automation, so I was more than thrilled when I had the chance to collaborate with my first PHPUnit tests.
As part of major database import project that involved developers from our team and our client, I was assigned to work in tandem with a senior colleague, creating tests for an XMLReader and its Validator, using as a base some tests that were already included in the project. For the first part we did the work together, but as my colleague went on holidays I had to finish the task by myself. After a couple of days of copy, paste, edit & refactor, the task was accomplished and my branch was merged.
But truth be said: copying code and making it work was ok, but could I do it from 0? Data was being read correctly, expected exceptions were being thrown, but I still had no idea how to do implement PHPUnit test by myself.
It came in very good time that The PHP Consulting Company had a Test Automation with PHPUnit training course happening a couple of weeks ago. With sessions led by Sebastian Bergmann, creator of PHPUnit, they covered the basics of PHPUnit: installation, creating simple tests, using different types of assertions and data providers to avoid code repetition, working with dynamic tests and an overview of what types of data we want to work with in the tests (creating stubs or mock objects).
To my (pleasant) surprise, the PHPUnit documentation is very complete and explained step by step. Even so, having Sebastian’s instruction and hearing about the experience of other professionals is essential for a better understanding of how and which features to use.
In my eagerness to finish a task, I often get lost in looking at the whole and forget to focus on the basics. That’s why it was so important to hear the basics of test creation. The cornerstone of test implementation is that tests should document what the code can do, starting with the most basic things (e.g. checking whether $email corresponds to a valid email format or whether an array sorting method is arranging an array in the correct order).
As usual, when writing good code we should “avoid repetition”, but it was nice to hear from Sebastian the sometimes the DRY golden rule can (and should!) be broken if it means the test will be easier to read and understand.
Test code should not be DRY, nor wet. It should be damp.
Some of the tips I learned and will take to future PHPUnit implementations are the use attributes (that can be added to the XML configuration file or in the command line):
testdox– to be able to read which tests have been runcolor– which makes the command line interface much more pleasant to read
So that was it. There is still a long way to seniority. PHPUnit is in constant development, and so am I. Next step is learning how to configure PHPUnit to work inside PHPStorm, but that is a discussion for another day.