I work on a team where we practice pair programming and TDD every day. Pairing alone isn’t the key to our success, another important element is Test Driven Development or TDD.

Traditional Engineering Teams

Most engineering teams today, make changes to their code and often these changes break a whole bunch of ‘stuff’.  If you’re lucky, you find out which functionality was regressed prior to pushing code to production.  But more often than not, we’re not that lucky.  The breaking change isn’t caught because automation does not exist.  So the code gets into the hands of the customer long after it’s been written and results in an escalation.  This leads to frustration and increased customer dissatisfaction.  But it doesn’t just lead to frustration and inefficiencies for our customers, it results in Increased TCO for everybody involved.  The cost of working this way is ENORMOUS.


TDD Explained

TDD turns traditional development on its head.  Test-driven development is a programming technique that requires you to write implementation code and automated test code simultaneously. By working in this way, you ensure your code is tested.  Because the code is automated, you can test and retest your code quickly and easily.

Here’s how it works in practice –

  1. Before writing any code, you first write an automated test for your code.
  2. The first time you run your automated test, the test should fail—indicating that the code is not yet ready.
  3. Implementation code is then written to make the test pass.  Once the code passes the test, you can then begin cleaning it up, via refactoring. As long as the code still passes the test, it means that it still works. You no longer have to worry about changes that introduce new bugs.
  4. When the test passes the implementation is complete and programmers move onto writing the next test and implementation…
  5. Programmers enjoy more time to play air guitar, ping pong or Xbox.  Just kidding, sort of …

 

The Benefits of TDD

One obvious benefit is the elimination of technical debt.  Technical debt is a metaphor used to describe the consequences of writing code without having appropriate test coverage.  The debt can be thought of as work that needs to be done before a feature is finished.  If the debt is not repaid, then it keeps accumulating interest, making it hard to implement future changes.  Technical debt is a major factor in bringing an engineering teams’ productivity to its knees.

  • TDD reduces the total # of bugs and also the potential for bugs.  The granularity of TDD implementation guarantees that every line of code is tested.
  • Project teams can quickly tell if they have broken functionality that was previously delivered prior to pushing code to production.
  • Refactoring encourages continuous learning and improvement.  Preventing ‘code rot’.
  • Programmers can execute with greater confidence, every line of code is tested.
  • Developers can implement code in smaller chunks and push that code to production more quickly.
  • By eliminating technical debt programmers and project teams can focus on customer need and business value.

If you’d like to learn more about how we leverage TDD, or how you can get started, come visit us at the #EMCDojo.  We would love to give you a tour and perhaps, if you have the time, you could even pair with us.  After all, learning by doing is at the heart of everything we do.

Email Brian Roche

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.
Tags: , , , , , , , , ,

Leave a Comment

Comments are moderated. Dell EMC reserves the right to remove any content it deems inappropriate, including but not limited to spam, promotional and offensive comments.

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.