Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Pex (don't ask me what it stands for, but the symbol, a shark, is because it is similar to the Latin word for "fish"... I think) - Pex is a great tool for checking out and debugging your code - even testing it. Want to find all those edge cases that you (and I include myself) are too lazy to look for? Then Pex is what you're looking for. It could be used as a TDD type tool, but it's much better at "after the fact" testing. Perhaps after your design is done and you just want to flush out some extra bugs.
Anyway, I took a training course a couple of weeks ago with Peli De Halleux and we got into the nitty-gritty of Pex and how it works. Unfortunately, for me, it was a use it or loose it proposition. I wasn't in a position to put Pex into practice immediately, so I've forgotten some of what Peli taught us. So I went to the Pex site and downloaded the latest version of Pex, which comes with some great tutorials. Wow, it's nice for us old-timers to see the tutorials in Word format - it prints out for leisurely reading so much better than web pages. I was going through the first exercise to refresh my familiarity with Pex and noticed that when I went to debug the generated testing code, it wouldn't run - gave me an error that it couldn't dynamically load my target assembly that was being tested - one of the two assemblies in the project. I still don't know why that happened - maybe it's me or maybe it will be fixed in the next version of Pex, but removing the reference in the test project to the targeted assembly and re-adding the reference to the first project did the trick. Now I can step through the code generated by Pex.
More on Pex later as I re-learn the tool and put it into real practice!