NUnit and other popular and freely available unit testing frameworks have been here for enough time for people to absorb unit testing in their .NET development environments. Does just having parallel NUnit test cases for your code suffice to being truly test driven? In the following sections, I have tried to put down what I think about this whole thing.
Putting the very tenets of test driven development at the outset, the answer would be a straight ‘No'. So, what are these tenets? In my opinion, the most important tenets are:
- Test-First development
- Designing for testability
Test-first development did not make sense to me at first. The very concept of writing unit test cases before writing the application code, appeared to be against the norm. But if you take a hard look at it, you will see a value in writing test cases upfront. You will realize that it is the best scheme in building confidence in the code you are going to construct. Test cases built that way would be the guardian angels of the quality of code you write. In fact, I have started to believe that writing unit tests after you have churned out all the code does not add any value. You would be better off just testing manually - either running through the system's functionality or by just walking through the code. The reason being you, as a developer, would be more biased towards what the code does, rather than what it should actually be doing.
Like test-first development, designing for testability is not something that is typically at our disposition. Well, it is not any new model of design per se; it is just about taking your design and then asking these questions- is this suitable enough for me to write test cases against? Is it possible to create atomic units that can be tested and verified in isolation? This is definitely not as easy, as we typically tight-couple the layers in our application, rendering them difficult to test them as separate units. Design weaves the fabric of the application and hence, this tenet should be treated with a lot of importance. Because, having a design that makes it difficult to test individual units defeats the very purpose of unit testing.
Test-Driven development is a journey that I have embarked upon, and it is not going to be rosy to start with. The slogan - Red=>Green=>Refactor=>Test-Driven is all planted into my workplace, but I know, it would take more than that to imbibe it wholly into my daily work. But, I shall get there eventually.
So, are you ready to be test-driven?
[Problem]: Many a times, you end up using large string constants (usually placed in text files) in your application code. Typical examples are XSLT templates, SQL scripts and so on. It doesn’t really look nice to have a string constant defined in a class which have a hundred lines of text to serve this purpose. You wouldn’t want to store them separately in external text files either, as you wouldn’t want users to see/edit the contents.
[A Solution]: One way to solve this issue is to embed the text file contents in the assembly as a resource and then extract them at runtime. To embed strings in the assembly, you can add the text file to the project, and in the properties of the file select “Embedded Resource” as the build action. Then, to extract the contents of the file from the assembly, you can call the GetManifestResourceStream method on the Assembly instance, and read the stream into a string variable conveniently using StreamReader. You are just done!
Of course, this method is justified if the strings you embed are quite large (say, at least a 1000 characters or so). Else, be happy to use class constants.