This post originated from an RSS feed registered with .NET Buzz
by Ranjan Sakalley.
Original Post: TDD with Whidbey (Team Test)
Feed Title: Ranjan Sakalley
Feed URL: /error.htm?aspxerrorpath=/blogs/ranjan.sakalley/rss.aspx
Feed Description: (the life and times of a mock object)
Honestly, its good to
have a test generator right there in your own sweet copy of VS.Net. But
you need to buy the Team Test edition of the Team System. Sad. In the
past, I have argued with many people about generated test cases, from
people who have written books on TDD to normal people like me, and all
their arguments were centered on "You will lose the control"/"Whats the
use of TDD then?"/"What about test first and code then?". Except for
the last one, these are very much similar to the ones which came
forward when people cried about why "Drag Drop"/"Visual Studio
Generated code" for VB(of which i know nothing) and other languages
(and this was my argument :) ) . Ofcourse every geeko will take their
time criticizing this feature, embracing it later one way or the other.
Paying for it too. Sad.
Personally I hold the last point, namely "test code first and then
code" to be the strongest argument out there against code generation. I
have thought about this a lot, and though I understand that I am no
high authority in this world, I find myself thinking that its just a
philosophy. And as any other philosophy, there are better and more
personalized ones out there. Which broadly means that as and when I
find myself in a situation where generation speedens my development
process, I shall use it, no matter what people say. Good old test first
is correct, and it shall carry on, with a little personal twist on my
side.
Wait, I have one more argument! Most of the people think that TDD cases
are just a way to verify the "correct"ness of the code, by developers.
No. Not just that. TDD cases, i.e. code written to test code actually
opens up a new perspective towards quality verification by third
parties too namely the QA teams. They tally their use cases with the
test cases, write extra if there are none there for the use-cases. They
are not developers (which is sad, and they earn more than developers,
which is sadder still) so they normally work on written code. What of
them?
So test generation is ok by me, because it serves a purpose. If handled
correctly. Sad.
Handle it correctly.
Here is some insight I might provide. Darrell has already written about
how to re-use your NUnit test cases ( I really wish MS had supported
this rather than creating their own, with Mr.Newkirk right there in
Redmond) here
(http://codebetter.com/blogs/darrell.norton/archive/2004/06/17/16811.aspx).
In brief, almost all attributes, asserts and static calls are
supported. So you just need to change one "using" line. And so, I will
try to concentrate on the generator.
Lets take a class that needs to be tested.
namespace Tested
{
public class Math
{
public int Add(int firstNumber, int secondNumber)
{
return firstNumber + secondNumber;
}
}
}
Generated test class for the Add method is-
using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework;
// The following code was generated by Microsoft Test Code
// Generation V1.0. The test owner should check each test
// for validity.
namespace Tested
{
///
/// This is a test class for Math and is intended
/// to contain all Math Unit Tests
///
[TestClass()]
public class MathTest
{
///
/// Initialize() is called once during test execution before
/// test methods in this test class are executed.
///
[TestInitialize()]
public void Initialize()
{
// TODO: Add test initialization code
}
///
/// Cleanup() is called once during test execution after
/// test methods in this class have executed unless
/// this test class' Initialize() method throws an exception.
///
[TestCleanup()]
public void Cleanup()
{
// TODO: Add test cleanup code
}
private TestContext m_testContext = null;
public TestContext TestContext
{
get { return m_testContext; }
set { m_testContext = value; }
}
///
/// AddTest is a test case for Add (int, int)
///
[TestMethod()]
public void AddTest()
{
Tested.Math target = new Tested.Math();
// TODO: Initialize to an appropriate value
int firstNumber = 0;
// TODO: Initialize to an appropriate value
int secondNumber = 0;
int expected = 0;
int actual;
actual = target.Add(firstNumber, secondNumber);
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
}
}
Stop tinkering about my color coding scheme. I am color blind. Concentrate. We need to do this correctly.
You can yet again read about the attributes at msdn2.microsoft.com
(wait, there are no descriptions there, and may be that's why I am
telling you to go there.) Let me try -
[TestClass] = [TestFixture]
[TestMethod] = [Test]
similarly [TestInitialize] [TestCleanup] are mapped to the
corresponding SetUp and TearDown attributes. ( naming something
differently does give you a copyright, am I right?).
So the test case looks like -
public void AddTest()
{
Tested.Math target = new Tested.Math();
// TODO: Initialize to an appropriate value
int firstNumber = 0;
// TODO: Initialize to an appropriate value
int secondNumber = 0;
int expected = 0;
int actual;
actual = target.Add(firstNumber, secondNumber);
Assert.AreEqual(expected, actual);
Assert.Inconclusive("Verify the correctness of this test method.");
}
TODO's are I
think very nice, I need not run around trying to find out where to
initialize to an appropriate value. I call it the VB touch.
"expected" and "actual" are pretty descriptive names. Then there is the
regular assert. And then there is Inconclusive, which is basically
there to notify you to write a conclusive test case (by commenting the
line? ha)
Anyway, what my point is (listen, its not very hard to understand), is
that I fight all those people, tell everybody how good generating test
cases would be, and all I get is ONE test case?
Who will write the test cases to check the method input parameters? Who will write the test cases with expected exceptions? Where should I define my own test template, and then the generator generate the test cases based on that?
Like you would have guessed, this test case generator is inconclusive.
Its got nothing yet, and I hope it would be improved. Till then, I am
happy to write my own test cases, and write them first. (Do look into
the tests generated for the private methods. Really a great
implementation.)
Anyway, I am just one in more than a million, so the VS.Net team might not even notice this, and so......
Lastly, I am not color blind. I am just lazy (as you would have guessed too, by now).
Previous Topic
