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 –...

Guidelines for writing good automated tests

Monday, April 30, 2012

Hi everybody! Recently I was appointed to lead the test automation and TDD efforts in Retalix’s development group. As part of this effort, I realized that most people lack the knowledge of how to write good tests, and their mistakes lead to tests that are a pain to maintain, or give doubtful ROI. So I ended up putting this short guidelines on the internal Wiki. However, I thought that it should be useful to share it with everyone. What kind of tests these guidelines refer to? Any functional automated tests. That is automated tests that...

Worst VS feature: Copy & Paste

Wednesday, March 21, 2012

Time and time again, when I'm reviewing code of pretty experienced programmers, I'm still shocked how they're using Copy & Paste programming extensively instead of extracting common code to shared methods and classes. Visual Studio and many 3rd party add-ons tools make it very easy to make these refactoring that allows to avoid any duplication. But still – Copy & Paste is easier and that's what many programmers use by default. Frankly, I chose the title for this post just to tease. Clearly there's nothing wrong with the Copy & Paste feature of Visual Studio. The problem is...

TDD and the SOLID principles (Part 7 – Conclusion)

Sunday, November 20, 2011

Table of contents: Pat 1 – introduction Part 2 – SRP Part 3 – OCP Part 4 – LSP Part 5 - ISP Part 6 – DIP Part 7 – Conclusion (This post) Often when talking about TDD it is said that despite of its name, TDD is not a testing methodology, but rather it’s a design methodology. As you’ve seen in this series of articles, the SOLID principles goes hand-in-hand with TDD, and indeed TDD drives the design of your code in a way that adheres to the SOLID principles....

TDD and the SOLID principles (Part 6 – DIP)

Tuesday, November 1, 2011

This is the 6th post in the series about TDD and its relationships with the SOLID principles. Here’s the table of content for the series: Pat 1 – introduction Part 2 – SRP Part 3 – OCP Part 4 – LSP Part 5 - ISP Part 6 – DIP (this post) Part 7 – Conclusion DIP – Dependency Inversion Principle Depend on abstractions, not on concretions. This principle states that: A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS. ...

TDD and the SOLID principles (Part 5 – ISP)

Saturday, October 1, 2011

This is the 5th post in the series about TDD and its relationships with the SOLID principles. Here are the links to the previous parts: Pat 1 – introduction Part 2 – SRP Part 3 – OCP Part 4 – LSP Part 5 - ISP (this post) Part 6 – DIP Part 7 – Conclusion ISP – Interface Segregation Principle “Make fine grained interfaces that are client specific” This principle speaks for itself… but anyway I’ll “translate” it… : It is better to create many small interfaces than...

TDD and the SOLID principles (Part 4 – LSP)

Thursday, September 22, 2011

This is the 4th post in the series about TDD and its relationships with the SOLID principles. Here are the links to the other parts: Pat 1 – introduction Part 2 – SRP Part 3 – OCP Part 4 – LSP (this post) Part 5 – ISP Part 6 – DIP Part 7 – Conclusion The LSP (Liskov Substitution Principle) The principle (originally stated by Barbara Liskov in a more academic fashion), states that: FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED...

TDD and the SOLID principles (Part 3 – OCP)

Wednesday, September 7, 2011

Table of contents: Part1 – Indrocution Part 2 – SRP Part 3 – OCP (this post) Part 4 – LSP Part 5 – ISP Part 6 – DIP Part 7 – Conclusion The Open/Close Principle The Open/Close Principle states that: SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICTION. This statement pretty much says it all, and naturally extends the Single-Responsibility principle: Classes (and functions, etc.) should be kept as simple as possible (having a single responsibility) and therefore should never have to change. Therefore, if you want to add functionality to your system you should add new code instead of changing existing one....

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...