Blog

22
December 2013

Gavin Pickin

Unit Testing 01 - Setting up my Testing Environment to Test Unit Testing

Unit Testing

Getting Started with Unit Testing is my new Series to help myself, and you, get started with Unit Testing. I am definitely not an expert, but as I go through this process, I'll try and learn and share my experiences, so we can add to the number of ColdFusion and CFML developers using Unit Testing, like they should. Today is the first in the series, so its not that exciting, just mainly a lot of setup.

Ok, so I'm going to start doing some Unit Testing, and I'm going to test my unit testing, with my Test Environment. In english, I'm going to setup a play site, so I can walk through setting up a site with the sole purpose of creating Unit Tests, and I'll install TestBox and play with MxUnit Compatible tests, and some BDD (Behavior Driven Development) test style too.

Why did I choose TestBox? Like I mentioned in my last Unit Testing blog post, MxUnit is a great tool, and has been for some time, but due to commitments, changes in the community, and life, it is not currently an actively maintained project, although just to be clear it still works, and is not dead. Luis Majano from Ortus Solutions (the maker of ColdBox) has created TestBox as a way to extend MxUnit (includes backwards compatibility) and develop it further, and in version 1.0 (just released mid December 2013) it already supports MxUnit styled tests, and new BDD test styles. 

If you are an active member of the ColdFusion community, you will know of Sean Corfield, creator of Fw/1, the other big CFML Framework being used right now, has mentioned on Twitter he is already testing his MxUnit tests with it, and would like to see it succeed. Sean has been involved with almost everything in CFML's history that has been successful (IMHO). If he is willing to test it, give feedback, and try to help it success, I think that is a great sign. He tweeted today that he ran several hundred tests using TestBox and got them to pass, I'm eager to see how this plays out.

Long story short: If the 2 biggest CFML Framework creators are behind this, I have a strong feeling it will be successful, and pick up the torch where MxUnit left off.

Please note, no one means any disrespect to MxUnit, its a great tool, and it has served the community well and still does, the efforts every contributor gave it are greatly appreciated. It just seems like it is time for a new team to pick up where they left off, and continue the great legacy that MxUnit started and keep it evolving.

Ok, now lets get this moving. 

To make it easier to follow along, I'm going to make a Git Project, and try and break down my code into steps, so for each blog post, there might be several chunks. It will all be available on Github so you can pull it down, and see the code I write (I'm sure some of it will make you cringe), and run the tests locally. I am also going to setup a subdomain on my site, so you can actually run the tests on each chunk, on the live site, so you can see how the run, if you don't want to download and set them up on your machine.

Ok, so, for all of you out there, the Github repo is setup.
https://github.com/gpickin/Blog-UnitTesting-Series Star, Fork, Clone, Follow Me, all the GitHub actions you want.

As we work through this blog entry, we'll setup the overall structure, and get some code in place, and we'll be able to run a couple of basic tests, and make sure our setup is solid, before moving on.

This blog is blog01 in this series, so everything will be put in the blog01 folder, under the root. I am using a local url and dev server url making use of subdomains? Blog-UnitTesting-Series or buts for short. Appropriate because there can be no buts about it, we should all be unit testing.

Local will be
http://Blog-UnitTesting-Series.local.com
or http://buts.local.com

Dev Server will be (when I get it setup in the new few days)
http://buts.gpickin.com 

Now, we need to think about what should we be testing, everyone does a Calculator, because it is simple, and everyone understands the basics of a calculator, there are several functions, but really, that is almost too simple, so let me think about what might be a more interesting, and useful idea to test. Ok, so I decided we're going to build a little tool to help manage our websites, so we'll have a few objects, and we'll build on them as we go. 

So, first we'll make a couple of objects. We'll make a model folder to store our CFCs, this isn't going to be a big project, so we'll keep it pretty flat in nature. We're going to create the following cfcs.

model/Website.cfc
model/CFMLServer.cfc

Other files in the folder

Application.cfc
index.cfm

Ok? its very simple, lets download TestBox and get it installed. Adam Cameron has started blogging on this very topic, so he's ahead of us, you might want to check out his installation posts if mine are too simplistic. Adam has been doing Unit Testing for a lot longer than me, so mine will be the "dummies" version. 

Lets go to http://www.coldbox.org/download and we'll download TestBox V1.0.0 which is the current latest version. It was only released a couple of days ago, so we'll be part of the group Testing out the TestBox, kind of funny.

Unzip the file, and drop the TestBox directory from the zip into the Root. You can map it, but this is setup as its own site, for simplicity, so we'll drop it there. 

We're going to create a test folder, that will store all of our tests in it. Inside there, we'll create a few subfolders to put our different types of tests in.

integration - for our integration tests
unit - for our unit tests

Inside unit, we're going to add 2 unit tests, one for Website.cfc and one for CFMLServer.cfc
Inside Website.cfc we'll place the following code

component displayName="Website.cfc Unit Tests" {

// executes before all tests
function beforeTests() {}

// executes after all tests
function afterTests() {}

function testIncludes(){
          $assert.includes( "hello", "HE" );
          $assert.includes( [ "Monday", "Tuesday" ] , "monday" );
     }

}

Inside CFMLServer.cfc we'll place the following code

component displayName="CFMLServer.cfc Unit Tests" {

// executes before all tests
function beforeTests() {}

// executes after all tests
function afterTests() {}

function testIncludesWithCase(){
          $assert.includesWithCase( "hello", "he" );
          $assert.includesWithCase( [ "Monday", "Tuesday" ] , "Monday" );
     }

}

Now, you might wonder what those weird tests are? right now, they are just placeholders, a couple of Dummy Tests from the TestBox documentation, to test to make sure our Testing Environment is setup right.

Now, to run and display the results of these tests, we will add a little code to our index.cfm page, in the step we're in, Step1.

<cfset r = new testbox.system.testing.TestBox( directory="blog01.Step1.test.unit") >
<cfoutput>#r.run()#</cfoutput>

Now, what this code does it create a new TestBox runner, and we pass the directory of our Unit tests into the runner. The runner gets every CFC in the Unit Tests folder, and will run them all (unless we tell it otherwise). 

So now, we can go to our browser, and test our tests.

As you can see in the screenshot above, if we browse to Blog 01 - Step1 - you can see there was 2 Bundles Run. CFMLServer.cfc and Website.cfc. Each one had 1 test, our dummy test, and they both passed. Now, it looks like we're setup, so we can actually start TDD in building out Tests and Components out.

So I'll leave it there. I'll commit my changes, and post this. The dev server will be online soon with this, so you can follow along, until then? check out my github repo, and follow along.

Thanks for reading, tomorrow, we really dig deeper.

Gavin

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Blog Search