Test Driven Developement

TDD, ATDD, BDD… were all pretty much alphabet soup.
These acronyms were flung around with the accusatory context that they weren’t being done.  People actually started developing ADD 🙂
Test Driven Development, Acceptance Test Driven Development, even  Behavior Driven Development.  I’ll cover some of the TDD aspects today.
I never liked coming in saying nothing was being done.  Maybe it’s just my style, but if a child is learning how to walk – it doesn’t do much good to simply yell “right foot – no, NO, you’re doing it all wrong”.   Instead it is far more effective to stand beside them, share in the moment with encouragement and recognize their wins.  Capitalize and keep moving with small improvements to become better and sustainable.

 In teaching TDD – there are just the three steps –

1) create a small test.
2) create the code to pass it.
3) Refactor the code/test.
This works at the unit-test level, the test case/functional level, even an automation level.  Is this all you need?  of course not.
But starting somewhere means something actionable and not just a complaint hanging in the air over a team to be lost in the nether.
I liked the many levels of insight and wisdom that Kent Beck had in his book (below) on why we want to do it this way.
Write the test first.
We are breaking it up into smaller pieces…. If the test is hard to write – then maybe the architecture should change.
we converge on the expectation. The test once created is run and expected to fail.
we know what it takes to pass.
we are not afraid of seeing an expected failure.. we learn to explore them. fix them
Write the code to pass.
We refactor if needed.
Get rid of duplicate code.
We have had a small success.. easier to move on AND we learned something.
We move on to the next small test.  If the test doesn’t pass then there isn’t much required in order to get it working again.
Also called ‘moving to the green’. – (red would be fail)
I also like a three pronged approach.  Coming at any problem from multiple, supporting lines of attack, usually assures a solution.

1) Just don’t throw a book at someone – help them to practice it.

There are some really good books and depending upon the level of the tester or developer.  I liked the Wesley Signature series.

There is no problem making the topic a book club, lunch-n-learn or a topic at the Community of Practice.  In stressing actionable, try actually suggestions from the team on where/when to DO it. Emphasize the action and not the complaint.  Perhaps it depends how receptive everyone is IF we are breaking bad habits, right? Don’t look back at all the legacy code.  Start today and move forward.  Today’s features and Today’s backlog items.  Time spent converting is not always fruitful.  To convert legacy code you may actually be trying to replicate bad architecture, and none of which gets you to the features your customers may want today. If you have a story that takes you into legacy land – that is the time to improve it.  Bring it up to our definition and expectations for done in alignment with backlog priorities.


(this should be number 1) right?)  For instance – Are the testers having a whiteboard at the beginning of the story on how it will be tested so that developers are on the same convergent expectation for what being done will look like.  Are there overlapping or redundant areas of test coverage between what we will do for unit and functional tests?  Are tests finished before the code – and code will get them to pass? Is anybody waiting? (a bad sign – there is always something that needs to be done or could be improved)  Can test automation be useful is creating example data in a developers environment so they can run and see the tests pass themselves? Can test automation created to prevent the excessively long hardening periods our organization has? Here we have code, test cases, test automation all developed at the same time. The proverbial vertical slice that is focused on delivering the story.  Do teams still put in unit tests as an afterthought?… the coverage is there, just not the correct sequence. Develop the unit tests first and watch their impact on how the architecture emerges.  Something very difficult to pass should tell us something.  By the way, consider using the unit tests for integration points and not always just trying for coverage.  Also accept that 100% coverage is very difficult and while the teams balances appropriately, list how you will cover exceptions.

3)Keep it simple but improving

What do the teams have today that we can leverage and improve.  Are we re-using tests, unit tests, code example libraries, test cases or test automation? Are we creating a thousand point and click here… or did we need just a few of those ‘beginner/training/ cases and most require some knowledge of the system and hit the bias paths and main workflows?  We are considering tactics and strategies on how to test the work. Without making the test harness a product itself (unless that IS your product … Selenium, Cucumber, etc.)  Testing augments the quality of the product the customer gets. The working deliverable is created more efficiently, making the team agile and faster in delivering it.
Celebrate the leaders, early adopters and achievements with recognition.  Scrum masters might even ask the team if they completed the tests first.   Think of easy metrics to make efforts visible and that point to improvement. There may be signs in velocity, type of work, fewer bugs and hotfixes… etc.  Lines of code usually decreases because quality is higher.
As ever, stay agile.

Please leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s