Main Pitfall of TDD–Refactoring

Monday, May 27, 2013

Many people have bad experience with TDD. Their main complaints are: They spend too much time maintaining tests. For example, to fix a small bug or a small change in the production code they need to fix many tests Even though they follow the TDD practice and always write tests before production code, the production code doesn’t become so “clean” and SOLID. It’s difficult to write tests that cover all lines of code and all cases Tests need very long and complicated setups of mock objects...

Avoiding Conway’s Law using TDD and ATDD

Wednesday, July 11, 2012

Back in 1968, Melvin Conway stated that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". This statement is still relevant today and is well known as the Conway’s Law. There’s a lot of truth in this observation, and many organizations take this law seriously and structure their development organization to best reflect their desired architecture. The desired outcome of such organizational structure, which is mostly achieved, is that each component is cohesive, loosely-coupled from the other components, and also pretty well maintained by the team –...

TDD and the SOLID principles (Part 2: SRP)

Friday, August 26, 2011

Table of contents: Part1 – Indrocution Part 2 – SRP (this post) Part 3 – OCP Part 4 – LSP Part 5 – ISP Part 6 – DIP Part 7 – Conclusion   In the previous post I introduced the SOLID principles and their relation to TDD in general. And as promised, I’m diving into each of these principles and explain their relationships with TDD. The first principle, which I’ll be talking about in this post, is the Single Responsibility Principle or SRP in short. SRP is the...

TDD and the SOLID principles (Part 1 – introduction)

Table of contents: Part1 – Indrocution (this post) Part 2 – SRP Part 3 – OCP Part 4 – LSP Part 5 – ISP Part 6 – DIP Part 7 – Conclusion   Mastering TDD is a process that takes time. There are many pitfalls that “newbie’s” fall into. IMHO the following 2 reasons are the main ones: Thinking about the implementation before writing a test. That is, writing tests that are coupled with the implementation instead of with the problem...