Short answer: Unit testing is evolving, time to change with it.

Long answer: So maybe it was just me back when I truly didn’t understand Unit Testing and the purpose of it; most of the time I saw it as an evil that might help you at some time. Well things have changed in my opinion of this once I started working with a company that had poor unit testing procedure. Not that their tests were flawed, they did the standard approach and tested each component to 100% code coverage. The problem is that when they put the components together, there were no integration tests to make sure they would work. So Component1 was expecting “input A” but got “input B” because component2 thought it needed to output B instead of A. Basically, making sure you have integration tests is paramount.

But that isn’t the point of this post; the point is that Unit Testing is coming along way from just writing a test class. I’m going to share with you two methods I’ve found really help in performance. It takes a little more time, but cuts down on unit testing. I’ll also try to explain it best I can and if there are questions by all means ask them in the comments, I’ll respond within the day at longest.

This help is designed around xml, although you can use it for other purposes. What it does is allows you to test / validate shared data between components of similar tests. This also assumes you are using Visual Studio, but I’m sure you can do this in other tools as well,

First Help:

The first help is perhaps the hardest, but here is what to do. Create a new xml file, in this file make a <TestCases> root tag, and then put a <TestCase name=”TestData”> inside this root.

<TestCases>

<TestCase name=”TestData”>Some data </TestCase>

</TestCases>

Now inside this TestCase tag you can create a cdata or whatever kind of tag you want maybe xml if that is what you are testing. Now that you have some test data setup, save the file and unload the project file. Click to edit, now find the xml file you just created and change its value to a dependentupon.

So it will look like…

<EmbeddedResource Include=”MyClassUnitTestData.xml”>

<DependentUpon>MyClassUnitTests.cs</DependentUpon>

</EmbeddedResource>

What this will do is when you reload the project; it will make it so the item appears under the unit test that the data relates to. So the cs file will look like a folder with that xml file under it. This helps keep the data with the tests.

Now if you write an XmlReader that takes in a type (I used a generic class that took in the type of the unit test class) that then uses reflection to get that embedded resource. Then you can pass in a name for what testcase you want out of it. It will then return whatever you want, I personally return an xml reader or xmldocument, but that is because I use xml. When I did one that didn’t involved xml or was suppose to be an invalid xml testcase, I used a cdata node and ended up returning the data in a stream.

So what we have done now is created a way to keep the test data and results close to the tests that relate to them. No more 100 file resource folders.

Step two (or maybe just another improvement):

So the second improvement to the Unit Test which blew my mind when I first realized I could even do it is to create a base class for the tests. So let’s say you have several components that use the same data. For this example I’m going to say that you are writing a data access layer and the connection string is shared between several classes along with the insert statements and all that jazz. So you have multiple data access classes that need similar data (connection string and different test data with insert). So then you can abstract out a base class that we will call “DataAccessUnitTestBase.cs” and in this class we have functions like “GetConnectionString” or “LoadInsertTestData” and these will return to you all the data that you need for that test. This helps keep the unit tests simple by only have one set of test data around.

Another exampled taken from myself is a Regex class I had to create to parse some data. The data used to be “[XPath]” but due to issues presented we wanted to change it over to “{XPath}”. The point isn’t so much the change, as when the test data needed to change to match, I only had to change the data in one spot, not every test, not several tests, and it was all in one spot.

So here is where it becomes really cool, I used step one to get all my test data into an xml file that holds my testdata, and then I made it dependentupon the UnitTestBase class. Then I created a base class function like “LoadSimpleData ()” that would then know to get the embedded resource of its own type (UnitTestsBase), and look for a testcase called “SimpleData”. It then returns that data. So now I have a nice file that has unit tests related to a group of tests and they are very nicely organized and I don’t have hundreds of resource files.

Unit Testing is looking like it is coming a long way. Designing code is taking less and less time and Unit Testing becomes more and more important as the project grows. The projects are getting so big and changing so fast, we started to design good Unit Tests and it has improved our ability to change with the project so much easier. Instead of spending an hour to update all the unit tests, it takes only a few minutes.

Filed under: Design, Design, development, Software Development, unit testing