I've been given the job of "improving the quality" of over a million lines of old code (mostly C++, but some Perl and Java too). Most of this code currently has no tests and was not designed with testability in mind. After reading these nodes:

• Testaholics Anonymous (or how I learned to stop worrying and love Test::More)
• Further adventures with testing
• The Joy of Test
• What goes in a test suite?
• Re: What goes in a test suite?
• Yet another meditation on testing

I've come up with a checklist of possible actions. Please let me know if I've missed important ideas or strategies and which of the points below you consider to be the most important. In particular, I'm interested to know the best way to add tests to existing code.

1. Add new tests whenever you find a bug: i) run test (should fail); ii) fix bug; iii) rerun test (should now pass). That is, grow a regression test suite over time.

2. Risk. Find code "hot spots" by talking to people and examining the bug archives. Add tests for hot spots and areas known to be complex, fragile or risky. Refactor where appropriate (first writing a regression test suite).

3. Add new tests based on what is important to the customer.

4. Documentation-driven tests. Go through the user manual and write a test for each example given there. This also improves the quality of the documentation and hopefully focuses on the customer view of the system.

5. Where you fear a bug. A test that never finds a bug is poor value.

6. Write tests for the more "stable" interfaces. If an interface changes often, you must keep changing the test suite in step.

7. Boundary conditions.

8. Stress tests.

9. Big ones, but not too big. A test that takes too long to run is a barrier to running it often.

10. Use code coverage tools to guide where to write tests.

11. Write some mock objects, where appropriate, to reduce dependencies, make tests more predictable, simulate errors and so on.

12. Do some manual code reviews.

13. Do some code reviews using tools, such as static (e.g. lint) and dynamic (e.g. valgrind) code analysers.

14. Don't let the enormity of the task get you down! Incomplete is better than nothing at all.

janitored by ybiC: Change hardcode www.perlmonks.org/index.pl?node_id=nnnnn links to [id://nnnnn], to avoid logging out monks with cookie set to other perlmonks domain (ie: .com or .net, or sans leading-www)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.