10 Comments

  • Nice article Roy. You really covered this in a nice introductory way. I especially like how you didn't start with NUnit, but showed how to do it without a harness. Nice.



    One thing that you missed is the refactoring phase that really should happen after getting a test to go green. That is the point at which you can feel safe about aggressively refactoring because you have tests to prevent you from messing anything up.



    Looking ahead, I'm interested in how you intend to address "Testing abstract classes". From a pure TDD standpoint, you don't test abstract classes directly. Abstract classes come into existence due to a refactoring phase. Typically when you find some duplication between two classes that you wish to refactor out, introducing a common base (abstract) class is one choice.



    If your tests of the concrete classes were complete enough, then you will get coverage of the base class for free.



    Nice work,



    Peter

  • Peter. Thanks for reading. I didn't show refactoring explicitly because refactoring is a process which has its place in more complex examples. I do intened to show the benefits of TDD and how refactoring fits into this nicely in the next article.

    As for testing the abstract classes, it really depened on the situation. Sometimes abstract classes are introduced early in the design phase and not after refactoring. This comes into play mostly when you design and implement frameworks for others to build on. That article will show, among other things, how using Mock objects, derived from the abstract class can help test inner workings and assumptions, but I don't want to give it all away now, do I? :)

  • Great article Roy! I'm starting to use NUnit and TDD and I've found a lot of interesting starting points. I'll wait the others!!!

  • RE: Refactoring



    I guess my point was that if you do TDD without refactoring, you are only doing half of the process. Sure, refactoring is a large concept but the 5th step of TDD is "Remove Duplication"... i.e. Refactoring. If you only do the first two, you will leave duplication all over the place.



    RE: Abstract Classes and Mocks



    Sure, I suppose that you need to introduce mocks if it is your expressed purpose to expose abstract classes in a framework for other developers. But if you have implemented a basic concrete class that extends the abstract class, then thorough testing of the concrete class should equal thorough testing of the abstract class.



    Also, a number of authors have been noting on the TDD Mailing List lately, that in general the use of mocks should be considered a code smell. If you HAVE to use mocks, perhaps the code isn't clear enough. I'm not sure how I stand on that particular issue, but it certainly makes you think.



    Again... excellent work.



    Thanks.

  • Thanks Manfred.

    I definitely did not know all those things.

    Thanks for the clerification :)

  • Good article Roy... thanks..

  • Not too sure about the timing of the 'Refactoring' - I would think it would be post-initial development (at least, not before the alpha stages). Otherwise, coding may be too constrained. I recall peer-coding reviews where the compiler warning switches were set very high (level-5 in the old MFC/VC++) but this was 'automated' and 'refactoring' can still be a bit subjective...

  • can I have all the methods in one file so that its easy to understand and use it as a reference while coding.



    thank you

  • Raj - I'm not sure what you mean.

  • Hi ,

    Im trying to use "TestFixtureSetUp" in my project and I'm getting this compilation error.

    The type or namespace name 'TestFixtureTearDown' could not be found (are you missing a using directive or an assembly reference?)



    I've included the NUnit.Framework.dll in my Reference list.

    I also have "using NUnit.Framework" in my code.



    I've installed the NUnit add-in for VS .NET 2003. created this project as "NUnit test" project.

Comments have been disabled for this content.