Comments on: Strategies for Structuring Unit Tests

By: Dave

Dave — Thu, 25 Jan 2007 01:07:01 +0000

Jeremy,

I hear you loud and clear. Most of this stuff I discovered (and am discovering) through trial-and-error. I lucked out and got to thinking about this stuff when I saw that presentation by Brad Wilson & Peter Provost (awesome presenters, btw).

Judah,

Great tip. I’ll incorporate this into a future revision of this post. I agree with you 100%. Right now I’m putting the tests into their own “Tests” solution folder. One thing I’d like to try is putting them side-by-side with the library under test, e.g.:

XS.Model.Contacts
XS.Model.Contacts.Tests

One thing that can be annoying is losing your place w/ Solution Explorer, so I’d be looking to keep everything w/in one scroll through this tactic.

By: Judah

Judah — Thu, 25 Jan 2007 00:33:32 +0000

I agree with James, 1 assertion per test. I’ve found tests to be smaller this way as well as more readable.

We have some 10 projects in a solution. I used to have all unit tests in a single project, but things started getting hairy. I’ve since broken the unit tests up into projects. Now, 10 projects means 10 unit test projects. Easier to find and maintain and allows you to run only the tests your interested in fairly easily.

Use TestDriven.NET (Visual Studio integration). This makes running your tests a breeze: just right-click and Run Tests from the context menu. Or better yet, assign a hotkey to run tests. I’ve assigned CTRL+\ to run the current test fixture set, and CTRL+] to run the last test that was run.

Name your test fixtures something other than the class or object they’re testing. For example, Foo.cs and FooFixture.cs.

Don’t skimp on tests if you’re in a hurry, it’ll come back to bite you.

Lastly, run tests regularly and always before publishing latest bits.

By: Jeremy Brayton

Jeremy Brayton — Thu, 25 Jan 2007 00:15:18 +0000

Thank you. I have a hard time coming up with adequate starting points for tests. It’s not that I’m an idiot, it’s just that I can change my mind about something 500 million times before I think it’s the right way(tm). I realize a lot of it is personal preference, but having it broken down severely helps. Having something like this to slap me into somewhat proper alignment is definitely a good thing.

By: Dave

Dave — Wed, 24 Jan 2007 21:05:36 +0000

That’s a solid tip. At very least “cohesive” assertions per test method, which should limit assertions (generally) to 1-5…

By: James Carr

James Carr — Wed, 24 Jan 2007 14:02:24 +0000

Good list. Another one I would add is “one assertion per test method.”

One thing that always bites me is seeing a a test where the first test method brings back an object and does 20 random assertions against it, and then it is copy and pasted for each test method, with the intent hidden somewhere along those 20 assertions.

By: DotNetKicks.com

DotNetKicks.com — Wed, 24 Jan 2007 05:07:56 +0000

Strategies for Structuring Unit Tests…

You’ve been kicked (a good thing) - Trackback from DotNetKicks.com…