Microsoft's Research in Software Engineering (RiSE) has been developing a pair of unit testing technologies for the past several years, named MOLES and PEX. Awareness and pre-market adoption of these technologies is being increasingly adopted by the programming community.
UPDATE: Please see the new Testing with Pex and Moles page, that contains links to all related posts!
What are Moles and PEX?Moles is basically an isolation framework that is used for mocking. Sure, there are plenty of great mocking tools out there, so why build another? Simply, Moles provides the mocks used by PEX. The neat thing about Moles is it doesn't just generate mocks -- it isolates and generates mocks and stubs of an entire assembly. This means stubs may be created for interfaces and non-sealed types, and mocks may be generated for static and sealed types and assemblies to which source code is unavailable. To prevent overwhelming the test harness with the mock of an entire assembly (particularly the .NET framework, mscorlib), assembly attributes may used to specify specific types that will be used in the test.
Moles works by using a host framework, identified by test method HostType attribute, just like ASP.NET unit tests. The host disassembles the type IL code, and injects a Func
PEX inspects all logical branches of the targeted code. From this information, PEX generates a series of unit tests that cover every logical branch possible. This method is able to generate tests for 100% code coverage, for many methods. Because PEX dynamically generates test code, you want to keep your hands off of it. Depending on the complexity of the code being tested, PEX may generate a large number of tests.
Including Moles and PEX in testing is surprisingly easy, especially when using the PEX and Moles Tools for Visual Studio. Moles may be used separately from PEX for stubbing and mocking purposes. Care must be taken to not overuse Moles, as its overhead is costly, so building stubs into application architecture is still advised.