Apr
27

Why Typemock-Isolator for TDD?

Author Eli Lopian    Category .NET Tests, TDD     Tags

There is a long discussion in the ALT.NET group about TDD and Typemock, it is very interesting and I suggest that you read the thread.

Benefits of TDD

Although the benefits of using TDD are inconclusive, here are some benefits attributed to using TDD:

  • Developers write more tests
  • Tests use the API, so developers can get early feedback on the API design
  • Developers have more Focus as the tasks are divided into small chunks

image

Why do we need to Mock?

In order to use TDD effectively the tests must

  • Run fast.

  • Run in isolation.

  • Self Contained.

  • Race Safe.

  • Independent.

In order to make sure that we have fast tests, that the tests are self contained and don’t rely on external resources, we need to test our code in isolation from the rest of the system. This is done by mocking out components that are not part of our test, and testing only the unit logic.

image

TDD and Typemock-Isolator

So where does Typemock-Isolator fit in and how does it compare to other frameworks?

When using TDD with legacy code or 3rd party libraries, the benefits of Typemock-Isolator are well known, so I will not talk about those area’s but about green-field projects.

Developing with Typemock-Isolator, developers will be able to do all the stuff the other frameworks and manual mocks/stubs allow with the addition of being able to mock static methods, private methods and types and a chain of calls (fluent interfaces) in one go (As well as better integration with Visual Studio).

These features make it simpler to divide the code into small chunks – leading to more focus and more tests.

The API’s are still reviewed as tests are written using the API so early feedback of the API’s are part of this process. This is achieved with the freedom to use any internal design of the unit: Extension Methods, Linq, Fluent interfaces, Singletons and Factories.

Other frameworks will force the developer to use DI as an internal pattern. This might be good, but might not be good. It might leave public API’s that where not meant to be public. It will leave the ability to inject an alternative implementation that might ruin the system. It will probably lead to developing extra functionality to support validating and error handling of the injected components. This might be a YAGNI smell that will require extra development and tougher maintenance.  Is DI a silver bullet design pattern?  Or do you want the Freedom to refactor the code to best suit the product – I know that I do, this is what Typemock-Isolator will give: The benefits of TDD with the freedom to refactor your code to any design.

Bookmark and Share

Post comment