Vishwanath Krishnamurthi's blog

A blog on Java EE, clean code, open source and TDD

Unit Test – What matters ? And some good practices

with one comment

Unit testing – Framework matters ? – No. Not much

Just as any “framework” is supposed to do, unit testing frameworks simplify your job and that’s what they are for. You could get the hang of a framework like JUnit in just a few minutes.

Unit testingWriting hundreds of tests matters ? – No. Not Unless

these tests are “good quality tests”. It’s pretty easy to write hundreds without having a sense of what these tests are supposed to test.
What matters is having “good quality” unit tests. So what makes a test, a good one ? Well I would say that of all factors, “failability” is the most important one.

To explain, say you’ve written a test of requirementX. A few days later the requirement changes and you make the code changes without changing the test. On running the test, the test should fail. If it doesn’t the test was no good at all.

Unit testingWriting testable code matters ? – Hell yes !

More than anything ! Writing testable code matters so much. And probably the best material around on the net would be

Unit testing – Discipline matters ? – Yes ! The most difficult one to acquire

We do come up with excuses for not writing tests. “Pressure”, “Deadlines” and more. And yes, as previously said, those are “excuses” for our own laziness.

Developing this discipline and sticking to it is probably the hardest thing to do. Definitely, I know I don’t have this discipline. But this is something to work towards. There’s a great section on Uncle Bob’s book “Clean Code” on how a developer should guard his code, writing tests, without excuses. You might like reading it.

The good practices section – Okay, just a collection of advises that you’d normally find

  • Focus on writing tests that cover only “one unit” so that a twenty tests don’t break in the place where only one should have broken.
  • Must not depend on the order in which a test is run. (Eg: A test should not expect a particular test to have run before it. )
  • If your method can behave in two different ways (say based on the value of a parameter passed), write two different unit tests.
  • Learn when / how to use mock libraries. (Mockito is a good one! )
  • Check the coverage of your tests once in awhile. (There are some amazing coverage plugins ) It’s good to have 70-80% coverage
  • Check also the exception paths and write separate unit tests for exception paths
  • Have minimal no of asserts in a test -Ideally one. Having one assert per test makes the test standalone and also precisely pin points the bug.
  • To check an algorithm, use a second algorithm and verify for matching results. ( Eg: you can check your sort() method that does a heap-sort by writing a sort() method in your test class that does a bubble-sort. And verify that both algorithms return the same results )
  • Need not test very simple code – getters, setters or very basic methods
  • Let the test names be long and descriptive – Describe the expected behavior. A mere testMethodX() is not of much use. methodXShouldDoYWhenPassedZ() helps.
  • Object Oriented design practices, clean code, good naming, refactoring – All of these apply here too -The test documents the design. Hence using right method names is extremely important. To understand a functionality, a programmer would first want to read and execute a test !
  • Need not test private methods. If the private methods are not very complicated, they need not be tested. A private method can be tested indirectly by testing the public/package-private methods that use it.
  • A bug is reported ? Write a test. Result is red ? Good. Now add the fix and make it Green.

Finally, Why TDD ? And why “test first” as advocated by TDD ?

TDD advocates that a test should be written and only then production code is written. A not-so-intuitive thing to do. But what is the gain ? By writing tests first, the points mentioned in this post earlier (writing good quality tests, writing testable code) is all taken care by itself.

A good resource on how the cycle should go –

The 4-contact points of software development


Written by Vishwanath Krishnamurthi

October 23, 2010 at 10:32 pm

Posted in Design

One Response

Subscribe to comments with RSS.

  1. Right here is the perfect blog for anyone who really wants to understand this topic.
    You know so much its almost tough to argue
    with you (not that I really will need to…HaHa). You certainly put a fresh spin on a topic that’s been written about for years.

    Excellent stuff, just excellent!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: