Pex and Moles

  • Article

Yesterday I attended a class about Pex and Moles held by the authors of named tool(s). The first part was about Moles which is kind of like Stubs (which I've covered before) but more powerful. With Moles you can fake any method in any class. I'll say that again. Any method in any class. That is very powerful when working with external dependencies and especially when working with legacy code trying to add some more tests for it. Even while Moles is a very powerful tool that can result in bad code of used in the wrong situations it is very simple and straight forward to use. Not really any fancy API to learn as with most mocking frameworks; just simple delegate properties that can be set to override any method's behaviour. I think it's just as neat and clean as it is powerful. So when to use Moles? Simple; as little as possible. For code you own there is really no need to use Moles (but you may want to use Stubs which is now part of Moles). And for external dependencies you probably want to wrap them as usual but with Moles you can get pretty high coverage even on those thin wrappers.

Second part of the class was about Pex. Simply put, Pex is a profiler that tries to break your code by analysing execution and try several different inputs. It can also generate parametrized unit tests for this. While Pex can be used to create a minimalistic test suite that covers all paths of the code I think there are a few things that prevents me from using Pex for this; First of all I don't want to generate my tests after the fact. The minimalistic test suite is not very good as documentation for expected behaviour. And even though the code is covering all paths it is not covering all possible conditions in the code so I end up with one or two tests missing if there are complex conditional statements in the code. However Pex can be used to analyze a single method without actually generating any tests. That is where I think I'll find Pex useful in the future since it is a good way of finding out if there are any test cases that should be written.