Unit Testing. Books have been written about it. Many, many books. About Unit testing; about Testing methodologies, about Unit Testing approaches, about Unit Test Frameworks, etc. I won’t attempt to duplicate that work here, as I haven’t the expertise to approach the subject to anywhere near that depth. But I felt like writing about it. Perhaps because I’m writing Unit Test code.

Currently what I am doing is writing Unit tests, as mentioned. These are written using C# (since they are testing C#, so it makes sense), and they make use of the built-in Visual Studio/NET Unit Testing features.

In my mind there are some important ‘cornerstones’ of Unit Tests which make them useful. Again, I’m no expert with Unit tests but this is simply what I’ve reasoned as important through my reading and interpretations on the subject so far.

Coverage

making sure Tests engage as much of your codebase as possible applies to any type of testing of that code, and Unit Tests are no exception to that rule. It is important to make sure that Unit Tests execute as much of the code being tested as possible, and- as with any test- should make efforts to cover corner cases as well.

Maintainability

When it comes to large software projects, one of the more difficult things to do is encourage the updating and creation of new Unit Tests to make sure that Coverage remains high. With looming deadlines, required quick fixes, and frequent “emergency fixes” It is entirely possible for any Unit testing code designed to test this to quickly get out of date. This can cause working code to fail a Unit test, or Failing code to pass a Unit Test, because of changing requirements or redesigns or because code simply isn’t being tested at all.

Automation

While this in part fits into the Maintainability aspect of it, this pertains more to automation of build processes and the like. In particular, with a Continuous Integration product such as Jenkins or TeamCity, it is possible to cause any changes to Source Control to result in a Build Process and could even deploy the software, automatically, into a testing environment. In addition, Such a Continuous Integration product could also run Unit Tests on the source code or resulting executables and verify operation, causing the build to be marked a failure if tests fail, which can be used as a jumping off point to investigate what recent changes caused the problem. This can encourage maintenance (if a code change causes a failure then either that code is wrong or the unit test is wrong and needs to be updated) and is certainly valuable for trying to find defects sooner, rather than later, to try to minimize damage in terms of Customer Data and particularly in terms of Customer Trust (and company politics, I suppose)

I repeat once more than I am no Unit Test magician. I haven’t even created a completely working Unit Test Framework that follows these principles yet, but I’m in the process of creating one. There are a number of Books about Unit tests- and many books that cover Software Development Processes will include sections or numerous mentions about Unit Test methodologies- which will likely be from much more qualified individuals then myself. I just wanted to write something and couldn’t write as much about Velociraptors as I originally thought.