Iain Cambridge

Since Continuous Integration is awesome and I’m going be using Lithium a lot, it was clear I needed away to run my Lithium unit tests via Jenkins. Since I use Phing for builds on Jenkins and that Lithium uses it’s own testing framework there was only one solution. Build a phing task to run Lithium tests. So after a quick hacking session I completed a quick task that allows for the running of Lithium tests and fails the build if all of them don’t pass. You can find it on github at https://github.com/icambridge/phing_li3.

Install

To install is simple, just copy the directory into the directory you have your build file in.

Build File

The build file implementation is simple, you just defined a new task with taskdef, then you can just call the task, currently it only has two parameters both of which are required. 

li3Base : The location where you have the Lithium application.
tests : The namespace for the tests. It also allows for “all” to run all the tests that can be found.

Mock Request

Since the way Lithium finds the base path for the application we need to mock the Request and replace the _base() method. This will stop Lithium using the base location of Phing for the base location of the lithium app and prepending it to redirects.

Conclusion

Currently it’s a quick and rough way of running the tests, I don’t doubt as I need to do different things I’ll expand this task to allow me to achieve them. I’ll also improve the functionality of it as well.

You can download it at https://github.com/icambridge/phing_li3

At work we’re starting to use Lithium for our main product. So once I found out, the first thing I wanted to do was to find out how I could unit test with it. In some cases it makes life really easy in other cases it made it bitch. So here’s what I’ve figured out so far. If you know a better way please tell me.

Original Controller

This is a simple controller that just sets a view variable called test with “test” as it’s content.

Mocks

To unit test the controller I’ve found that you need to mock the controller to allow you to use the dependency injection ability to use a mock response class to stop the view from being outputted. Below I’ve included a basic starting point for the mock controller in which it changes the response to the mock response and I added a getter function to allow me to access internal variables such as the render.

Here is the mock response class which just disables the rendering of the page view.

So now we have a mock controller that we can run tests on that won’t output HTML on every test. Now I’ll create a simple test which it checks to see if the test view variable has been set.

Mocking models for use in a controller test is more difficult, it looks rather nasty as lithium’s models are called statically. While lithium does allow you to use a test connection with your tests it means you can’t just test the logic of the code without testing the database layer. While I do agree that you should also do tests with your database layer, I also think you should do tests without a database connection so as you can see what is failing, the data being inputted into the model or the database layer. So after some trying to do some namespace magic, I finally remembered you can call static classes from a variable string. So to use a mock model I decided use the lithium dependency injection system classes array and retrieve the class name from it.

Controller

Mock Controller

In the mock controller we just replace the articles class with our mock Article class.

Mock Model

Here is a very simple mock Article class which just replaces the find method and returns two sets of data. In reality you would want a much better find and replace the insert as well. Currently I haven’t done too much in mocking models I just wanted to be able to do, due to how nasty it seems we’ve went for just using Fixtures.

Fixtures

Now I’ve shown how to do the unpopular mocking of the model class, I’ll link you to the Lithium fixtures, instead of basically duplicating what the author of the fixture plugin has to say you may as well get it from the horses mouth here.

Conclusion

Lithium unit testing is pretty simple, although this is a rather simple run though, I hope to post other snippets about unit testing when I run into stuff I need to figure out. I am sure there is probably stuff I could be doing better, if you know anything please do alert me.