15 Debugging

 

Innovation at the museum

This chapter covers

  • Reproducing a bug in code that involves primitive data types
  • Reproducing a bug in code that involves aggregated data
  • Replaying a scenario in the REPL
  • Creating unit tests from bugs

When our programs don’t behave as expected, we need to investigate the source code. The traditional tool for code investigation is the debugger. The debugger allows us to run the code, step by step, until we find the line that causes the bug. However, a debugger doesn’t allow us to reproduce the scenario that causes the problem.

In DOP, we can capture the context of a scenario that causes a bug and replay it in a separate process like a REPL or a unit test. This allows us to benefit from a short feedback loop between our attempt to fix the code and the results of our attempt.

15.1 Determinism in programming

After a few months, Theo calls Dave to tell him that he’s leaving Albatross. After Dave recovers from this first surprise, he’s given another, more pleasant one. Theo informs Dave that after consulting with the management team, they have decided that Dave will be in charge of DOP at Albatross. In addition to the farewell at the office next week, Theo invites Dave for a last one-on-one work session at the Exploratorium Museum of Science.

15.2 Reproducibility with numbers and strings

15.3 Reproducibility with any data

15.4 Unit tests

15.5 Dealing with external data sources

Farewell

Summary