"Writing Unit Tests" - What does That Mean - Specifically

[Jeremy]

I understand what a unit test is. No problem there.

What I'm wondering is what, specifically, do most of you more experienced
developers mean by "writing" a unit test. Am I correct to believe that you
are referring to some way you *document* your tests? If yes, can you provide
some example? Given the huge amount of unit tests that go on with any non
trivial application dev project I'd like to think that there is some
standard template that you follow (home grown, as it may be). At least
that's what I'd like to come up with as I try to improve my programming
habits.

Thanks!

 

[wfairl]

Look into NUNIT (nunit.org) or a similar unit testing framework. You'll
actually create (write) test classes.

 

[jeremiah johnson]

Writing a unit test involves writing code that tests your existing code
for faults.

the classic example is to use some unit testing framework to verify that
the example add(int a, int b) method actually returns the correct answer.

in Java it goes like this:

public void testAdd() {
int a = 5;
int b = 4;
int result = add(a,b);
assertTrue(result == 9);
}

I assume it would be very similar for C# and NUnit. It is all pretty
simple. the assertTrue means that if that add method does not return 9,
assert.

asserts are often used in C when you want to make sure that a condition
is met at some point in your code, thus the NUnit and JUnit method names.

C# and Java are close enough in design that you can glean quite a bit
from JUnit tutorials if you can't find sufficient NUnit documentation.
I'm sure you'll find enough NUnit stuff though.

 

[John B]

Writing a unit test involves writing code that tests your existing code
for faults.

the classic example is to use some unit testing framework to verify that
the example add(int a, int b) method actually returns the correct answer.

in Java it goes like this:

public void testAdd() {
int a = 5;
int b = 4;
int result = add(a,b);
assertTrue(result == 9);
}

I assume it would be very similar for C# and NUnit. It is all pretty
simple. the assertTrue means that if that add method does not return 9,
assert.

In c# and NUnit I would write this as:

[Test]
public void TestAdd()
{
Assert.AreEqual(9, add(4,5));
}

Cant remember from JUnit but NUnit will return an error message in the
form of:
Expected: <9>
But was: <5> (If add returned 5 instead of 9).

To me that is clearer than the blank message that gets raised if you
dont specify a message or since I modified my NUnit (gotta love open
source) so all Assert methods call AreEqual (Almost) so the message
would be:
Expected: <True>
But was: <False>

Cheers
JB

<...>

 

[Jon Skeet [C# MVP]]

I understand what a unit test is. No problem there.

What I'm wondering is what, specifically, do most of you more experienced
developers mean by "writing" a unit test.

Personally, I mean writing the code for a unit test, along with any
comments in/around the code which are required to understand what it's
meant to do.

Am I correct to believe that you are referring to some way you
*document* your tests? If yes, can you provide some example? Given
the huge amount of unit tests that go on with any non trivial
application dev project I'd like to think that there is some standard
template that you follow (home grown, as it may be). At least that's
what I'd like to come up with as I try to improve my programming
habits.

Well, there tend to be naming conventions, but that's about it. I tend
to name my test classes after the class they're testing, but with
"Test" at the end (FooTest testing Foo, for instance) and I tend to
have an instance variable called m_subject of the type I'm testing, but
there's no much beyond that.

Different people will tell you different things about whether to have
the unit tests in the same assembly, but not compiled in release mode,
or to have them in a different assembly. I'm a "different assembly"
guy, although that does make things harder as you can't test internal
members and can't make members available just for testing (other than
with .NET 2.0's "friend" capability).

 

[Steven Nagy]

So Jon, if you're a "different assembly" kind of guy, what are the
advantages?
You only pointed out the disadvantages of doing it that way, but there
must be a reason you continue to do so.

Is it simply because the test cases are more manageable in their own
assembly?

 

[Jon Skeet [C# MVP]]

So Jon, if you're a "different assembly" kind of guy, what are the
advantages?
You only pointed out the disadvantages of doing it that way, but there
must be a reason you continue to do so.

Is it simply because the test cases are more manageable in their own
assembly?

That's one aspect - but the main one is that I know that I'm really
running the unit tests against the genuine code. I can take the same
assembly that I'll ship to customers and unit test that, rather than
building two versions, one with the tests in and one without, and
hoping that all the production classes in the shipped version are going
to work the same as they did in the test version.