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!