I've spent some sleepless nights and stressful days trying to understand why the latest versions of PHPUnit won't work anymore on any of our dev boxes. It almost drove me mad.
It was like chasing a ghost: you fix one thing, you think everything should now work, you try again, then: SBAM! Another error is bitch-slapping you some truth in your face. Iterate over a dozen times and you'll know how I felt. This was my state until I found about CodeCeption.
A brief overview on the state of things
This was a great thing, although I've never managed to do any functional tests, as at the time I started getting interested in them, I was more eager to work with Selenium WebDriver rather than the previous version (RC). Plugging Unit Tests into Jenkins was also a breeze using Apache Ant.
A friend named Trouble
Since version 3.7, PHPUnit started to change, aligning itself to the majority of other modern PHP projects, being distributed as a single
.phar file, and ready to be used with Composer.
This didn't sit too well with Yii, which meant several problems started to arise, first with the server configuration, especially with the outdated re-packaged sources available on many Linux distros together with PEAR - which was one of the main complaints that Composer will be addressing. Then with several other issues regarding Yii's and PHPUnit's autoloaders conflicting with each other.
An account of such experience can be found on the tickets I've opened not so long ago on PHPUnit's GitHub and on Yii's GitHub as well. According to samdark, Yii's core developer, this seems to be a problem on Yii side and will hopefully be fixed with the next public release of Yii 1, while at the same time Yii 2 is heading towards a public release, providing an almost radically different solution altogether.
At this time, another Yii developer, Ragazzo, got me interested into CodeCeption by casually commenting about how Yii2 would have been using it, solving many of the problems I - and I suppose others, were experiencing with Yii1.
Now I've worked a bit with CodeCeption, creating functional tests and refactoring some old unit tests within it, swearing a bit while trying to make Active Records and fixtures work as expected (I provide some basic steps in my slides/screencast below).
I've also had the opportunity to explore a bit further what will lie ahead of us, when Yii2 will be marked as stable. All this preliminary work is now ending with this article, after the presentation I've given during the Yii London Meetup of April.
If you don't care much, read on, as I'll try to briefly explain what CodeCeption is and what are its strengths.
CodeCeption tries to simplify and aggregate the process of writing tests, plugging different testing suites with the use of modules and giving the opportunity to anyone to extend it and improve it.
It covers three different types of tests, which are:
- Acceptance tests
- Functional tests
- Unit tests
On top of it, it defines and provides within the directory of each of the suites the - so called - Guys: these are the main objects you will be using for describing your tests, doing assertions and interacting with the testing interface provided. These are:
- WebGuy, used for Acceptance tests
- TestGuy, used for Functional tests
- CodeGuy, used for Unit tests.
CodeCeption provides commands for generating test code and get you started. The basic tests you can create for Functional and Acceptance are:
- CEPT tests, which are a plain, simple and highly-legible PHP file
- and CEST tests, which are instead using a class to wrap all tests, the way PHPUnit normally does, that should help you organise your tests better
While for Unit tests you have the choice between plain PHPUnit and CodeCeption-driven unit tests.
If you ever worked in a BDD or TDD environment, translating an acceptance criteria into code is straightforward:
$I = new WebGuy($scenario);
The above example has been extracted from CodeCeption documentation, and proves how easy it is by just reading it in plain english.
Nice things about CodeCeption
Long story short, CodeCeption has been designed with modularity and extensibility in mind, which is one of the best things in the short and long run.
As I said before it's also trying to create a common ground for all testing suites that can be used with it, doubling the simplicity and readability of its syntax.
There might be many other things worth mentioning, which I've briefly cited during my talk, but the above have been sufficient for now to convince me staying on it.
I don't know if integrating any other unit testing suite (e.g. JUnit, Jasmine, ...) would make any sense or it's out of its scope, but what you can do with it now is quite powerful and can easily solve a damn bunch of problems you might have without it.
For more info or if you want to discuss further, feel free to comment below.
Here are the slides with the embedded youtube video: