14

Has anybody tried any Unit Test generators for .Net?

I assume although it won't be any substitute for any good unit test written by a person who has written the functionality, but I think it will take away some of work and be a starting point on which we can better the unit tests.

Thanks.

Blair Conrad
  • 233,004
  • 25
  • 132
  • 111
Biswanath
  • 9,075
  • 12
  • 44
  • 58
  • +1 Pretty interesting overall question. I'm interested to use a test generator once in a while for tiny projects, and you question is relevant to what I was just wondering. – Will Marcouiller Nov 11 '10 at 15:40

4 Answers4

22

Unit test generation is the wrong way to perform unit testing. The proper way to do unit testing is to create test cases before you write functional code, then develop your code until the tests validate, this is know as TDD (Test Driven Development).

One of the key reasons unit test generation is a bad idea is because if there are any bugs in your existing code, the tests will be generated against those bugs, therefore if you fix them in the future, the bad tests will fail and you'll assume something is broken, when it's actually been fixed.

But since the code is written, it's now water under the bridge. And possible buggy unit tests are better than no unit tests at all. I've always preferred NUnit and there's a NUnit compatible test generator here (very affordable).

TravisO
  • 9,406
  • 4
  • 36
  • 44
  • 10
    Yeah it's the wrong way to do TDD, but if you are working with Legacy code it's a good foundation no? – Webjedi Dec 10 '08 at 18:30
  • @Webjedi. I don't think so. Writing the tests by hand will help you understand what the code is supposed to be doing. Running a test generator -- with the questionably readable code it would produce -- doesn't help with that. – tvanfosson Dec 10 '08 at 18:38
  • Exactly. How would a tool know what the behavior of your application is supposed to be? If you've got no tests, you're better off writing functional tests for the UI using WatiN or Selenium, etc – bryanbcook Dec 12 '08 at 04:39
  • 1
    +1 When employing TDD, you're right, a test generator is no use. However, when one is writing pretty simple classes as data reservoir, with no methods, which somehow sticks to the Façade and Factory Design Pattern, you may afford the use of a test generator. Besides, you have lightened my lantern with this response and shall consider a different approach. Thanks for the comprehensive answer. – Will Marcouiller Nov 11 '10 at 15:39
11

Have you considered Pex? It's from Microsoft Research.

Pex automatically produces a small test suite with high code coverage for a .NET program. To this end, Pex performs a systematic program analysis (using dynamic symbolic execution, similar to path-bounded model-checking) to determine test inputs for Parameterized Unit Tests. Pex learns the program behavior by monitoring execution traces. Pex uses a constraint solver to produce new test inputs which exercise different program behavior.

Pascal Paradis
  • 4,275
  • 5
  • 37
  • 50
  • Pex is worth looking at. I've found it useful for the growing list of extension methods we write, which up to now have gone untested. – Frep D-Oronge Dec 18 '09 at 09:57
5

Years ago I modified Haskell's QuickCheck to allow for purely functional Test Driven Development with generative tests. My solution was to save the PRNG seed for that generated a failing test case, and run future tests with that same seed.

I recently got a .NET job, and Google found that MbUnit did have support for generative tests in 2004. I also found the more recent Gallio, but I had some sort of trouble using it, I don't remember exactly what.

So, TDD and generative testing are not mutually exclusive, Gallio is the only recent .NET option I've seen, and I don't remember why I'm not using it now.

shapr
  • 1,676
  • 13
  • 18
0

I created ErrorUnit an unit test generator for .Net

Using a generator for TDD development is certainly practical; for instance in coding what happens on a button click, a way to use ErrorUnit in a TDD way would be:

1) First create a test manually to ensure there is a button press event; then create the event and test as per pure TDD.

2) Then run the program, navigate to the screen with the button, and with a breakpoint set in the event method, press the button

3) When the breakpoint is hit you can then click ErrorUnit's "Add unit test" to generate a unit test with all the objects and current database state already mocked. (Repeat as needed with different use cases states)

4) You would then alter the created unit tests to have an Assert to match the result of what you want the button click to do as per TDD .

5) Then write the code behind the click event, and run your test that is part generated by ErrorUnit (for the Arrange and Act) and part custom (for the Assert).

This way you save most of your time that would be spent typing the Arrange and Act.

ErrorUnit also works with Error Logging to reproduce errors in other environments by serializing and mocking in the unit test the exact state at the time of error; Bringing TDD to production issue resolution.

johng
  • 171
  • 9