During the Hacking Day on the Symfony Live conference I decided to give it a try and write some unit tests for Symfony2. I'm a big fan of TDD for quite some time already and I recently became really interested in BDD. For sure I'm not new to unit testing. Still, I didn't expect that writing tests for an existing piece of software can be so much fun.
What I also discovered is that writing unit tests for Symfony is a great way to learn its internals.
Contribute to Learn
The process of writing tests is no doubt a contribution. What's less obvious it's an occasion to learn as well.
Before we can even start with writing a test we need to dig into an existing ones to see how they're built. Reading the tests teaches us how classes and components should be used. This way we're learning the API.
Next we should analyze the class we plan to cover by tests. Doing this we're learning about Symfony internals quite extensively. We have to understand the code very well before writing anything.
The good part is we don't have to learn the whole framework at once. As it's pretty well structured and decoupled to components we can take a really small steps. Class after class. Component after component.
How to Start?
So, you want to contribute to an Open Source project? It's useful to learn some ground rules first.
Perfect starting point are the coding standards. It's good to speak the same language as other developers.
Next stop is the patches chapter of the Symfony Documentation. You'll learn how to work on your own fork of Symfony and make that your contributions are merged into the core. You'll also read about the tools needed in the process. If you're not familiar with git than I highly recommend reading the Pro Git book.
Finally, Running Symfony2 Tests will show you how to run the test suite and code coverage.
After reading these docs you should be able to fork the Symfony repository on github, clone it locally and run the tests:
phpunit
Code Coverage is our Friend
Code Coverage tells us what parts of the code base are covered by tests. We can generate a nice code coverage report in html with PHPUnit:
phpunit --coverage-html=cov
The report not only shows us which classes or methods are tested. We can also see which lines were invoked while running the tests (and how many times). This makes the report a perfect tool for finding parts of code which are not fully tested yet.
Unfortunately it won't show us if all the execution paths were run.
I also noticed that to get a real test coverage of a given component it's better to run the coverage report for that component only. It's because some components use other components. The fact that code is executed while running the test doesn't mean its behavior is verified.
