Comments on: Getting value out of your unit tests

By: Daniel Fernandes

Daniel Fernandes — Mon, 10 Aug 2009 17:40:28 +0000

Validation tests are bit of a pain and I don’t have much of a problem with multiple assertions as long as it’s easy to know what’s tested, there aren’t too many assertions and the context is explcit.
There may be situations that instead of having to create small unit tests that try testing individual rules, the business representative would submit valid test cases and expected outcomes for the validation. This is similar to Fit but you simply embed those test cases.
Daniel

By: bogardj

bogardj — Mon, 27 Jul 2009 12:48:27 +0000

@Gil

This example wasn’t so bad, but I’m sure you’ve seen ones where you have a bazillion assertions, and even worse, lots of setup-execute-verify in one test. Instead of thinking about it, I tend to just break up tests. It’s easier than deciding for me.

By: Gil Zilberfeld

Gil Zilberfeld — Sun, 26 Jul 2009 11:06:56 +0000

Jimmy,

Thanks for the great article.
Taking Mark’s example and your response: The name of the test is vague enough to include the properties. If I read the test I understand when the user name is invalid. Keeping them together, allows me to conceptually relay that they go together.Granted, that from code maintenance point of view, the separation is needed.

But from the POV of someone new, or someone visiting the code after 6 months, wouldn’t this test convey more?

Thanks

Gil Zilberfeld

By: Jason Olson

Jason Olson — Sat, 20 Dec 2008 07:50:39 +0000

A style I’ve liked lately is the idea of having a folder named after concern of the application. Then the test class/fixture is named after the context (WhenNewStackIsCreated, for instance), and then the tests are essentially the assertions you are making (ItShouldBeEmpty(), ItShouldNotBeIndexable(), etc.).

Then, the constructor of the test fixture (at least in xUnit.net) sets up the context that every single test will run under.

I personally find that this way of thinking helps organize my own thoughts on what I’m testing. And it often leads to test fixtures that are smaller (since they are about a specific context), and each test has a minimal number of asserts. Combined with AAA (Arrange/Act/Assert) style testing, it’s a methodology I’ve come to love.

Just my $0.02.

By: bogardj

bogardj — Fri, 19 Dec 2008 14:53:41 +0000

@Mark

One assert per test. If you have a common context/setup, like this one, pull that into its own setup method, or test fixture class, and have tests for each assert, with good test names describing what the user experience should be.

By: Mark Levison

Mark Levison — Fri, 19 Dec 2008 14:36:27 +0000

What about this case:

[Test]
public void EmptyUsernameShouldNotBeValid()
{

var user = new User();

user.Username = ” “;
user.IsValid.ShouldBeFalse();
assertEquals(” “, user.getName());

}

This is a lousy example – but I often find useful to assert two or threes properties of an object, based on calling on a single production method.

In some cases maybe I want to assert invariants.

By: bogardj

bogardj — Fri, 19 Dec 2008 14:01:20 +0000

@Micha

Yep, that’s much more like it.

@Frank, @Tosh

Workin on it, thanks for the heads up!

By: Tosh

Tosh — Fri, 19 Dec 2008 12:51:07 +0000

I’m with Frank: add some more value to the post by including examples of good or excellent tests that address the issues pointed out in the article.

By: Michael Reuß

Michael Reuß — Fri, 19 Dec 2008 12:11:36 +0000

Following rule #1 I’d go for

[Test]
public void EmptyUsernameShouldNotBeValid()
{
var user = new User();
user.Username = ” “;
user.IsValid.ShouldBeFalse();
}
etc.

Right?

Micha.

By: Lee Brandt

Lee Brandt — Fri, 19 Dec 2008 08:27:05 +0000

@Frank: This would be my stab at it. If this is what you’re asking.
[Test]
public void ShouldValidateUsername()
{
var user = new User();
user.Username = ” “;
user.IsValid.ShouldBeFalse();
}

@bogardj
Great article. Great points. For me, BDD has been the language shift that pulled me away from my bad TDD habits. I think the reason people get sucked into the fixture/class pattern is it makes them feel safe about code coverage. If they make one fixture per class and one to n tests per method, they’ll have great coverage. This, of course, leads to the problem you explained above of leading you away from the REAL purpose of TDD which is to verify and document the behaviors of the system.

Always enjoy reading your posts,
Lee