DEV Community

Jesse M. Holmes
Jesse M. Holmes

Posted on

Tell us about a time when your tests saved you

… or tell us about a time when your tests destroyed you.

Top comments (3)

Collapse
 
avalander profile image
Avalander

We were using a statistics library developed by another team in the company. Since that other team couldn't be bothered to write tests, we had an extensive integration test suite on that library (that's about all the tests we had, our project manager and architect thought we shouldn't bother to test our own code, but that is a story for another time). Every time they released an update on that library, we would discover half a dozen breaking changes thanks to our integration tests.

Collapse
 
phlash profile image
Phil Ashby

During the very extended 2 years of 'final testing' of our satellite code, during which time we changed a piece of hardware (the EPS - electrical power system) that could have failed the mission:

Pre-conditions:

  • 10minute delay required from power-up to deploying antennas for comms/control
  • watchdogs everywhere, including in the EPS

Critical code:

  • Delay loop executing at startup for 10mins

Fatal change:

  • The original EPS had a 30min watchdog..
  • The replacement was 5mins.

Impact discovered during full deployment test 1 month before launch:

  • The delay loop did not poll the EPS watchdog, which now operated, resetting the whole system - forever.
  • We have no antenna, and the software never leaves startup.

Fix:

  • Trivial - poll the EPS during the 10min delay.

Outcome:

  • Working FUNcube-1 :)
Collapse
 
gsto profile image
Glenn Stovall

When I update a package from 6.1.1 -> 6.2.1 and think, "that couldn't . have broken anything, right?"