I'm a huge fan of both CommandBox and TestBox from OrtusSolutions and have become a believer in the usefulness of testing. That in and of itself has had it's benefits in making me a more analytical programmer, understanding flow better, forcing me to write shorter methods, etc.
However, for the life of me, I couldn't get to first base on mocking. Conceptually, I knew it was when something was pretending to be something else but I didn't even know enough to understand the documentation (which is more of statement about me than the docs). As a result, I've been using Testbox in a valuable but limited way by using it to run a function without having to go through an interface which may or may not exist yet. The problem is that I wasn't separating it from any other function, table, web call or process with which it interacts. This in an of itself is a valuable process but it's not really unit testing and with that statement comes the following dialogue which I've published somewhere else.
Glossing over the argument about unit testing, we're launching a new automatic build system at work so testing, and more importantly, testing that ran quickly, covered multiple scenarios and was not attached to a database or actually called web services was needed. This precipitated me actually putting keystrokes to concepts and figuring out how this mocking thing works.
It turns out to be much easier than I thought.
To figure out how this worked I wanted to set up a simple function but one with ever increasing complexity of architecture. By that I mean that ultimately all my function did was to accept two numbers and then return an answer but did so in different ways. The rules were that I had to submit the same two numbers and get an answer. I was using TestBox and it's built in partner, Mockbox. The test could only run the function being tested and all information needed to run that function had to originate with the test, no outside dependencies.
The scenarios that I put together were these:
1. A public function which accepted two numbers, multiplied them together and returned the answer
2. A private function which accepted two numbers, multiplied them together and returned the answer
3. A public function which which accepted two numbers, queried a database for the answer and returned it.
4. A public function which accepted two numbers, obtained a query from another function in the component and then returned the answer. This actually used MockBox for the first time..
These went surprisingly well and I'll be outlining other techniques as I explore this more thoroughly.
However, for the life of me, I couldn't get to first base on mocking. Conceptually, I knew it was when something was pretending to be something else but I didn't even know enough to understand the documentation (which is more of statement about me than the docs). As a result, I've been using Testbox in a valuable but limited way by using it to run a function without having to go through an interface which may or may not exist yet. The problem is that I wasn't separating it from any other function, table, web call or process with which it interacts. This in an of itself is a valuable process but it's not really unit testing and with that statement comes the following dialogue which I've published somewhere else.
Glossing over the argument about unit testing, we're launching a new automatic build system at work so testing, and more importantly, testing that ran quickly, covered multiple scenarios and was not attached to a database or actually called web services was needed. This precipitated me actually putting keystrokes to concepts and figuring out how this mocking thing works.
It turns out to be much easier than I thought.
To figure out how this worked I wanted to set up a simple function but one with ever increasing complexity of architecture. By that I mean that ultimately all my function did was to accept two numbers and then return an answer but did so in different ways. The rules were that I had to submit the same two numbers and get an answer. I was using TestBox and it's built in partner, Mockbox. The test could only run the function being tested and all information needed to run that function had to originate with the test, no outside dependencies.
The scenarios that I put together were these:
1. A public function which accepted two numbers, multiplied them together and returned the answer
2. A private function which accepted two numbers, multiplied them together and returned the answer
3. A public function which which accepted two numbers, queried a database for the answer and returned it.
4. A public function which accepted two numbers, obtained a query from another function in the component and then returned the answer. This actually used MockBox for the first time..
These went surprisingly well and I'll be outlining other techniques as I explore this more thoroughly.
Comments
Post a Comment