http://davybrion.com/blog/2009/08/increasing-functional-test-coverage-with-quicknet/ Trying to walk that thin line between intelligence and ignorance Thu, 29 Jul 2010 21:01:23 +0000 hourly 1 http://wordpress.org/?v=3.0 http://davybrion.com/blog/2009/08/increasing-functional-test-coverage-with-quicknet/comment-page-1/#comment-22441 QuickNet On Google Code | The Inquisitive Coder – Davy Brion’s Blog Thu, 03 Sep 2009 10:11:36 +0000 http://davybrion.com/blog/?p=1486#comment-22441 [...] Increasing Functional Test Coverage With QuickNet [...] [...] Increasing Functional Test Coverage With QuickNet [...]

]]> http://davybrion.com/blog/2009/08/increasing-functional-test-coverage-with-quicknet/comment-page-1/#comment-22249 kilfour Thu, 06 Aug 2009 00:52:02 +0000 http://davybrion.com/blog/?p=1486#comment-22249 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 <a href="http://research.microsoft.com/en-us/projects/pex/patterns.pdf" rel="nofollow">Pex patterns</a>. 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 <a href="http://research.microsoft.com/en-us/projects/pex/pextutorial.pdf" rel="nofollow">Pex Tutorial</a> 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 ;-) 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

]]>