Issue
Imagine there is a CRUD (create, read, update, delete) test for a car object.
Is it best to have
[Test, Order(1)]
{
Create
}
[Test, Order(2)]
{
Read
}
[Test, Order(3)]
{
Update
}
[Test, Order(4)]
{
Delete
}
or
[Test]
{
Create
Read
Update
Delete
}
Both ways work, but I was wondering what the pros and cons are
Solution
This is one of those questions which can lead to opinion-based answers, but I think it can be answered fairly factually.
When writing a test, one assumes it's possible for it to fail - otherwise, why write it. If it fails, you need to know what went wrong. Assuming you give all your tests meaningful names, the first approach will tell you, for example, that update failed while the other three worked. That's in its favor.
In the second approach, you need to add messages that make it clear what failed. That's a minor inconvenience but the last think you want is to have to look at the stack trace to simply know that which of the four failed.
A compromise approach is to write it this way.
[Test]
{
Create
}
[Test]
{
Create
Read
}
[Test]
{
Create
Update
}
[Test]
{
Create
Delete
}
This is, in fact, what the old-timers of TDD have generally suggested. If your tests are as small and simple as they should be, the extra time needed to repeat some actions should be minimal, with a cost far below the value of the extra time you may spend figuring out what went wrong.
Under NUnit, for extra coolness, you can use Assume.That to ensure that each preliminary Create operation passes without generating extra errors.
As pointed out by @Ilya, your first approach makes it impossible to run a single test alone. By making the tests independent, avoid that problem.
So... make the tests independent and self-documenting. Everything else is actually a matter of opinion. :-)
Answered By - Charlie
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.