Is Pex (Test generation) really useful tool?

Question

Yes, it is possible to generate tests on boundary values for functions like \"Sum\" or \"Divide\". Pex is a good tool here.

But more often we create tests on business be

Answer 1

There's a few things useful in Pex.

1. Code coverage. Let's put Pex aside for a second. In general, 100% code coverage doesn't necessarily mean you have good code coverage. It just means ever path is executed, but program has data-flow, and testing that code different, additional inputs, gives you best "test coverage", if not code coverage. Here's, I'm just reiterating your point. 100% code coverage is not necessarily good, but you can say for sure that 25% code coverage is bad, so that's how code coverage is useful. When you have low code coverage, you know for sure you have low test coverage.

   When you use Pex to get 100% code coverage, it's not really helping you get better test coverage per se, but what it does do is give ever piece of the production code some test, which can be used for debugger. In fact, a Pex presentation as a conference shows the use of Pex for this very purpose. The programmer said, "Gee, look at this method in NHibernate. I'd like to step through it in a debugger to see what it does, but how do I even invoke that method through the normal "business-entry point" into the library? Without knowing anything about the library, you can't. So he ran Pex, and was able to step through the code with all sorts of parameters. Interesting, Yes. Useful, maybe so, maybe no.

2. In addition to automatically created tests, Pex is also useful for parameterizing your tests. It's much better to create unit tests that are data driven. Why write the same code over and over, with different parameters. Write it once, and feed the parameters from a data source.

3. Pex is also useful as a simple stubbing framework. It's probably the easiest way to create mock objects, using the new lambda expression, which is much easier to understand than complex frameworks like RhinoMocks, etc. With Moles, you can also stub not just interface, but concrete non-virtual methods in classes.

4. I would also be careful with the "testing at the business logic" layer, too much. You could easy get to doing Behavioral Driven Development, which is not for unit testing. There, you are testing against a spec. If that's all you did, how would you test, say, custom data structures, etc., that have no business value, but are internal libraries used throughout the application.