Bit Motif

The other day, my team was asking if we needed to have unit tests for our data structure classes that had only getters and setters. We were thinking more in terms of Test First Development/Test Driven Design. I was uncomfortable saying “no”, but I couldn’t say why. Most IDEs will generate these, so you don’t you shouldn’t have to worry about doing something wrong. The practical side of me was fighting with the Test First side of me.

I could see why one wouldn’t want to have tests for said classes. They suck to write, and are supposedly so simple you have high confidence that they work correctly. Still, it bugged me. Then, a teammate pointed out something. In these cases, the value of the unit test isn’t necessarily the design aspect. It is for future users. The test is a set of expectations for the data structure class, a set of expectations that all other classes it interacts with will have.

If you don’t have a test, when you make a change, you aren’t going to have confidence that everything is working as it should. With a test, you will know what the expectations are if you need to make a change. And, if you make a change to the data structure class without regard for the test, the existing test should give you some feedback, and a little more confidence.

In this case, I think the value is for future changes. It isn’t nearly as cool as having a test drive your design (which it still can), but it is just as important.

As to why we have all these, data structure classes and what I think of it, that’s another post…