Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Winning people over to better development practises (TDD)

by eyepopslikeamosquito (Archbishop)
on Mar 13, 2006 at 21:19 UTC ( #536384=note: print w/replies, xml ) Need Help??

in reply to Winning people over to better development practises

When I gave a lunchtime talk evangelizing TDD (Test Driven Development), I summarised the benefits as follows:

  • Improved interfaces and design. Especially beneficial when writing new code. Writing a test first forces you to focus on interface - from the point of view of the user. Hard to test code is often hard to use. Simpler interfaces are easier to test. Functions that are encapsulated and easy to test are easy to reuse. Components that are easy to mock are usually more flexible/extensible. Testing components in isolation ensures they can be understood in isolation and promotes low coupling/high cohesion. Implementing only what is required to pass your tests helps prevent over-engineering.
  • Easier Maintenance. Regression tests are a safety net when making bug fixes. No tested component can break accidentally. No fixed bugs can recur. Essential when refactoring.
  • Improved Technical Documentation. Well-written tests are a precise, up-to-date form of technical documentation. Especially beneficial to new developers familiarising themselves with a codebase.
  • Debugging. Spend less time in crack-pipe debugging sessions. When you find a bug, add a new test before you start debugging (see practice no. 9 at Ten Essential Development Practices).
  • Automation. Easy to test code is easy to script.
  • Improved Reliability and Security. How does the code handle bad input?
  • Easier to verify the component with memory checking and other tools.
  • Improved Estimation. You've finished when all your tests pass. Your true rate of progress is more visible to others.
  • Improved Bug Reports. When a bug comes in, write a new test for it and refer to the test from the bug report.
  • Improved test coverage. If tests aren't written early, they tend never to get written. Without the discipline of TDD, developers tend to move on to the next task before completing the tests for the current one.
  • Psychological. Instant and positive feedback; especially important during long development projects.
  • Reduce time spent in System Testing. The cost of investigating a test failure is much lower for unit tests than for complex black box system tests. Compared to end-to-end tests, unit tests are: fast, reliable, isolate failures (easy to find root cause of failure). See also Test Pyramid.

Note that the first point above is the most important.

Update: Some further points added later from Effective Automated Testing:

  • It is easier/cheaper to write automated tests for systems that were designed with testability in mind in the first place.
  • Interfaces Matter. Make them: consistent, easy to use correctly, hard to use incorrectly, easy to read/maintain/extend, clearly documented, appropriate to audience, testable in isolation. For more detail see On Interfaces and APIs.
  • Dependency Injection is perhaps the most important design pattern in making code easier to test.
  • Mock Objects are frequently useful and are broader than unit tests - for example, a mock server written in Perl (e.g. a mock SMTP server) to simulate errors, delays, and so on.
  • Consider ease of support and diagnosing test failures during design.
  • Single step, automated build and test are a pre-requisite for continuous integration and continuous delivery.
  • Automation is essential for tests that cannot be done manually: performance, reliability, stress/load testing, for example.

The talk was well-received and did change both development practices and management awareness. I also illustrated each point with specific examples from our workplace (e.g. a developer refactoring without a test suite causing a rush of new bug reports from customers).

See Also

Updated 19-Mar-2006: Improved wording. Also note that many of the ideas for these bullet points were derived from chromatic and Schwern's excellent Test::Tutorial talk. See also Unit testing -- module, book, and website suggestions wanted. Updated 23-Aug-2018: Minor improvements to wording (keep in sync with Effective Automated Testing). See also You've gotta have tests! by talexb. July-2019: Added See also section.

  • Comment on Re: Winning people over to better development practises (TDD)

Replies are listed 'Best First'.
Re^2: Winning people over to better development practises
by simon.proctor (Vicar) on Mar 14, 2006 at 10:23 UTC
    Thanks, that's a good list to start with.

    I wondered, did you find it difficult to handle some people in winning them over to this? How did that change over time?

      I wondered, did you find it difficult to handle some people in winning them over to this?

      For the people in my team, I had no difficulties whatsoever because I could sit with them and show them how to do it (as adrianh notes below: "show not tell").

      For people in other teams, it depended on their interest and aptitude: some really surprised me by writing excellent unit tests without any prodding at all; others didn't seem to get it; others complained that they didn't have the time. Nobody said it was a stupid idea, the most common reason for not doing it was "I have a hard deadline and I just don't have the time right now, maybe I'll try it on my next project".

      How did that change over time?

      It's been over a year now, and TDD is growing slowly but steadily as the early adopters spread the word and show others how to do it. There are a certain percentage of programmers (maybe more than half) that don't read or study anything outside of work; the only way to reach them is to sit with them and show them how to do it.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://536384]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (3)
As of 2023-12-10 13:15 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (40 votes). Check out past polls.