Reply: Some thoughts on tests' maintainability

This was to reply to an interesting post of my friend. Unfortunately, Blogger is not able to handle my long comment. Maybe it is too long, or may Blogger think I am a spammer. Anyway, the comment is long enough for me to dedicate one of my post here for it:

Read original post by my friend: http://playground.teerapap.net/2011/09/my-experience-with-unit-testing-in.html

Interesting post. I'm in my first years practicing unit testing too. Won't miss leaving a long comment here!

It seems the very problem about unit testing for you is about maintainability of the test cases. It was a question for me too about how many tests to write for particular class. The lower number of tests you write, the lower maintainance problems, right?

There are some occassions I avoid writing tests for. I am not claiming these are right or wrong but it seems to work for me.

#1: During our undergrad years, I was introduced to unit testing (with JUnit.) What I remembered are that we are encouraged to write tests for as many methods as possible. We even generated the tests for plain getter/setters. Come to think of it now, that was totally unpractical!

So now I just skip the simple methods I am sure there are only silly test cases for it.

#2: Another thing is about writing test for private methods. When you design a class, you are giving your users some kind of contract by providng public methods. These are something that should be broken or be changed often. If you need to change these often, you may have to admit the class is incorrectly designed and thus rewrite/add the tests.

However, I do not test private methods. This give me some room of flexiblity where I can change/optimize/organize the inner working of the class. I can change the signature/working of private methods any way I would like to, but I just need to make sure the public methods do pass the tests.

#3: I do have some tests you referred to as 'small acceptance tests.' However, to perform 'unit' testing, you test one and only one class. If the class depends on some other concrete classes then you have to change them to abstract/interface instead. If you are testing more than one classes than that may be considered as 'integration' testing, or some other names.

That was quite hard core! While I know this, I don't mock out some dependencies for small classes. That would require some efforts. But still, I would write integration tests for it.

Clearly, innovations in our world do not start with requirements from users. So all these models starting from requirement gathering are all WRONG. If you want to introduce something now, use whatever you like and do whatever you want to. But if you are building something big, you must also need to look into the rear mirrors and you do need some confidence going forward. Unit tests, test coverage, etc. are some of the answers to that.