Beta 2 comments

Simon Fell
  • Simon Fell

    Simon Fell - 2001-11-30

    I've just spent the last couple of days looking at NUnit, one thing i really liked in there is the reflection driven discovery of tests.

    I think the attributes approach is better, although i don't think there's a lot between the two.

    • Drew Marsh

      Drew Marsh - 2001-11-30


      From the discovery point of view, I agree, there's not a big difference between checking for the existence of an attribute vs. checking if something suclasses TestCase. However, fewer people are actually going to be writing test browsers and drivers. It's when you look at it from the unit test writers point of view that I think the attribute based approach greatly simplifies the creation of test fixtures/methods as well as reduces the overall time spent creating tests, letting the developer focus more time on his/her domain specific development.


      • Simon Fell

        Simon Fell - 2001-11-30

        I'm not entirely sure i agree, i compared your sample tests against a demo NUnit test [which uses inheritence], The inheritance methods requires you to type an additional

        : TestCase
        public TestClass(string n) : base(n) { }

        per test class [not test case]. Doesn't seem like a train wreck to me. IMHO the dynamic disovery of tests in NUnit far outweights this.

        • Drew Marsh

          Drew Marsh - 2001-11-30

          Well... I never said it was a "tran wreck"! ;)

          I'm not trying to put NUnit down in anyway, shoot... how can I? It's a port of one of the most popular, proven ways of unit testing: JUnit. Obviously it works well for many developers.

          For comparison, here's are the major differences between the two architectures:

              For Unit Test Writers:
                  - subclass TestCase to define a test fixture
                  - override SetUp/TearDown for per test method initialization
                  - define test methods by defining public methods in the class which are prefixed with "Test"
                  - apply one or more ExpectedExceptionAttribute for scenario where an exception is required
                  - no standard traversal mechanism for test heirarchy

              For Unit Test Writers:
                  - mark test fixture class with TestFixtureAttribute
                  - put initialization/cleanup in contructor/finalizer (support for IDisposable coming in next version!)
                  - define test methods by defining public methods in the class and marking them with TestMethodAttribute, which also allows, but does not require additional information to be supplied about the test method
                  - set the ExpectedExceptionType property of the test method's TestMethodAttribute
                  + allows parameterized test methods which enables you to define a single test method and call it with varying inputs per test case
                  - standardized traversal mechanism for test heirarchy via heirarchical visitor pattern[1] (see TestVisitor)
                  + allows static test methods to avoid the overhead of instantiating the test fixture everytime the test method is run if there's no need for test fixture state within a specific test method

          I do kinda have one gripe with the J/NUnit architecture in the way it blurs the distinction between what a test case is and what a test fixture is. I won't go into it here, but I believe that a test fixture and a test case are two distinct things. Check out this link[1] for more details.

          I don't expect many developers, who are looking to write unit tests tomorrow, are going to jump ship to .NETUnit, because there isn't even a public test driver yet. However, I obviously do think that this approach is an improvement over today's existing unit testing frameworks and that once I get some more samples out demonstrating the various aspects of the framework it's benefits will become more apparent. At the end of the day however, both frameworks get the same job done... it's just a matter of preference.



          • Simon Fell

            Simon Fell - 2001-11-30

            Wow, that's a lot of comments to type in the little box ! <g>

            Thanks for the comparision to NUnit. In reading the CppUtx page, it talks about a TestFixture and a TestSuite, yet these appear to be the same thing ? One thing i didn't get from the doc is why the HVP is better ?


            • Drew Marsh

              Drew Marsh - 2001-11-30

              Hahah, tell me about it. The *worst* part is that I lost them the first time I tried to post! :( The second time around I was smart enough to work on them as a text file locally and then just paste in. ;)

              A test fixture is *usually* just a way to group together a bunch of test methods which test one specific class or system. A test suite is a container that can contain test cases from many *different* test fixtures as well as other, nested test suites. Like J/NUnit, there is often a one to one correspondence between a test fixture and a test suite, but also like J/NUnit you can construct a test suite composed of test methods from many different fixtures. So, there's really not much of a difference between the two architectures here... just that J/NUnit tend to blur the two a bit.

              In NUnit, for example, it's the difference between instantiating a TestSuite via the TestSuite(Type) constructor, or instantiating it with just a name and adding tests via AddTest. Currently, a .NETUnit TestSuite has no similiar constructor, because building test suites is left up to the test driver implementation.


    • Anonymous - 2001-11-30

      I'm very interested in implementing unit testing in our new project (4 developers), having never done it before.  I have a few comments after having looked at NUnit, perhaps you can help me with some comments about testing in general or .NETunit.

      1.  It seems to me that NUnit (and .NETUnit?) are designed exclusively for automated testing.  This is ok in as far as it goes, but is not possible in some circumstances - like routines that do database access or file reading which will vary on input data. 

      Am I looking at unit testing the wrong way, or should these issues be handled seperately?

      2.  If unit testing can really only be used on the algorithmic/calculatory parts of a project, in a generic user-driven application is it actually of much practical value?

      As someone that is looking to formalise our testing procedures I am interested to hear your comments.


      • Drew Marsh

        Drew Marsh - 2001-12-01


        Here's some breif answers to both:

        1) There is functionality in .NETUnit that enables parameterization of test methods for test cases. Basically this means that, based on how the test driver is written:
          a) read different sets of parameters from a script and create/run a test case per set
          b) have a UI where the user can actively select the set of parameters and press a button to create/run a test case for that set

        2) This is true. J/NUnit and .NETUnit are designed mainly with regression testing of component systems in mind. You should check out this page[1] for more details on the various kinds of unit tests that exist and what solutions are out there for each kind.




Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks