Unit testing is part of a developing trend that is becoming more and more important as the software becomes more and more complex. It is called test-driven development. It’s all about making sure that your software behaves as expected, and keep behaving as expected even after you modify it to introduce new functions, improve it, fix bugs etc. It’s frequent the case where a developer introduces a new feature in a plugin, and inadvertently breaks something else in doing this, and only when clients report the bug realizes that. Unit tests should help you avoid this situations.
I’m not really a fan of test-driven development done as described in the Wikipedia page linked above. There are in fact different schools of thought even here. According to the original test-driven dev process, you should write tests before you actually write the code. Personally I prefer the other way around but anyway the important thing is to write tests. I’ve started studying unit tests because lately I’ve been collaborating with the developers of the Inboundnow suite of plugins. That suite is becoming complex, and we need to make sure that the existing code base doesn’t go out of control while new features and improvements are introduced.
Despite the guides that I’ve followed (I will link all of them in the next articles) learning how to make unit tests work the way we wanted has been tough. I had to learn new tools and new technologies that I had never heard before. Forty days ago I didn’t even know that Travis CI existed. Today, it’s becoming part of my normal workflow.
Since this first article is an introduction I won’t go yet into the details of how to configure everything. What I need to do here is to clarify how I’ve decided to work with unit tests. I’ts probably not the only way to do it, maybe not the best but it’s the way it works for me.
First of all, you need to install your unit tests libraries locally on your pc. I have a Windows machine with a Bitnami WAMP installation but it doesn’t really matter what you have. I also installed an Ubuntu virtual machine with VMware to better learn, and unit tests worked perfectly even there. At the end I’ve decided to keep working with my local WAMP installation and abandon the Ubuntu virtual machine because it’s too resource heavy.
After you’ve installed all your unit test libraries you setup a local website that you’ll use exclusively to develp unit tests, and you’ll work on your PC to develop all the tests. Once the development of a test is completed, it can be moved to the main code and committed and pushed to Github.
When your local unit test environment works, you need to configure the remote unit test environment that will run under Travis CI. Travis CI is a service that allows you to run remote automated software tests on a number of languages. Every time an automated test must be executed Travis setup a virtual Linux machine, installs all the tools needed according to the configuration file, and runs the tests. After the tests are finished the virtual machine is deleted. It’s important that the configuration file instructs Travis CI correctly, or the tests will fail or won’t run at all.
When you push your code to Gihub (wheter it is a new test or a new feature) is when the magic begins. Travis CI keeps your Github code monitored, and as soon as it sees an update it downloads your code and automatically runs all the tests. All it’s automated, if everything goes well you won’t even know that the tests were run, if any tests fail then you’ll be notified via email.
The advantage of using a remote service for tests is that if you work in a team every developer can push code to Gihub and trigger tests automatically. If tests run only on your local machine instead…well, you probably get the point.