Thursday, December 19, 2013
TDD and the Single Responsibility Principle
Amongst the 5 SOLID principles, I found that the one which is the least tangible is the “Single Responsibility Principle” (SRP). Even though this is the most well-known and intuitively easy to understand, the questions “What exactly is ‘Responsibility’?” or “How do you determine whether a class has exactly one Responsibility?” is not trivial whatsoever. Obviously there are many cases that the violation of this principle is evident, but there are many more which fall in the grey area.
It’s often being claimed that TDD helps guide you to develop classes which adhere to the...
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....
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. ...
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...
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...
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....
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...
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...
Monday, February 14, 2011
In the project I’m working on right now we’re using FitNesse as a core part of our development process and I found it very useful. FitNesse is a wiki-like tool that provides the ability to define tests (and run them) by writing them in a special mark-up language, rather than in a programming language. This is usually best for describing user-stories (rather than low-level unit-tests), and therefore this approach is often referred to as “Acceptance Test Driven Development” or shortly ATDD. Note: other tools (like Cucumber and SpecFlow) refer to a similar approach...