Skip to main content

Setting Up Testing for a Simple Math Function

This is part of a [short but hopefully growing] series on mocking.

There are a several presentations and articles about the need for testing and also how to set up up a framework like TestBox. I'll summarize:

Setup

1. Download and install CommandBox
2. Open CommandBox
3. Type "mkdir testproject  true" - this will create a folder called testproject and then move you into it.
4. Type "install testbox" - This will install TestBox.
5. Type "server start"  - This will open up a browser serving CFML from Lucee with the root of the site being the testproject folder.
6. Open up your development software and point it at this folder.

I created two folders
1. "testMods" to hold the CFCs and methods I wanted to test
2.. "tests" to hold the unit tests I was going to make.

The CFC which contained the methods to test was located at testMods.first.second.third.VanillaCFC.cfc

The folder which housed the tests was \tests\first\second\third\vanillaCFC\. I have no idea about best practices but it seems a good idea to me to house the tests in the same folder structure as the actual  methods for simple organizational purposes. Each CFC to test had a folder in the \tests\path and then the tests for that CFC went int that folder.

The last piece of setup was to copy the index.cfm page from the \testbox\test-browser folder into my \tests folder and change the rootmapping to my folder. That will let us browse to the test we want to run

<!--- SETUP THE ROOTS OF THE BROWSER RIGHT HERE --->
<cfset rootMapping     = "/tests">


Testing the Public Function

The method here is very simple. It accepts two number, multiplies them and returns the answer.

component accessors="true"{
    public function simpleMath(numeric numA, numeric numB){
       return numA * numB;
    }
}

This method is easy to test. It's self contained, publicly available, has a definitive answer which is a straightforward, simple variable.

Using CommandBox to create a skeleton of the tet for this method by navigating to \tests\first\second\third\vanillaCFC and typing

testbox create bdd simpleMath

We get a simple document which I then filled in with the beforeAll Content and then my tests:

/*** My BDD Test*/
component extends="testbox.system.BaseSpec"{
   
/*********************************** LIFE CYCLE Methods ***********************************/
   // executes before all suites+specs in the run() method   
    function beforeAll(){
      testobj=createObject("component","testmods.first.second.third.vanillaCFC");
      testme=testobj.simpleMath(8,9);
   }

   // executes after all suites+specs in the run() method   function afterAll(){
   }

/*********************************** BDD SUITES ***********************************/
   function run(){
   
      describe( "The simpleMath result should...", function(){
         
         it( "be a number", function(){
                expect( testme ).toBeTypeOf('numeric');
         });
         
         it( "be 72 given the inputs 8 and 9", function(){
                expect( testme ).toBe(72);
         });
         
      });
      
   }
   
}

Process and Result

This is about as simple as it gets for testing. In the beforeAll() function we use createObject to make an instance of the vanillaCFC called testObj and then we make a variable called testme which is teh result of the simpleMath(8,9). We then submit testme to some expectations, namely that it should be a number and that it should equal 72.

Good to go. On to the next challenge: Private methods!


Comments

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...

As the Dev Ops Manager, I need to start planning our CI/CD release process

Part of the CI/CD Development Series Once we have our Deployment Diagram designed, we need to figure out out to get from here to there. If the end point is the appropriate server environment, the starting point is the developer with his/her hand on the keyboard. These steps take place on a variety of machines, within various process and can changes based on what files are checked in or not. At the moment, we've only created the early basics as seen below. The Beginning of our Deployment Activity Chart Even though there is quite a long way to go there are some elements which we have already been determined. For example We have determined the broad strokes of our technology stack. This is going to be React on the front end and ColdFusion on the server side. We have determined that we are going to be using linting on both the CF and React paths. CFLint for the CF and ESLint for the Javascript We have determined that we are going to be formatters - CFFormat for CF and...

As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each one

Part of the CI/CD Development Series The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up ...