Increasing Functional Test Coverage With QuickNet

Thanks for the link. Both your suggestions are on my (rather large) todo list
About the difference with Pex, there’s a short answer : Pex is a parameterized unit tester, QuickNet is a property based tester that models a program (or model, class, method) as a finite state machine.
Part of the long answer :
Recently Peli de Halleux published a paper with Pex patterns. The State Machine pattern on page 13 might seem familiar to anyone who has read the QuickNet preview (QN was born about a year ago btw, around the same time Pex made it’s first steps, I think we all saw the same talk By J.H). But look at the amount of classes and code, imagine having to string together a large number of transitions, or deal with a transition in one class that changes the state of another class. This will get out of hand. Pex is a unit tester, not really designed to handle state, but to make input generation as painless as possible. QuickNet is designed to handle both unit tests and integration tests (state).
In the Pex Tutorial chapter 6 it is mentioned that ‘Abstraction from the environment is necessary if you want to have a Pex-testable design.’. Now I truly agree that ‘Abstraction from the environment is necessary’ in order to have good code and if the program was developed in a TDD fashion, it probably has this feature, but in reality a lot of programs do not make this abstraction and I still want to test those. And I want to test them BEFORE I refactor them. QuickNet allows me to do that even if it touches a database or a filesystem or whatever.
I’m sure Pex derived it’s ideas from QuickCheck aswell just as QuickNet does (the Oracle in the example kind of gives it away ) but they changed a couple of basic premises.
Too long a comment already so I’ll keep the explanation of the last statement for a post on my own blog