Unit testing has been around for quite a while and a lot of developers have created their own unit tests. Even being a simple concept and having been around for some time I still think that unit tests are misunderstood, poorly written and don't follow best practices by a majority of developers. I'm not a unit testing expert but there are some guidelines that I try to follow when I create unit tests some of those are listed below (in no particular order).
- Make them small
- Make them self contained
- Make the names describe what the test case tests (at the price of a long name)
- Follow the arrange/act/assert pattern, i.e. don't do something like arrange/act/assert/act/assert, etc.
- Don't make database calls!
- Use mocks when necessary to ensure that you test the correct piece of code
- Consider making methods/properties to be internal instead of private. You can use the InternalsVisibleTo attribute to allow testing of internal items.
- Don't have app.config for your unit tests. Unit test should "arrange" the configuration in code.
If you make your unit tests too long and to test more than one item then they will become a pain to maintain, which leads to them being ignored and eventually to a complete breakdown to your testing effort in general.
I have recently been thinking more about how unit tests are being used throughout software development. Also I've been reading ASP.NET MVC in Action which coincidently puts a lot of emphasis on unit testing. I found a few quotes in Chapter 3 of that book, which covers Controllers, and thought that I would share them here because I agree with statements whole heartedly. Text in italics are my own comments.
- Unit tests run fast because they do not call out of process (i.e. no database calls, no web service calls, etc)
- It is very difficult to test poorly designed code. (Do you ever have a set of code and think to yourself, "I can't write unit tests for this, it's impossible", at this point you should consider to refactor it because this is a red flag for bad code!)
- (While discussing mocking)… unit testing becomes easy and soon becomes a repetitive pattern of faking dependencies and writing assertions. Over time, if you employ this technique, you will see a marked improvement in the quality of your code.
- A good controller unit test runs fast. We are talking 2000 unit tests all running within 10 seconds.
- It's nearly impossible to test-drive code that ends up with a bad design. (Once again bad code is hard to test)
- Pay attention to pain. If your tests become painful to maintain, there's something wrong.
- Correctly managed design and tests enable sustained speed of development whereas poor testing techniques cause development to slow down to a point where testing is abandoned.
Some of the key take aways: use mocks, and testing should be helpful to your development process not a hindrance.
Don't write unit tests just to write them or just to get the necessary coverage. Make sure that you write the test cases with a specific intent and that they are written well so that you will continue to maintain and execute them as a part of your CI build process.
Here are some unit tests that I've recently written that I'd like to use to show some concrete cases.
[Test]
public void TestGetConfigValue_ValueExistsRequiredTrue()
{
string key = "83F216CD-1B3E-4fc1-9DA5-4A7D506AF7E8";
string expectedValue = "C2D4E7CA-BE6B-4976-BFA9-50F5223C603A";
ConfigurationManager.AppSettings[key] = expectedValue;
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, true);
Assert.AreEqual(expectedValue, actualValue);
}
[Test]
public void TestGetConfigValue_ValueExistsRequiredFalse()
{
string key = "0601AB1F-C78C-4c72-8648-B140D50BDDEC";
string expectedValue = "92DCADBC-9618-49f3-A412-5C90A945903D";
ConfigurationManager.AppSettings[key] = expectedValue;
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, false);
Assert.AreEqual(expectedValue, actualValue);
}
[Test]
public void TestGetConfigValue_ValueDoesntExistRequiredFalse()
{
string key = "2D4B5C66-BA37-4ab8-9B51-3F17CF348E6D";
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, false);
Assert.IsNull(actualValue);
}
[ExpectedException(typeof(ConfigurationErrorsException))]
[Test]
public void TestGetConfigValue_ValueDoesntExistRequiredTrue()
{
string key = "0511216E-3AA6-4b80-B215-E980A459466D";
// ConfigurationErrorsException here
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, true);
}
[ExpectedException(typeof(ArgumentNullException))]
[Test]
public void TestGetConfigValue_KeyIsNull_RequiredFalse()
{
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(null, false);
}
[ExpectedException(typeof(ArgumentNullException))]
[Test]
public void TestGetConfigValue_KeyIsNull_RequiredTrue()
{
string actualValue = ServiceConfigHelper.Instance.GetConfigValue(null, true);
}
// Setup method here
[SetUp]
public void Reset()
{
ServiceConfigHelper.Instance.Reset();
if (ConfigurationManager.AppSettings.HasKeys())
{
List<string> allKeys = new List<string>();
foreach (string key in ConfigurationManager.AppSettings.Keys)
{
allKeys.Add(key);
}
foreach (string key in allKeys)
{
ConfigurationManager.AppSettings[key] = string.Empty;
}
}
}
Notice that each of these has a very descriptive name, if you saw the name of the test in the list of failed test cases you immediately know what to work on; you don't even have to look at the test. Notice that all of the tests are pretty small, and that each test case tests a very specific piece of functionality. Also you might have noticed that I use Guids in test cases I like to do this just to make sure that I have random data and that test cases don't conflict with each other.
Also I'd like to note that in the book the guys recommend reading Working Effectively with Legacy Code for good coverage of unit testing, I haven't read it but I might grab a copy.
Sayed Ibrahim Hashimi