Start Integrated Testing by Gavin Pickin - CFMeetup #258 - Notes

Note: The following post is a rough draft of notes take after going through the presentation on Integrated Testing. It is likely one of a two part series, with the second part the experience of performing my first test. That will have to come later, however, as I have yet to write my first ColdBox App, a super top secret sports tracking application. :-)

Testbox Site:
Meetup Recording URL:

There are tons of types of testing, but - Unit Testing and Integration Testing are key topics of this presentation.

Unit Testing - testing behavior of individual objects (functions). Smallest testiable part of an application, (isEmailValid()) which is actually a very complicated approach. Kind of like irreducible complexity for an application. It has a lot of pros. Instantly know if something is broken - example: IsEmailValid is tested on .io emails before they are broken by a user. Also can expose high coupling, and you can identify it - high coupling is bad b/c you are relying on too much stuff - ie - if your function is calling 5 other functions.

Integration Testing - testing entire app from top - down (end to end)

UI Verification testing - visual elements

Important Testing Tools

Mocking Framework
Jenkins, Bamboo, Teamcity, other Cis
Jmeter or Webstress Tool, Apache AB

Testbox - Ortus took it over. Leverages BDD and is open source.


Test Driven Development - write the tests first. This seems really cool, and structured. I doubt you'd miss anything here. You only write stuff to pass tests. Old school but still very popular. Adds confidence and focuses on functionality.

BDD focuses more on behavior, and I like it better because of it's format, but TDD is sweet too. Again - either way - if the user gives me a valid email, I will get a valid result. 

Basically human readable tests, with BDD being a bit more readable than TDD. 

TDD example:

Test('email address must not be blank', function() { notEqual(email,"", "failed"); });

BDD Example

Describe ('email address', function(){ It('should not be blank', function(){ expect(email)not.toBe("")


BDD Matchers

expect(true).toBe(true); expect(true).toBe(true); expect(true).not.toBe(true);


Chau, Mocha are Node.js equivalents

BDD Examples are easier to read than TDD.

User stories look similar to New BDD examples. 

Installing Testbox - # box install testbox

Create a runner.cfm file to Run your tests which has a bunch of defaults. Include the html runner at the bottom.

TestBox HTML Output looks nice. It has totals for passes, failures, and errors. It's cool that there is FusionReactor integration. Cool readable understandable BDD tests.

Wow - you can change the reporter to json, and now you get all the data generated by testbox. You can have another app consume this. 

So you can of course run TestBox with CommandBox - another reason to run it.

Pretty neat termial right inside the console right insid VS Code at minute 30. 

You can set up multiple runners if you want. Anyway, you can even change the test on the fly and rerun it and you're set. Definitely want to run more than one monitor. 

So IntoTheBox has this training, which is cool. 

Today's demo is testing SoapBox - which is a clone of twitter - a demo site that is used for training. 

If you don't use ColdBox, don't freak. all CFCs go in the model folder. 

So what is our first test? What is the biggest bang for your buck? For me, it would be does the home page work, but maybe I'm thinking too broadly. The answer I give is the same as the first person to respond in the YouTube chat. Are we going with expect(true).toBe(false)? Gavin recommends for a first great test is to check to make sure cfcs compile. In this case, the Rant Service. Have this test for all CFCs to make sure that can compile. And you may be able to do this in a 1/2 hour. CFC is instantiated and can return a component.

A second test would be something like can all users be returned? Or put another way, can all users be listed? Not necessarily. This example is more of an integration test than a unit test. Surely, I need to learn more about the differences. Because here, we are testing the list function. 

So why Integration tests? Well, if we take the list example from above, we are testing many pieces (db, function, etc) are all working together successfully. Some of these tests can cover large amounts of your app. This is also helpful, or can be used with, user stories.

So if you test a registration process altogether, (perhaps that is a user story), that is integration testing. But the registration process contains individual components, such as can I pass a user name successfully, which are unit tests.

Unit tests are great, but if you have 200 features? So if you have no tests today, this is a best bang for your buck.

So when do you write a test to test code? As soon as you code it. You write some code, and you write a test for it.  It is at this point that I am starting to see the abilty for all devs to do this. 

A few good integration tests for logging in scripts were shown.

So Hyper is a cool tool for creating clients, and replaces cfhttp, and handles cookies, etc better. Before we get to that, though, I see the need for something like Jsoup or Integrated for client handling. It solves the cookie problem of having a user who logs in or who posts a comment to keep the user known without having to pass cookies manually.

Jsoup is a cool java library for html parsing, and so instead of doing difficult regex stuff, Jsoup can be used. You can install the Java library and leverage it. But Integrated...

Integrated is a TestBox package.  It is easier to read. And there are a ton of things to do with this, starting with filling out forms. Integrated works with ColdBox, but it also can work with other frameworks, includiing legacy apps, by adding an adapter

NonIntegratedTest.cfc is the name of the file exampled by Gavin. So how do you run this? 

Gavin opened up a web application which I think was Integrated, and copied and pasted the output into an html renderer that he Googled for which rendered the output in a more readable format. But then he went to VS Code and started running from the terminal using a plugin (likely commandbox). 

So now, if you are hooked into Continuous Integration, you are always protected. 

There are many real life examples for testing for which there is a slide. 

Tests are built and run before the image is built. 

The bottom line is we need to use Integrated 





Post a Comment

Required Field