Unit Testing
There are 10 entries for the tag
Unit Testing
A while back I talked about how testable code helps manage complexity. In that post, I mentioned one common rebuttal to certain design decisions made in code in order to make it more testable. Why would I want to do XYZ just do improve testability? Recently, I heard one variation of this comment in the comments to my post on unit test boundaries. Several people suggested that it’s fine to have unit tests access the database, after all, the code relies on data from the database, it should be tested. Implicit...
When I build applications, I personally like to have my unit tests in a separate class library project than the application I am testing.
That’s just how I roll.
I just assumed this is how everyone structures their unit tests, but I’ve talked with some people who have a deep history in TDD who put their code in the same project.
So I wanted to create a simple poll to find out how people are actually structuring their unit tests. I’ve been involved in various internal discussions looking at
how Microsoft design, tools, code can better support unit testing across the board.
Note...
If you know me, you know I go through great pains to write automated unit tests for my code. Some might even call me anal about it. Those people know me too well. For example, in the active branch of Subtext, we have 882 unit tests, of which I estimate I wrote around 800 of those. Yep, if you’re browsing the Subtext unit test code and something smells bad, chances are I probably dealt it. Unfortunately, by most definitions of Unit Test, most of these tests are really integration tests. Partly because I was testing legacy code that...
Sometimes when writing unit tests, you run into the case where you want to override the behavior of a specific method.
Here’s a totally contrived example I just pulled from my head to demonstrate this idea. Any similarity to specific real world scenarios is coincidental ;). Suppose we have this class we want to test.
public class MyController
{
public void MyAction()
{
RenderView("it matches?");
}
public virtual void RenderView(string s)
{
throw new NotImplementedException("To ensure this method is overridden.");
}
}
What we have here is a class...
This is a quick follow-up to my last post. That seemed like such a common test situation I figured I’d write a quick generic method for encapsulating those two tests. I’ll start with usage. [Test]
public void FileBrowserSecureCreationTests()
{
AssertSecureCreation<FileBrowserConnector>(new string[] {"Admins"});
}
And here’s the method.
/// <summary>
/// Helper method. Makes sure you can create an instance
/// of a type if you have the correct role.</summary>
/// <typeparam name="T"></typeparam>
/// <param name="allowedRoles"></param>
public static void AssertSecureCreation<T>(string[] allowedRoles
, params object[] constructorArguments)
{
try
{
Activator.CreateInstance(typeof (T),...
This is a simple little demonstration of how to write unit tests to test out a specific role based permission issue using NUnit/MbUnit and Rhino Mocks.
In Subtext, we have a class named FileBrowserConnector that really should only ever be constructed by a member of the Admins role. Because this class can write to the file system, we want to take extra precautions other than simply restricting access to the URL in which this object is created.
Here are two tests I wrote to begin with.
[Test]
[ExpectedException(typeof(SecurityException))]
public void NonAdminCannotCreateFileConnector()
{
new FileBrowserConnector();
}
[Test]
public void AdminCanCreateFileConnector()
{
MockRepository mocks = new MockRepository();
IPrincipal principal;
using (mocks.Record())
...
A coworker of mine ran into some problems using WATIN to test our website. Specifically issues with Javascript and AJAX. Yes, I know there’s Selenium out there, but I hoped for something we could run from within NUnit/MbUnit, so that it’s nicely and easily integrated into our build process and development environment. He did a bit of digging and found this free web automation infrastructure product by Art Of Test Inc. called WebAii (they also have a blog). It seems to do everything we want and more. Check out some of these features (the full feature list is much longer). ...
Ayende just announced the release of Rhino Mocks 3.0. The downloads are located here. If you aren’t subscribed to Ayende’s blog, I highly recommend it. This guy never sleeps and churns out code like a tornado.
Ever since I discovered mocking frameworks in general, and especially Rhino Mocks, mocking has become an essential part of my unit testing toolkit.
A while ago I wrote a short intro demonstrating how to write unit tests for events defined by an interface. This small example shows the usefulness of something like Rhino Mocks.
If you’re wondering what the difference between a mocks, stubs, and fakes, be...
Leon Bambrick (aka SecretGeek) has started a series on Agile methodologies and Test Driven Development (TDD) in which he brings up his own various hidden objections to TDD in order to see if his prejudices can be overcome. One of the questions he asks is an age old argument against TDD. Who Tests the Tests? Leon sees potential for a stack overflow since, given that the tests are code, and that according to TDD, code should be tested, shouldn’t there be tests for the tests? The short answer is that the code tests the tests, and the tests test the...
One of the holy grails for unit testing is to get 100% code coverage from your tests. However, you can’t sit back and smoke a cigar when you reach that point and assume your code is invulnerable. Code coverage just is not enough.
One obvious reason is that Code Coverage cannot help you find errors of omission. That is, even if you had 100% code coverage from your tests, if you forget to implement a feature (and a test for that feature), then you’re shit out of luck.
However, apart from errors of omission, there’s the case presented here. Imagine...