2011 Conceptual Web Framework Utopia — Part 2, Testing

This short series of posts represents a snapshot of my thinking at the end of 2011, in terms of how I would ideally produce web applications using the .NET platform. In this, part 2, I’m going to cover my current testing strategy and preferences.

For this post, the plan is:

  1. General  Testing

  2. Endpoint Testing, using the Endpoint Testing Pattern

  3. Database Testing with RavenDb

I won’t be talking about higher-level tests or BDD that drive the TDD. The only variable there is the frameworks, which are generally interchangeable.General Testing

My unit tests need to be fast, and they need to be readable – no interacting with databases then. See the last section for that.

To make unit tests readable I treat them as high-importance code. This doesn’t mean I take any longer, it means I have three simple rules that I nearly always use:

  1. Keep them short (3 lines is optimal, 7 means I don’t get to eat for the day)

  2. Hide assertions inside extension methods that read well (just like the GOOS boys)

  3. Wrap setup code in methods too

[Test]

public void Get_GivenIdForExistingBook_ShouldReturnViewModel_WithBooksDetails()

{

var book = GetRandomBookSimulatedToExist();

var viewModel = endpoint.Get(new UpdateBookLinkModel {Id = book.Id});

viewModel.ShouldHaveDetailsFor(book);

}

Above is an example of what I consider to be an ideal test.

Context Specifications

With the above preferences applied, most of the time there are just 3–5 line test methods that follow like a given, when then. Sometimes, though, it really makes sense to use a context specification.

[SetUp]
public void WhenRequestingABookReview_AndTheSystemContainsBooks_WithDifferentGenres()
{
var retriever = MockRepository.GenerateMock<IBookRetriever>();
var endpoint = new ViewEndpoint(retriever);
book = BookTestingHelper.GetBook(rating: 4);
retriever.Stub(r => r.GetById(book.Id)).Return(book);
SetupBookForSameGenreIncludingReviewBook();
retriever.Stub(r => r.GetReviewedBooks(book.Genre.Id)).Return(allBooksForSameGenre);
viewModel = endpoint.Get(new ViewBookLinkModel { Id = book.Id });
}
[Test]
public void ViewModelShouldHaveBooksTitle()
{
Assert.AreEqual(book.Title, viewModel.Title);
}
[Test]
public void ViewModelShouldHaveBooksGenreName()
{
Assert.AreEqual(book.Genre.Name, viewModel.GenreName);
}
[Test]
public void ViewModelShouldHaveBooksRating()
{
Assert.AreEqual(book.Rating, viewModel.Rating);
}

If you look at the full source code for this class you’ll see there are another 6 tests below it. I think in this case it was the most readable way to test.

When Do They Run?

Always — these are the general tests that form part of the main suite for giving immediate feedback about any regressions.Endpoint Testing

In part 1 my diagram mentioned “Endpoint-specific models”. This includes link (usually called request), view, and input models. By having them specific to each endpoint, the models are tested as part of the endpoint tests and not alone. I refer to this mentallly as the endpoint testing pattern, but it is not an official term.

For example:

[Test]

public void Get_GivenIdForExistingBook_ShouldReturnViewModel_WithBooksDetails()

{

var book = GetRandomBookSimulatedToExist();

var viewModel = endpoint.Get(new UpdateBookLinkModel {Id = book.Id});

viewModel.ShouldHaveDetailsFor(book);

}

This test covers the endpoint and the models. There would be no additional tests for the models — they only exist to serve one action method on this endpoint so don’t need it.

Update Scenario

[Test]
public void Post_GivenUpdateModel_ShouldCreateDtoAndPassToBookUpdater()
{
var model = new UpdateBookInputModel
{
Genre       = "genres/9",
BookStatus  = BookStatus.Reviewed,
Title       = "Updated title",
Id          = "books/444",
Rating      =  3,
Description_BigText = "Updated description",
};
endpoint.Post(model);
updater.ShouldHaveBeenCalledWithDtoMatching(model);
}

For these scenarios, a simple assertion is made that a service was called. Anything more involved than that is probably logic that doesn’t live there in an ideal world.

When Do They Run?

These will be ultra-fast tests that are part of the main suite of tests. Every time there is a change in code, these get run to check for regressions.Database Testing With RavenDb

I’ve specifically name-dropped RavenDb because this is my utopia. In this world, we eat, sleep and breathe RavenDb for data access because it makes life a lot easier. You get all the benefits of NHibernate’s session, transactions & POCOs, without any of the pain of the SQL mapping or performance disasters.

Another benefit of RavenDb is the testing support. In fact, this is fantastic. A mini Ayende sits their inside your pc spinning up an instance of his document database **in your computer’s memory. **As far as I’m aware, this works exactly the same as a normal instance of the database. None of those SQL Lite — SQL Server mismatches.

Here’s a data access test:

[Test]
public void GetWishlistBooks_ShouldOnlyReturnBooks_OnTheWishlist()
{
PopulateSessionWithBooksOfDifferentStatus();
Session.SaveChanges();
var fromSession = Session.Query<Book>().Where(b => b.Status == BookStatus.Wishlist);
var fromRetriever = retriever.GetWishlistBooks();
Assert.AreEqual(fromSession, fromRetriever);
}

Here is how the session is setup for testing….

public abstract class RavenTestsBase
{
protected IDocumentSession Session;
private EmbeddableDocumentStore store;
[SetUp]
public void SetUp()
{
store = new EmbeddableDocumentStore
{
Configuration = {RunInMemory = true,}
};
store.Initialize();
Session = store.OpenSession();
}
[TearDown]
public void TearDown()
{
Session.Dispose();
}
}

…..I agree — someone is taking the piss. This is so simple I’m worried the cleaner will take my job.

So You Run This With Your Main Test Suite?

They’re fast, but they’re no Ussain Bolt on happy pills….. I run these when any data access code changes and before important commits.Conclusion

I hope you enjoyed reading about my testing preferences and conventions. Whether you agree with them or not, it’s important to tell yourself how you think the best way to do something is. This gives you a point of reference to take on and incorporate new information — it helps you to improve… and socialise with other developers in the pub.

The most important part is having conventions about how you test. This lets you create consistent tests, that require less cognitive resource to create, maintain and read. You can then put more focus on delivering software and understanding the problem domain.

In part 3 I’ll show you some of my other preferences for web frameworks. Most of them have been learned by playing with FubuMVC.