6 Test Frameworks
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Introduction
So far I’ve used many frameworks for testing. Some that come to mind: SimpleTest, Lime, PHPUnit, Codeception, PHPSpec, Behat… Each has its own unique selling points and is probably easy to use, but do we really need so many test frameworks? Sure, every new framework introduces new ways of writing and structuring test code, but if it’s new and better ways that we’re looking for, one day we’ll certainly want to migrate do a different framework that offers even more revolutionary ways to write test code.
Many projects suffer from this urge to use multiple test frameworks over the years. In the beginning a project has only one framework for writing tests (e.g. PHPUnit with a setup for browser-like testing), then it adds another one (e.g. Behat for high-level scenario tests), and maybe even another one (e.g. PHPSpec for class tests). Eventually, one of these frameworks is going to become obsolete. The maintainer of CoolTest 2000 is going to give up on the project. They liked inventing a new framework, and indeed, it’s probably fascinating to do so, but at some point it becomes boring. Perhaps it wasn’t the maintainer that gave up, but the development team who didn’t like the framework anymore. Then the team has to adopt the next framework, which is going to do things in a completely different way.
The same is true for mocking libraries. If you use any number of mocks in your tests then you end up being invested in one particular mocking library, like Mockery, or PHPUnit mocks, or Prophecy. Unfortunately, when a new tool comes around, someone in the team wants to try it, or the team decides to switch but never takes the time to complete the migration. Now the project has two or three different mocking tools in use. All their related packages need to be updated regularly, and for (new) developers it’s unclear what mocking tool they should use.
My hypothesis is that a project ends up with different test frameworks and mocking libraries because:
- Writing tests can feel cumbersome, we want it to go faster, and be more fun, so we install new and cool tools that promise these things.
- Tests aren’t production code, so it feels like we can freely experiment with different approaches.
- A new tool is quickly installed and the enthusiasm is contagious, but no project manager is ever going to “give us time” to upgrade the old approach to the new one.
Use Only the Most Basic Features of a Test Framework
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Declare Test Dependencies Explicitly
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
PHPStan Rule: Don’t Allow PHPUnit Extensions
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
PHPStan Rule: Don’t Allow Class-level Set-up and Tear-down Functions
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Assertions
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Write Tests in Plain Code
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Handwritten Test Doubles
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
PHPStan Rule: Don’t Generate Mocks
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.
Conclusion
This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/recipes-for-decoupling.