Replace paper with unit tests

TDD, or Something Like It

When I write new code, I often start out following the TDD principles: write a test, make it pass, refactor. But often, as I’m doing the refactoring or even the initial implementation, I find myself thinking of other tests I should do or features I should add. Instead of jotting things down on a piece of paper, I’ve started creating method stubs for my future tests that effectively document my development path for me:

[Test]
public void CreateItemThrowsExceptionWhenNameIsDuplicate()
{
}

This is nice and I can go in and fill in the details of those tests as I work through my code. However, it’s still easy to forget or miss a test, since these will automatically show up as passing. So we can add an Assert.Fail() call:

[Test]
public void CreateItemThrowsExceptionWhenNameIsDuplicate()
{
    Assert.Fail("Implement me!");
}

This will now remind you to implement tests as you run them locally. Great!

Why bother?

The benefits are pretty clear:

  1. Even if you’re the type of developer to write tests after you write the actual code, this will help you make sure you’re not forgetting anything. It can save you from either trying to find that piece of paper where you wrote down your thoughts three days ago or from staring at your just-written code to identify parts that need testing.
  2. This promotes clear and meaningful test method names, since you have to be able to remember what you were going to test when you wrote the stub.
  3. As you fill in your tests, you will use your own code. If you’re writing an API or just a new set of public methods, you will see pretty quickly if they’re easy to use or if the consumers of your methods will come after you with torches and pitchforks.

My, that’s a lot of code to type in every time…

Typing all that out every time can, indeed, be quite tedious. That’s where Live Templates from ReSharper come in to save the day. I have a template set up that when I start typing in the word “test”, Intellisense picks it up and expands it to create a skeleton method that looks like the ones above, prompting me to fill in the method name and contents (with the Assert.Fail() call filled in by default).

Creating a Live Template with ReSharper

  1. Go to ReSharper->Live Templates… in Visual Studio to bring up the Templates Explorer dialog.
  2. Go under “User Templates” in the Live Templates tab and click the “New Template” button.
  3. In the window that comes up, pick your shortcut (mine is just “test”) and paste the following in the template’s code window:
    [Test]
    public void $TESTNAME$()
    {
         $ACTION$
    }

$TESTNAME$ and $ACTION$ are variables that can be pre-defined (as I will explain below) or be left undefined to let you type them in as needed. I leave $TESTNAME$ undefined and set $ACTION$ as follows:

  1. Click on “choose macro” in the Value column on the right.
  2. Select “Constant Value” and click OK.
  3. Paste “Assert.Fail(“Implement me!”);” in the dialog box that comes up and click OK again.

That’s it! Save your template and it becomes available to you in all your projects. Whenever you need a new test, just start typing “test” (or whatever shortcut you picked) and press TAB to expand it when Intellisense figures out what you’re doing.

The final result should look something like this:

Live Template Example

Live Template Example

For more information on ReSharper templates see their site.

No ReSharper?

I have tried to produce something similar with just plain recorded macros, but I’m doing something wrong there and my attempts haven’t worked at all. I’ll post again about it if/when I figure that part out.

Advertisement
Leave a comment

5 Comments

  1. Nice! Another mechanism I use for marking outstanding tests is to use the Ignore attribute like this [Ignore(“Implement me!”)]. I prefer this because I can distinguish between tests I should ignore because I haven’t gotten to them yet and those that are truly failing. In TDD I would ideally like to have only one failing test at a time and this helps me stay focused on that.

    Reply
  2. @Declan Whelan
    Totally agreed. The main reason I went with a failing test instead of an ignored one for my templates is two-fold:
    1. When I run my tests within Visual Studio through TestDriven.NET, I can double-click on a failing test in the Output window and be taken right to it in my code. If I recall right, I can’t do that with ignored tests.
    2. I have in the past mistakenly checked in ignored unimplemented tests — which by design didn’t fail the build and I just plain forgot about them. Reading through the test report and eliminating tests ignored for other reasons (especially if those reasons are long the lines of “I don’t know why it’s failing”) is a habit I’m trying to form, but it’s a work in progress.

    Reply
  1. Tweets that mention Anna Aleriel Lear » Replace paper with unit tests -- Topsy.com
  2. Anna Aleriel Lear » Replace Paper with Unit Tests: Code Snippets Edition
  3. Tweets that mention Anna Aleriel Lear » Replace paper with unit tests -- Topsy.com

Leave a Reply to Declan Whelan Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: