Why? Why? Why? Unit Testing…
It sounds like the beginning to a Tom Jones song, but it’s the most common question I get asked when I introduce unit testing to someone.
So here’s the definitive answer…
- How do you know your code works?
You’ve written a package/procedure and, ok, you may have run it in SQLPLUS, TOAD, SQL Developer, but does it do what it’s meant to do? Have you tested it from all angles? Does it fail gracefully if there’s an error?
- It works today but will it work tomorrow?
Ok, so you tested it when you wrote it, but will it work tomorrow? Next week? At the end of the project when you’re migrating to the Live Environment? During the development phase your database may change frequently and invalidate packages. Therefore, you need to run your unit tests frequently to verify that everything is ok.
- Detect your errors early
If there’s a bug in your code you must detect it early. This ties in to the concept of Daily Build and Continuous Integration whereby your application is built and tested frequently so that you can see errors as they happen and fix them early, not when it’s too late!
- Does it replace User Acceptance Testing? Of course not.
It’s true to say that a comprehensive unit test can do much of the functional business logic testing, but we can never totally replace the UAT stage.
- Don’t cheat with your Unit Tests!
You could sit and create lots of tests that simple verify that an object exists, but is that a relevant and accurate test? Not really.
A unit test should test the functioning of your code. Does your code do what it’s meant to do?
- Peer Review
Following on from point 5, we should review each other’s code making sure that our tests are accurate, relevant and appropriate.
There may be many other reasons why unit testing is a good idea, so please feel free to comment below.
I’m always open to new ideas on code writing and testing!