Day 20 of 100 Consider Tests First

June 5, 2013 — Posted by Al Shalloway

Continuing with the 100 Things You Must Know to Be Effective In Software Development

Many consider doing Test-Driven Development but think it is too much work or will lead to future challenges.  Many folks find that their tests become unsustainable over time.  That's a different story, and you are holding off on TDD because of this, check out our Sustainable TDD site.

This blog is about something much simpler.  It's about the insight that considering your tests (not even writing them, but just considering what they will be) will improve your code dramatically.  The reason for this is that thinking about how you will test your system is a looking at your system from a behavioral perspective - which is a strong design method.  Not coincidentally, one of the critical mandates from design patterns - design to interfaces (which is what tests are).

Anyway, here's the first page and a half from Chapter 3: Define Tests Up-Front from our Essential Skills For the Agile Developer: A Guide to Better Programming and Design book. If you want the rest, just click the link above.

Chapter 3

Define Tests Up-Front

With the advent of agile methods, Test-Driven Development (TDD) has been gaining momentum.  A mantra of agile is that stories are completed, not merely written, every iteration.  This means they have to go through testing to be considered “done, done, done.” Many teams have experienced the productivity gains and value of TDD. Many teams have, unfortunately, shied away from it as well.  We believe that the value and reason that TDD works is not fully appreciated.  This chapter discusses both why TDD works, and why it isn’t really testing up-front.

A Trim Tab: Testing and Testability

As mentioned in the preface, this book represents the set of trim tabs we, at Net Objectives, considers to be most useful for enhancing the productivity of software developers.  We consider the issue of testability (the focus of this chapter) to be, perhaps, the greatest of these.  Hence, we could say this chapter is about the trim tabs of trim tabs.

What Is Testing?

Merriam Webster’s dictionary defines test as “the procedure of submitting a statement to such conditions or operations as will lead to its proof or disproof or to its acceptance or rejection.” This is testing as an action.  However, a test can also be a noun, something that is “a basis of evaluation.”  We’re sure you recollect a time someone put a “test” on your desk and then you had to take it.  The test you were given in this case specified what you needed to know in order to get a good grade.  The action of taking the test is something different altogether.

In the same way, tests in software are about what the software needs to do in order to be considered successfully implemented.  This is why we can write tests before we have code to test.  We are specifying what the software needs to do.  We would suggest this insight leads to the observation that test-first is really analysis first using tests. In other words, we use the tests to determine the behavior we want of the functionality we are testing.  This is a form of analysis.

 But it is actually more than that – it is also a type of design using tests to accomplish the design.  That is, simultaneously with the analysis, we are figuring out how to implement the interfaces of the functionality.  We are splitting the classes up into their methods.  We are, in essence, doing design. 

Testability and Code Quality

Why is this useful?  We suggest it’s because testability is highly correlated to the code qualities we want to manifest, in particular, loose coupling, strong cohesion and no redundancy.  We can recollect times that at the start of testing our code we have remarked:
“I can’t test this code, it does too many things that are so intertwined” (weak cohesion)
“I can’t test this code without access to dozens of other things” (excessive coupling)
“I can’t test this code, it’s been copied all over the place and my tests will have to be duplicated over and over again” (redundancy)
“I can’t test this code, there are too many ways for external objects to change its internal state”

We’ve often summed it up by saying – “gee, I wish they had thought of how this code was going to be tested while they were writing it!”

I’m kind of slow sometimes because it took me quite some time to realize (comment by Alan):
     I should consider how my code is going to be tested before writing it!

The reason is clear – testability is related to loose coupling, strong cohesion, no redundancy and proper encapsulation.  Another way to say this is that the tighter your coupling, the weaker your cohesion, the more your redundancy and the weaker your encapsulation, the harder it will be to test your code.  Therefore, making your code easier to test will result in looser coupling, strong cohesion, less redundancy and better encapsulation.

This leads to a new principles:
   Considering how to test your code before you write it is a kind of design.

Since testability results in so many good code qualities and since it is done before you write your code, it is a very highly leveraged action. That is, a little work goes a long way – it’s a great trim tab.

 

Click here for the rest of the article.

If you are looking to improve your code, I really suggest this simple tip.  It will make a difference.

Al Shalloway
CEO, Net Objectives

Did you like this? Please tweet by clicking on twitter icon below.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban