How to start doing TDD?

Intro

A colleague recently asked my advice about how to start incorporating Test-Driven Development (TDD) into his project. I don’t consider myself very advanced in this topic, but long ago I recognized the tremendous value of this development approach and the benefits it provides for writing good and clean software, therefore I started practicing it and forming my own learning path. Rather than jumping right into a demo, I decided to provide a set of initial pointers that will allow any developer to better understand and apply this development paradigm, even before writing a line of code.

What to learn before writing unit tests?

Here are some of the topics along with useful resources that will allow developers better understand and apply the TDD approach:

  • Understand how to write testable code
  • Learn the art of refactoring
  • Understand the TDD philosophy
    • What is Red->Green->Refactor workflow?
  • Try and choose a unit test framework that works for you and learn the syntax
  • Define a naming convention for your tests
    • Setting a naming convention is very important, since the number of test cases will grow exponentially as you write more code, and you want a quick way to identify what scenarios are being tested and what is breaking, just by glancing over the list of tests.
    • For test libraries, I like to use:
      • <libraryname>.tests.dll
    • For test methods, I like to use:
      • <classname>_<methodname>_<testconditions>_<expectedresult>
  • Practice, practice, practice
    • Exercism.com – I found this amazing site offering several simple exercises that must be solved using a TDD approach and can be implemented in multiple languages. Great resource not only for learning TDD, but also for keeping programming and logical skills sharp and learning a new language once in a while. It is also great to be able to view how other programmers implement the same solution, as well as providing and receiving feedback. I took the personal challenge of solving a couple of exercises every week.

Once you are very familiar with the above topics, you could try expanding into more adavanced scenarios:

  • Learn how to use mocks and fakes
  • Integrate unit tests into the Continuous Integration build
  • Get test coverage reports

Summary

I hope this post can be helpful to those developers wanting to incorporate TDD into their development approach for the first time. It only touches the surface, but hopefully it can serve as a starting point for future craftsmen, willing to put the extra effort in order to write clean, efficient and maintainable code.
Please let me know if you’d like to expand on any topic or add new ones to this list.

Reference

Advertisements

Tools and techniques for Agile teams

The following list is meant to be a compilation of practices used by teams following an agile development process. This is not an absolute list, as I intend to update it periodically, but it should represent the most common practices being adopted and exercised in the field.

Requirements

  • Product and Sprint Backlogs
  • Kanban Boards
  • User Stories
  • DoD (Definition of Done)
  • Acceptance Criteria

Estimation

  • Sprint Planning
  • Story Points
  • Planning Poker

Feedback

  • Burnup and burndown charts
  • Daily Stand-up
  • Sprint Review
  • Retrospective Analysis
  • Automated Tests
  • Continuous Integration
  • Code Reviews

Quality & Productivity

  • Source Control
  • Pair Programming
  • Automated Testing
  • Test-Driven Development
  • Continuous Integration
  • Design Patterns
  • Code Refactoring
  • Product Increment

Project Roles

  • Scrum Master
  • Product Owner
  • Cross-Functional team

Template for Retrospective Analysis used by Agile Teams

Intro

The following is one of the principles described in the Agile Manifesto:

Continuous attention to technical excellence and good design enhances agility.

One technique to materialize this principle is to conduct a retrospective analysis after each iteration. This allows the team to identify issues and reflect on how to become more effective, then fine tune the behavior accordingly and improve the process. The goal is always to become better at what we do and deliver the best possible results, while keeping all team members engaged.

I will share a very simple template that could be used to gather data about a previous iteration of work from all team members. This could serve as a guide for a productive discussion.

Retrospective Analysis Template

The following template can be used to collect some information from team members after an iteration of work:

What went well?
In other words, what took place that we want to recognize and acknowledge as having gone well?
What didn’t go so well?
What took place that didn’t go as we would have liked?
What did I learn?
We want to think about what we’ve learned about how we worked together. It’s less about the content and more about the process.
What still puzzles me?
This question allows us to capture things that happened but leave us feeling unclear or puzzled.

Summary

Constant improvement is a key aspect of any Agile project. Conducting retrospective analysis allows teams to gather feedback after each iterations and  identify what areas need attention. There are many recommended approaches and frameworks for conducting a successful retrospective analysis session, and they all focus on identifying three things:

  • what went good
  • what went bad
  • what actions we should take to improve the process

This articles provides a specific template that could be used to request information from team members after each iteration, and then be used as support for in-person session.

Reference

Agile Retrospective by Margaret Rouse

Agile Manifesto

Agile Retrospective Wiki