Skip to main content


Showing posts from March, 2011

Mock Roles not Types

"if it feels wrong, it probably is" - numerous Codeweavers' developersThe framework we use at Codeweavers is the excellent Moq, therefore when something is difficult to mock we are forced by the framework to write an adapter. We use an interface for testing, then create a concrete type which simply invokes the hard to test code such as static code, third party libraries and resources that are expensive to set up. There are some ways ways in C# to get around this, but they involve black magic and should be avoided at all costs unless you are deeply entangled in legacy code. A refactoring would be preferable over hard to test code.The process of writing an adapter around hard to test code is a standard practice, we do it all the time as we are forced to by the unit testing framework. Some frameworks we use at Codeweavers such as ASP.NET MVCare designed with testability in mind, so unlike scenarios where you cannot test code…

MBUnit to NUnit

Over the last few weeks we've ported our tests from MBUnit to NUnit. This was done as after a quick spike it was seen that NUnit tests run almost fifty percent quicker. For example our common projects' test time went from around 40s to around 20s on average.This whole process was no easy task. Initially our largest project was converted by the whole team. We split into pairs/individuals and tackled a test project each. Working in this manner we could commit after each project, meaning at any one time the build was only fractionally broke, rather than completely unbuildable. Previously we tried a big bang approach but after several thousand errors, we quickly reverted. After each commit the tests were gradually moved over. This took around an hour or so, and therefore our allocated dojo/technical dojo time for that week was used. For the remaining projects an ad-hoc approach was taken. The first pairs to work on a project would …