Recently Microsoft research lab announced Moles stubbing framework that comes tightly with Pex (http://research.microsoft.com/en-us/projects/pex/). I really do not see profits in using Pex on real projects, but Moles is quite interesting.
Features of Moles:
1) It can create all types of test doubles except of mocks. Personally I do not accept mockist style of unit testing, so I consider absence of mocks as advantage.
2) It uses delegates to define behavior of test doubles. Like Moq does. Sweet :)
4) It can be used with any testing framework, like NUnit, MBUnit, xUnit. Of course it does – in other case nobody will use it!
5) And the last and most significant feature – it can replace any class with test double, even static one! Before this moment only one framework was to able do it – typemock for just 800 $ per license. They call such test doubles “Moles” and mole for DateTime.Now will look like:
Finally covering legacy code with unit tests will be not so painful :)
Links for farther reading:
http://angler.wordpress.com/2010/01/21/pex-and-moles-untestable-code-not-really
http://research.microsoft.com/en-us/projects/pex/documentation.aspx
http://research.microsoft.com/en-us/projects/pex/molestutorial.docx
http://research.microsoft.com/en-us/projects/pex/molesmanual.docx
Update: Answer to question "Is Pex (Test generation) really usefull tool?" is here http://stackoverflow.com/questions/2704669/is-pex-test-generation-really-usefull-tool
Features of Moles:
1) It can create all types of test doubles except of mocks. Personally I do not accept mockist style of unit testing, so I consider absence of mocks as advantage.
2) It uses delegates to define behavior of test doubles. Like Moq does. Sweet :)
var fileSystem = new SIFileSystem() { ReadAllTextString = filename => { Assert.AreEqual(fileName, file); return content; } };3) It uses pre-compile time code generation to create classes for doubles.
4) It can be used with any testing framework, like NUnit, MBUnit, xUnit. Of course it does – in other case nobody will use it!
5) And the last and most significant feature – it can replace any class with test double, even static one! Before this moment only one framework was to able do it – typemock for just 800 $ per license. They call such test doubles “Moles” and mole for DateTime.Now will look like:
MDateTime.NowGet = () => new DateTime(2010, 1, 20);
Finally covering legacy code with unit tests will be not so painful :)
Links for farther reading:
http://angler.wordpress.com/2010/01/21/pex-and-moles-untestable-code-not-really
http://research.microsoft.com/en-us/projects/pex/documentation.aspx
http://research.microsoft.com/en-us/projects/pex/molestutorial.docx
http://research.microsoft.com/en-us/projects/pex/molesmanual.docx
Update: Answer to question "Is Pex (Test generation) really usefull tool?" is here http://stackoverflow.com/questions/2704669/is-pex-test-generation-really-usefull-tool
3 comments:
Hello,
It's a good thing you cast a critical glance on Pex, too.
Personally, I see the big advantage of using it in the high code coverage in real projects because of the following things:
1. Code coverage: You get a near-to-100% code coverage automatically. Hence, you don't have to care yourself about writing for every branch of code and every possible flow of control testing behaviour.
2. Automatically created test suits. You don't write them yourself anymore - which is potentially less error-prone. Especially for a big code base this might come in handy.
What do you think?
I completely agree with you about your Moles part!
Btw, nice post! ;-)
Best regards,
Martin W. Angler
http://angler.wordpress.com
Hi Martin,
Thanks for your comment!
Yes, it is possible to generate tests on boundary values for functions like "Sum" or "Divide". Pex is a good tool here.
But more often we create tests on business behaviour. Let's consider example from classic Beck's tdd book:
[Test]
public void ShouldRoundOnCreation()
{
Money money = new Money(20.678);
Assert.AreEqual(20.68,money.Amount);
Assert.AreEqual(2068,money.Cents);
}
Can this test be generated? May be... The day when Pex generates such test will be the last day of my profession - it will do my job:)
95 % of tests in my projects check business logic, and can not be generated. That is why I do not belive in automated generation of tests at all.
As concerns to code coverage - Pex can give 100% code coverage, but "a high code coverage rate of a test suite does never indicate, that code is well tested".
Hi,
Thanks for the nice post.
I'm completely against test doubles of the static methods (what is one of the advertized advantages of Moles), since such need shows off some coupling issues in the code.
E.g. dependency on the DataTime.Now() method is a dependency on a global state, and the only right move here can be to abstract it into the Clock class.
Again, on code coverage. If you get your code covered 100% by automated tests, you get into the trap of zero maintanability of such tests, and zero value of them as documentation. Unit test shoud document the intent of the code, and not how it works internally - but this is what Moles force you towards.
Rgds,
Alex
Post a Comment