SOLID Principles

In a previous posting on BDD,  I quickly referenced ‘Uncle Bob’ Robert C. Martin’s website where he outlines the SOLID Principles.

I wanted to expand upon that and provide a few more helpful links.

The best examples I have seen that demonstrates these principles can be found in a series of short videos on DimeCasts.net.

# 88 – Creating SOLID Code: Single Responsibility Principle (SRP)

# 90 – Creating SOLID Code: Open/Closed Principle (OCP)

# 92 – Creating SOLID Code: Liskov Substitution Principle

# 94 – Creating SOLID Code: Interface Segregation Principle

# 96 – Creating SOLID Code: Dependency Inversion Principle

 

Scott Hanselman too has a number of podcasts where he is directly interviewing ‘Uncle Bob’:

Hanselminutes Podcast 145 – SOLID Principles with Uncle Bob – Robert C. Martin

When I listened to this podcast, I was quite pleased to hear and have my personal experience validated when ‘Uncle Bob’ rated the Single Responsibility Principle as the most important. In my personal experience, and in the experience of a number of my colleagues, this principle alone has had the largest positive effect in the quest to write cleaner and more intuitive code.

Hanselminutes Podcast 150 – Uncle Bob Martin, this time with feeling

And a more recent podcast discussing the related topic of professionalism.

Hanselminutes Podcast 171 – The Return of Uncle Bob

Towards Behaviour Driven Programming – Part 2

Today a small team of three had a post-iteration meeting, and for the first time within the company (I dare say), there was agreement about the benefits of BDD/TDD when automated tests are required. The team agreed that it takes significantly longer to retrofit automated tests than it does to do the coding and testing in a BDD/TDD fashion.

The main reason is because when BDD/TDD practices are followed, the code is designed cleanly from the start and it tends to naturally follow best practices. When tests were retrofitted, the code typically has to be refactored/restructured and sometimes even completely rewritten so that the test cases can be properly identified and then written.

This is a hard-earned and yet relatively small victory, and after a long amount of time, suffering and battling, I’m telling everyone who’ll listen!

One step closer… critical mass… you are now in my sights! 

Towards Behaviour Driven Programming

Yes, I am a Behaviour Driven Development (BDD) man – and in this post I am limiting my discussion to Behaviour Driven Programming – the reframing of the very badly named Test Driven Development (TDD) practice. If in the future I find a better coding practice, I will switch to it, but at the moment this is the best I’ve found. I don’t necessarily follow the practice to the letter, but I do exude the spirit of BDD.

In case you are unfamiliar with it, BDD (and its predecessor TDD) are all about developers designing their code – code that is simple to use, simple to maintain, squeaky clean, follows best practices (like SOLID development principles), and it just happens to result in the very welcome side-effect of an automated test asset suite. If you don’t understand the benefit of automated tests already, then… I am sorry…

For almost two years now, I have been attempting to up-skill and convince various developers and teams and management at work about the benefits of BDD. The slow progress that has been made at work in no way correlates with my efforts – it is quite difficult to change the culture of teams. However, slowly and surely, I am happy to say that progress is being made.

Late last Friday night, I was showing a well-intentioned developer how he could perform behaviour tests on his code. We started by trying to retrofit the tests to his code, but it was quite smelly to say the least. In addition, because of the structure of the code, we were struggling to identify the valuable test cases we would create. In my disbelief, I quickly reached the point where I blurted out something along the lines of “if it were written using BDD/TDD practices in the first place, then we wouldn’t be having this trouble” – and it was true.

FLASH! It was one of those defined moments in history. I almost didn’t realise what I had said, but then it sank in… and the door reopened to showcase the power of BDD/TDD…

We then scrapped most of the pre-written code, and in a Pair-Programming style I walked the developer through the process of how to write clean code and perform unit testing with the practice of BDD/TDD. The resulting code was clean, intuitive, highly maintainable (as it read like a story), and was easily tested.

We compared the code that he had written with the new code, and there was no contest – the BDD/TDD code was significantly better, and the tests were easy and quick to create.

BDD/TDD is the unavoidable “pit of success” that enables the writing of clean, high quality code with automated test cases.