More deterministic tests + better signal-to-noise with branch ‘cross-targeting’

A Tale of Two Repositories

Maintaining a stable branch

In the mainstream app development world, every organization (hopefully) carries both a stable and unstable branch. The names might change — release or master for stable, integration or dev for unstable — but the theme is the same:

  • Continuously maintain a version of our code which is more reliable / less buggy
  • Carefully curate / manage changes to this branch
  • If a bug is found in production, we can “hotfix” against stable quickly
  • Bettter understood code, less fear of breaking changes

If you don’t maintain a stable branch, then your main branch is _unstable_

Implementing an automation-stable branch

We create a new branch in our automation repo. Next, remove cruft, old tests, old libraries. Assign a test developer on cleanup duty for a week or two (three?).

  • Merge your new automation features to unstable first
  • Run all new functionality first in unstable
  • Once a test has burned in successfully with other code, then you can promote that change to stable and let it play for the adults.

Cross-Targeting

At first blush, you might think that stable tests stable and vice versa. But that is actually exactly wrong. What we actually want is a cross pattern, like so:

Two different test vectors, two different priorities

With an “unstable” or development branch for automation, we’re now free to take more risks.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Add Lightness | Better Testing, Better Software

Add Lightness | Better Testing, Better Software

26 Followers

A software dev in test thinking against the grain. “To go faster, simplify, then add lightness.” ~Colin Chapman #cleancode #minaswan #innovate