The new field mock feature that enables developers to mock fields has raised the questions:
- Who needs to mock fields, (only bad programmers)?
- Does Typemock advocate bad design?
- Is Typemock too powerful?
Advocating Good Design
Well, lets get one thing straight. I do advocate good design, the design of the software is an important factor and one that I spend a lot of time on. I don’t advocate bad design. But this has nothing to do with testing tools.
Separation of Concerns
Mixing the abilities of tools is not a very good idea, I can give you numerous examples: One is my friends combined DVD/VCR that didn’t last long, the DVD had missing functionality that made the machine obsolete. Having your testing tool and design tool in one can lead to the same results.
I believe in Separation of Concerns – the testing tool should help you test your software and give you the confidence that you code works, it should not (as much as possible) force you (or help you) to design your code. The design tools (refactoring) should enable you to design your code in a better way, it should not test your code. Testing and Designing are different mind-sets. When you are testing your code, you are thinking about the external API and the scenario that you are testing – trying to make the code fail. This is a different mind set then when designing your code, where you need to see the higher picture and how to put all the pieces together. That is why TDD has 3 different steps: Test, Code, Refactor! (Where Refactor is the Design process)
So what about mocking fields
Enabling Field Mocking comes from the same philosophy: Let the developer test his code. There is such a beast called “public fields” in .NET and there are some teams that use them and need to test their code. To give them confidence in there code, we can create pragmatic tools that will enable these team to test their code base and thus help these teams become more agile. If we tell these teams that they cannot test there code unless they conform to one certain design, these teams will not become agile as the bar is too high.
And what about design
There are many tools that developers can use to design there code (before or after writing tests), from static code analyzers like fxCop to refactor tools like Visual Studio and Resharper, and of course code reviews (and pair programming) which I believe are the best tools for design.
Once you separate the testing phase from the design phase you will have the freedom to make the correct balance and thus the best design, Typemock actually helps you get BETTER designed software. As long as you start thinking about the design seriously (by ruthlessly refactoring) and stop relying on your testing tool to do your design for you.