Workflow

An important part of doing testing successfully is getting into a rhythm. Here are my rhythms for a few scenarios. I suggest that if you don’t already have rhythms you try these.

Adding A Feature: General Steps

  • Check out the code. Make a branch for the feature.
  • Run the tests. Fix any that are failing.
  • Optional: create an issue in your issue tracker related to adding the feature.
  • Write a new feature. Don’t write tests while you do it, unless you believe the feature is going to consume over 200 lines of code.
  • If you think the feature you want to add is going to consume lots of code, try to break the feature into some number of parts, and write just one of those parts.
  • When the feature is more or less working, start to add tests. Don’t add tests for all of the code, just one or two tests for a bit of it.
  • Run the new tests.
  • Fix failures.
  • As you’re fixing tests, change the code to suck less.
  • Lather, rinse, repeat until the feature is working and completely tested.
  • Add a note to the changelog about the new feature.
  • Document the new feature.
  • Check the result into version control as if you had meant to write code like that all along. :)

Adding A Feature: Antipatterns

  • Not running the tests before you start to add the feature.
  • Writing a thousand lines of code without writing any tests for that code.
  • Writing a bunch of tests without changing any of the code that’s being tested.
  • Not, at least once for every large feature, throwing away a medium sized chunk of code wholesale and starting over again because you realize you can’t test it.
  • Not fixing existing tests that start to fail as a result of your changes.
  • Not fixing existing tests that fail as a result of someone else’s changes.

Adding A Feature: Demonstration

Fixing a Bug: General Steps

  • Create an issue tracker issue for the bug (e.g. “issue # 10931: Frobnozz Doesn’t Fizz”) describing the bug in detail.
  • Check out the code that has the bug.
  • Create a branch of the code in your local repository (e.g. bug-10931-frobnozz-doesnt-fizz).
  • Run the tests. Fix any that are failing.
  • Write one or more tests to demonstrate the bug. The tests should fail.
  • Commit the failing tests.
  • Push the branch to the centralized repo.
  • Inform others that might be able to fix the bug that you’ve repeated it.
  • Try to fix the bug on the same branch while you’re waiting for the cavalry.
  • When the bug is fixed, check the fix into the bug branch, and push it (or pull it in, if someone else has fixed it).
  • Verify that the bug is fixed mentally.
  • Merge the fixes that are in the bug branch (including the tests) into the mainline.
  • Add a note to the changelog about the bug and the fix.
  • For each bug, make sure you write a test demonstrating it.
  • If necessary, change the docs.

Fixing a Bug: Antipatterns

  • Not creating an issue describing the bug succintly.
  • Not creating a failing test (if possible).
  • Not pairing the bug’s issue and the test that demonstrates the bug.
  • Checking a failing test in on a branch that other people use. Let them opt-in instead of making them opt-out.
  • Not merging the test that demonstrated the failure back to the mainline.
  • Not adding a changelog entry relating the issue in the tracker to the commit that fixed it.
  • Not fixing existing tests that start to fail as a result of your changes.
  • Not fixing existing tests that fail as a result of someone else’s changes.

Fixing A Bug: Demonstration