Unit test case generator [closed]

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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