Tools

The Importance of Unit Testing

by on March 17, 2014 8:57 am

I’m currently working on an enhancement to an existing insurance premium rating algorithm. Anyone who has done work in insurance (whether it be in IT or on the business side) is probably well aware of how complex this can become.

Consequently, any significant enhancement to such a system is quite likely to be fraught with pitfalls and setbacks, and that’s even before considering the level and quality of business requirements and testing strategies. However, the existence of unit tests can help to minimize these risks.

Both unit tests that exist before development enhancements and unit tests you create as part of the development effort can be beneficial.

Existing unit tests benefit developers in at least two ways:

1. They could be considered a form of requirements as to how the system currently operates. Unit tests provide concrete expressions of business requirements. For those who understand concepts better through examples (such as me), these existing tests can be invaluable. Even with well-written business requirements, sometimes understanding can only come through examples such as this. It also provides the developer with a debugging opportunity for deeper understanding of the existing code, should this be found to be necessary.

2. They help to ensure that changes made by the enhancement do not break the existing system, or gives the developer a testing pathway, should the existing behavior need to be changed due to the enhancement.

New tests also provide their own benefits:

1. It should be obvious that they help to ensure that code meets requirements.

2. They also help to ensure that all logic conditions are accounted for. They force the developer to revisit the code they have just written and to approach it from different directions. This helps to root out conditions the developer might not otherwise think of, resulting in them to then alter the code to properly handle these conditions.

Sufficient Coverage

So, what are some ways we can ensure that we write unit tests with sufficient coverage? Below is a short list of some guidelines to follow:

1. How many tests are enough? Nothing that can break should be left untested, even seemingly trivial ones.

2. Most modern development environments have tools that will expose code that does not get executed during the run of your unit test suite. Use these tools to ensure you get the most thorough test coverage you can.

3.  Test boundary conditions, especially when testing something as complex as the algorithm I referred to in my introduction.

4. Bugs tend to collect within the vicinity of each other. If one bug is found, it is good practice to thoroughly test the code around it, since it is likely other bugs will exist there as well.

5. Lastly, and this can sometimes be difficult, tests must be as fast as you can possibly make them. When time gets short, it will be the longest running tests that get sacrificed first. As an example, I’ve had unit tests in the past that have processed over xml document provided as the result of a service call. These documents were huge, containing the data for entire policies, most of which we never even needed. To cut down on processing time, we edited these documents to contain only the data relevant to the tests being run.

Unfortunately, the decision to create unit tests or not isn’t always up to the developer. As I previously stated, I think most of those involved understand the importance on a theoretical level, but just are not willing to sacrifice the time up front to ensure that unit tests are written. However, as developers, we must try to incorporate them when we can.

– Robert Rice, asktheteam@keyholesoftware.com

  • Share:

Leave a Reply

Things Twitter is Talking About
  • @rickincanada Thx for your tweet! Shoot us an email at asktheteam@keyholesoftware.com so we can set up a time to talk. Have a good day.
    July 24, 2014 at 3:33 PM
  • Never used JAXB? Check out a simple usage pattern that pairs #JAXB’s data binding capabilities with JPA - http://t.co/Ki9G04HV5e
    July 24, 2014 at 9:53 AM
  • Guess what today is? Tell An Old Joke Day - http://t.co/835ORWMX6N! So, why do programmers always confuse Halloween & Xmas? 31 Oct = 25 Dec
    July 24, 2014 at 8:45 AM
  • MT @midwestio: Posted another #midwestio talk recording to our YouTube channel: @MinaMarkham on modular CSS. Watch: http://t.co/aU3LpfUoi4
    July 24, 2014 at 8:25 AM
  • We just posted pictures from our National Hot Dog Day Lunch Cookout. Check them out - http://t.co/To06plaw1C
    July 23, 2014 at 4:14 PM
  • Good free cheat sheet - #Java Performance Optimization Refcard from @DZone: http://t.co/7vBgsmqy08
    July 23, 2014 at 10:48 AM
  • Did you know today is a holiday? It's National Hot Dog Day! We're gearing up for our team lunch hot dog cookout & can't wait to celebrate.
    July 23, 2014 at 9:43 AM
  • Check out our newest blog: #JAXB – A Newcomer’s Perspective, Part 1 http://t.co/Ki9G04HV5e
    July 22, 2014 at 1:22 PM
  • New post on the Keyhole blog by Mark Adelsberger: #JAXB – A Newcomer’s Perspective, Part 1 http://t.co/Ki9G04HV5e
    July 21, 2014 at 2:27 PM
  • If you're a Java dev, you're likely familiar with Annotations. But have you created your own #Java Annotations? Ex - http://t.co/BgCsYjxZKF
    July 18, 2014 at 12:10 PM
  • RT @gamasutra: Don't Miss: Unconventional Tips for Improving your Programming Skills http://t.co/6TFox7CKHU
    July 16, 2014 at 3:20 PM
  • We're about to send out our free monthly tech newsletter. Dev tips/articles via email. Not on the list yet? Sign up - http://t.co/F8h0NSiicZ
    July 15, 2014 at 11:57 AM
  • Have you ever tried creating your own #Java annotations? See a situation where it was beneficial - http://t.co/BgCsYjxZKF
    July 15, 2014 at 8:36 AM
  • There's a new post on the Keyhole blog by @jhackett01: Creating Your Own #Java Annotations - http://t.co/BgCsYjxZKF
    July 14, 2014 at 1:43 PM
  • We love development! Have you seen our weekly team blog? We show how to be successful with the tech we use. See it - http://t.co/nlRtb1XNQH
    July 12, 2014 at 2:35 PM
  • Rapid appdev has a bad rep, but there are ways to bring development time down the right way. Don't Fear the Rapid - http://t.co/aTPcAKOj0r
    July 11, 2014 at 3:10 PM
  • Automated Testing is great for dev, but does bring a set of challenges (especially for #agile teams). Success tips: http://t.co/1acl1ngO7i
    July 11, 2014 at 12:16 PM
  • This is fantastic - One small step for Google, one giant leap for empowering girls to code: http://t.co/R90V5DBkv1
    July 10, 2014 at 2:52 PM
  • #RabbitMQ: messaging software built on AMQP protocol. Learn relevant concepts & how to avoid common "gotchas" here: http://t.co/ZwMXlhKyX8
    July 10, 2014 at 9:31 AM
  • A huge welcome to Brian Wetzel who joins the Keyhole team today!
    July 10, 2014 at 8:50 AM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.