in Search

Do you Twitter? Follow us @CodeBetter

Ranjan Sakalley

TDD with Whidbey (Team Test)

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).

Published Apr 29 2005, 06:59 AM by rsakalley

Filed under: C# 2.0

Comments

Raymond Lewallen said:

Like you said, it appears as though the code gen will need a lot of work to become usable. I'd hate to thing that it might ship like this and developers come to rely on the functionality and test cases it provided.

For somebody like me who practices Red-Green-Refactor, it appears to have no value at all, at this time. Perhaps that will change.

# April 29, 2005 8:20 AM

Sam said:

I think you're using TDD in place of UnitTesting a lot. TDD is kinda a binary decision I think. You either test-first, or you test-after. There's not really a middle ground here. It can be tempting to claim so, but the whole point of TDD is Design. How are your tests guiding your design if you're even writing anything as basic as method signatures first?

Not that a lot of people can't come up with designs using code-first that are better than mine using TDD.

# April 29, 2005 9:16 AM

rsakalley said:

Sam,
I think TDD is something that's an upgrade for me over unit testing. For me :).
It makes me improve my design when I design for testability, and its majorly because I consider the design aspect even when I am concerned about a simple name change. It makes those decisions big, and makes me more concerned. Makes me confident when the test passes. Continuously testing makes me keep track of my mistakes. So yes, TDD is a binary decision, I do it, or I do it not. I prefer to do it, because of its obvious advantages, because I feel confident when my test case passes.
I think you might have misunderstood me, when it came to generation. It is easy to misunderstand, because you and me know that testing afterwards, means testing logic. That means Unit testing. not TDD. I agree. But at one point of time, you also need to understand that TDD is not just "writing test case first". Writing the method signature first and then testing is not wrong.
Refactor when required. Thats why you need to refactor, because you change your design time and again. To satisfy the present design decisions, you refactor the code written in the past. Refactoring has more reasons that need not be mentioned here, but this is one of them, and a pretty important one too.
Generating test cases are not wrong.
You need to consider the fact that the person writing buggy code, might write buggy test cases too, can't he? I know thats a funny argument. Drop it, or take it. But as a Manager, I would really need to keep a certain pace of development, I would need machine generated test cases, for the ones that tend to repeat themselves (like I mentioned in the post, parameter testing etc.). Developers tend to copy and paste the test code accross testfixtures for these, which in my experience is more of a problem than a solution.

Drop me a mail sometime, I would really like to talk to you, I think it would be great learning experience for me.

Thanks again for the comment.

# April 29, 2005 10:26 AM

Anonymous said:

"But you need to buy the Team Test edition of the Team System. Sad."

Actually, unit testing is included in Visual Studio Team Edition for Software Developers, Visual Studio Team Edition for Software Testers, and of course, Visual Studio Team Suite.

Ranjan Sakalley

TDD with Whidbey (Team Test)

Comments

Raymond Lewallen said:

Sam said:

rsakalley said:

Anonymous said:

NeVaL said:

Smułko said:

dobloo said:

volf said:

volf said:

Leave a Comment

Our Sponsors

This Blog

Syndication

Recent Posts

Tags

News

Other writings

Archives