I came across this Microsoft Research via Peli's Farm. This looks like a cool idea at first glance but as I think about it I'm not sure it's a good thing. It definitely helps for parameter validation but I'm wondering if a tool like this may just give developers a false sense of security.
I should qualify that I'm nowhere near a TDD guru (although I _am_ working at it). But how would a tool like this actually be able to verify the desired functionality when the developer doesn't really know what values the method will be called with when the test runs? On the other hand I do know that bugs come out when a method encounters values not anticipated by the developer. Maybe this tool has it's place as a "catch-all" for when the developer has written a bunch of unit tests to cover all the cases that they can think of. They can then "add on" Pex to get that extra bit of coverage and ensure that their code is being exercised fully.
2 comments:
"How would a tool like this actually be able to verify the desired functionality?"
In fact, the tool still relies on the developer to write assertions and verification code in it's test. For Pex, an assertion is yet another piece of code that it will try to cover (in an assert, there's the branch that succeeds and the one that throws). Therefore, Pex will try to compute inputs that will fail the assertions.
Note that the 'Pex' approach is not exclusive, one can still add more unit tests at the end of the process or do the TDD process with classic unit test, then refactor them to parameterized tests to see if Pex finds something interresting.
Thanks for that clarification Peli. :-) This begins to sound like a more useful tool for unit testing.
Post a Comment