Part 1 of our guide on automating testing in Coldfusion and Railo with Testbox, Gulp, and Jenkins
A couple of years ago I sat down on a new travel project. In reality it was a ground-up re-write of an existing site. Ordinarily this would involve taking the existing code and working from there however as this was intended to be from first principles I decided to do away with that.
Unit testing had been on my radar a while and so when better to start using it than before your project has got a single line of code? I went ahead setting up some basic tests with MXUnit and got results (and failures) back in the browser. Happy days.
As the project progressed there became more and more tests. Now some of these tests take longer than a unit test really should, but that’s not my concern at the moment – all I want to see is that green light. So I set up the Eclipse MXUnit plugin to help me keep track of my unit tests en-masse in a way which doesn’t seem to care quite so much about my browser timing out. So far so good.
So now the project has progressed and there’s a few more people on the team. They have a variety of OS’s and the like, and without exception they have a dislike of Eclipse. I no longer blame them as have since moved onto Sublime. What options do I have for running these tests? I could just keep Eclipse around solely for unit testing. This is just what I have done for the last year. The hiccup here is when it came to trying to set up other developers environments, in particular when it became clear to me just how much persuasion my tests needed to run with Eclipse.
But hold up, what about automation? How about a nice little server that can beaver away with my tests and throw heavy objects at the unfortunate developers that cause a failure? Well that would be nice.
So I started out looking into Ant. This was a mistake. It does a lot, but getting it to do precisely what I wanted it to made my head spin. Couple this with the fact that MXUnit seems to have had some issues working just the way I was hoping and the fact that everyone is talking about Gulp and Grunt nowadays (and in no small part due to Adam Cameron urging me along this route) I decided to throw away Ant and MXUnit, and dive in to Gulp and Testbox.
I held onto Jenkins though. He just looks so helpful, it’d be like kicking a kitten in the face to throw him away too! (If only their site could be a little more stable)
The first problem that I hit though was simple, there seemed to be no go-to guide that detailed how to get all these things playing nicely together. I am sure that what I have done may not be the most efficient or optimal way to achieve my objective of being able to throw away Eclipse, however it has got me to a point where I can see my test results within Jenkins without the need for anything special installed on my client machine.
A simple guide for a basic integration of Testbox with Jenkins using Gulp will follow shortly in part 2 of this article.