I’m in the middle of developing a proof of concept project for a client that involves me working fairly closely with 3 third-parties along with the client. The communication and waiting game can sometimes be a PITA. Currently I’m waiting on any one of those 3 third-parties to provide me with “something” before I can proceed with “anything”. While I am doing “nothing” I figured I would add some unit tests to one of our core libraries. Since I’m using that library for the project I am working on, increasing code coverage on the library will help increase code coverage for my project. The library is new - rewritten for .NET 2.0. It already has about 60-70 percent code coverage - most of the “hairy” things have tests written for them - but many of the “normal” things do not.
So, basically I am just adding some “smoke” tests - instantiating objects and then testing to make sure they are not null, assigning values and then testing to make sure the values are what I assigned to them - some basic Getter/Setter testing. At one point early this morning I began questioning the value of the Getter/Setter testing I was adding which lead me to begin wondering if I wasn’t just adding the tests for the sake of improving code coverage. But then…
After writing Getter/Setter tests for a Product object, the unit tests threw an exception. Apparently the “ImageLarge” property wasn’t returning the value that I had assigned to it. In fact, it was returning the value for “ImageNormal” rather than for “ImageLarge”. Turns out that I had uncovered a nice little bug that would have probably been pretty tough to figure out in the middle of development of another project that used that library - we currently have 3 in development that do.
So now I have an answer to my question - yes it is worthwhile to write the basic Getter/Setter tests. Maybe there is no such thing as a “smoke test”. I just thought I would share my enlightenment.