Lime is a testing tool bundled with symfony. It can be, however, used separately with any PHP application.
It is a great alternative for famous PHPUnit. Its advantage is simplicity. Since writing tests with lime is dead easy it’s a perfect choice for unit testing newbies.
What makes lime so powerful is that almost no effort is needed to create a new test. You just open a new file, initialize lime_test object and you’re ready to start writing your tests.
Note: file included in the first line initializes symfony related libraries (like autoloader). If you want to use lime without symfony you should replace this line with simple require statements. You’ll need to include lime and other classes used in test.
Reigning the Chaos
Lime approach is simple and quick to start with. Unfortunately, it becomes hard to maintain in big projects.
As the number of tests grows test files become complicated and unclear. Splitting them into several smaller files isn’t a big improvement. Besides, too often helper functions are needed to make tests more readable and avoid code repetition.
Object oriented approach solves the problem in a better way.
$this->isa_ok($test,'string','::stripText() returns a string');
$test->cmp_ok($text,'===','lorem-lipsum','::stripText() replaces spaces with a dash');
What I did was group tests as methods of a test class. Adding new test is as simple as creating a new method. Test cases are clearly separated and I gain power of object orientation.
Note: Lime 2, the next generation of Lime, will be far more sophisticated. Out of the box it’ll let you use neat annotations or test classes. For good introduction to Lime 2 read Best Practice Testing with Lime 2 by Bernhard Schussek.
Every public method which name starts with ‘test‘ is considered to be a test and is called by a run() method. You can see the full implementation on the next listing.
Every test should be run in a clean and separate environment. That’s why before each test setUp() is called. Most often I use it to load test data into the database. Respectively after each test tearDown() should clean things up.
Common initializations can be done in a constructor. Additional feature is added here. Since I’m annoyed by having to pass lime_output_color instance all the time to get results in color I made it a default behavior.
Good tests are the documentation
Giving descriptive and meaningful test method names is important for the reader. It helps to figure out what’s the purpose of a test case and catch the requirements. To support practice of appropriate naming a diagnostic message is created from the method name and printed out before each test.
The gyLimeTest class is a base test class in most of my projects. As it’s part of my test plugin I cannot put project specific methods there. What I usualy do is I introduce additional project test class. This way I can put common project methods and assertions in one place.
PHP development manager in GOYELLO, focusing on delivering high quality software with clean and easily maintainable code. Follows best programming practices and use the best Open Source solutions. Big fan of symfony framework.