The foundation on top of which everything else is built.
Regigious Zealot?
Those who have worked with me almost all get tired of hearing about unit tests but they are
fundimental. There are tons of books and other sources to tell you why and how to unit test
but for me this is single practise that freed me up from the concern of wheather my code
actually works or not and allowed me to begin to think about other concerns like
if my code was well designed or understandable.
In Practise
I always aim for 100% coverage but this is not always practical but I try to isolate non-tested
code and to test it in other ways.
Unit testing and other automated testing is built into my software pipeline and any drop in
coverage will trigger a build failure. I use a combination of trying to always write the
unit tests first and then code coverage tools to check if something was missed.
Writing the tests first took a lot of time to work up to for me but now using ReSharper
this just makes the most sense as much of the code can be generated directly from the
tests and goes much faster.
There are other layers of testing besides the unit testing of TDD that I employ to ensure
I release only working software that I trust but the unit tests are the bit that guides
the code design and helps to make my software structure better at the class level.
For the most part a 'unit test' should test only one class, with the noteable exclusion
of property only data model type classes. I really wish the language had supported classes
of this type in C#7 as was initially proposed. For now we will have to stick to convention
but some help from the compiler to enforce this would be great. The test fixture should
have an exact 1-to-1 mapping to the class but can have as many tests as required to define
all the behaviour and assert it.