Shimon Krokhmal's blog

In the last few weeks, i was doing a deep dive into some development methodologies such as TDD, BDD, and scrum.
what was bothering be about the TDD approach is the concept of designing for testability.
in early stages of my research, i spoke with Nati, a good friend of mine that practicing TDD in his team,
he told me that in order to write practice TDD it is imperative to write testable code.
What is testable code i asked ?
Well, this is not a simple question to answer, roy Osherove has even written a book about that,
from changing the design of your application, like using MVP to an "Inherit & Override" practice .
all these practices make your TDD life easier, but we need to ask ourselves one simple question :
"What is the purpose of your application ?",
seems like a stupid question to raise, but due to the noticeable progress of the software industry towards TDD blindly,
this may affect the software performance/Quality "Just" for making our code testable.

I came across Eli Lopian's article about Stop Designing for Testability, which confirms my concerns about the issue, i Totally agree with him.
testable code has an added value, but must we not forget the real purpose of the application, which is to run best in production environment.

This post is a sort of a reply post to nati's post - Testable code, is it worth it ? regarding that matter.

Testable application is certainly an added value to the development process and to the business as one,
but we must be careful not to make it the main issue of the application.
a great example of how TDD should be done is the TypeMock.Net tool, which allows you coding TDD without affecting the performance and OOP design of the application, in my opinion, this is the way to go the TDD way.

What do you think about this matter ?