Saturday, January 31, 2015

More on getting started with unit testing

In a previous post I talked about how I was finally able to start writing unit tests.  In this post I will discuss how I went from just starting out to where I am now.  This has involved splitting our database access object into two parts, creating an object factory, and a few mock objects.  I think they are mock objects and not stubs, but I may need to read about that a little more before I finish this post.

As much as possible while getting started I have been trying to do TDD (Test Driven Development).  This means I am following the process of writing tests first and then writing code that makes the tests passed.  I did have to make some tests for some existing code before getting started.
As I mentioned in the first post, at work we use a cfc that I wrote to do most of our database interaction.  If you are familiar with active records in Ruby on Rails it is similar to that.  I don't have much experience with rails but I think it is pretty similar anyway.  It doesn't really matter though for the purposes of my unit testing explanation.
Cfcs that extend that one are used in many places in our system and more places use it all the time.  So I decided it was a good object to start writing tests for.  The problem I ran into right away though was that much of what the cfc does is database activity.
We don't use the cfc directly.  It is always extended so I made an object in my tests folder that extends the database cfc.  Then I made a table in our dev database to use for my tests.  Then I had to setup tests for all the existing functions in the cfc.  After that I had a bunch of unit tests that do actual database activity.   I know I'm not supposed to do that, but at the time it was the only way I could get the tests written.
Now that I had tests I was able to make changes without fear of breaking everything.  Over several weeks or months I continued refactoring the code.  Eventually I reduced the number of methods that actually did database activity.  After that I was able to split the database activity into a separate class.
With that done now I was able to create a mock object for the query methods.   I also created an object factory object that allows me to inject the mock database object.  I think I'll stop here and maybe write up a few more details and some conclusions in another post.

No comments:

Post a Comment


  I'm not sure where I heard this, and it wasn't worded this way, but it helps to think about coding this way. Basically, any progra...