Beginning Test Driven Development
page 3 of 7
by Brendan Enrick
Feedback
Average Rating: 
Views (Total / Last 10 Days): 34747/ 54

Creating Two Simple Tests

To start off, we want something easy just to demonstrate what types of things we want to test, and how we go about testing them. Before we dive into writing our first test, I should probably at least give a small amount of background on our example application. We are going to be working on a card game. For the purposes of this article, we will just be focusing our attention on a few classes in the game; Deck, Card, and Player.

We should always start off with the simplest thing we want to do. The first thing we need to do is come up with something our code should do. We want to then write a test which asserts that our code works as expected.

Naming your tests is extremely important. If you don't name your test well, you will not know what it is testing later and you might go off on a tangent and test something entirely different. You want to be descriptive enough to describe the problem, but you also need to be concise. For this first test, we will use the name, DeckCountShouldEqualCardCount. We will follow that test with one called, DeckShouldHaveOneLessCardAfterDrawing. Some people will read these names and think I am crazy, but let me remind you that you will have tests for every class and without names this descriptive; you will not know what is wrong when tests fail. Having a descriptive name tells you immediately what failed, because it is in the name

We know that we need to be able to draw cards and that after we draw there should be one less card in the deck, so we should start off by creating a deck with a collection of cards, keeping track of the number of initial cards. We then draw a card from the deck and assert afterwards that the number of cards in the deck has decreased by one. The following are our first test methods.

Listing 1: The Simple Tests

[Test]
public void DeckCountShouldEqualCardCount()
{
    var cards = new List<Card> {new Card(), new Card(), new Card()};
    int initialCardCount = cards.Count;
 
    var deck = new Deck(cards);
 
    Assert.AreEqual(initialCardCount, deck.Count);
}
 
[Test]
public void DeckShouldHaveOneLessCardAfterDrawing()
{
    var cards = new List<Card> {new Card(), new Card(), new Card()};
    int initialCardCount = cards.Count;
 
    var deck = new Deck(cards);
    Card card = deck.DrawCard();
 
    Assert.AreEqual(initialCardCount - 1, deck.Count);
} 

When we compile this, we get a build error because we have a little bit of implementation to do. We can assume that our 3 classes exist as empty shells for now, so the remaining work to fix the compiler errors is to create a constructor for the Deck class which takes a collection of cards, create a method called DrawCard, and create a property called Count. When we first create these we can just have them each throw a NotImplementedExcetion. Then we will no longer have the compiler errors. This is a good opportunity to run the tests and confirm that they indeed fail. This means that our code needs to be written. Having a failing test is kind of like having a task in the queue.

I am not going to cover running NUnit in this article, there are plenty of articles and tutorials that demonstrate how to run that application.


View Entire Article

User Comments

No comments posted yet.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-29 2:46:01 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search