As of today, backup_test.go is the second-largest test file in CRDB at ~9k lines. It is becoming harder to understand the existing backup+restore test coverage, maintain older tests, and is not exactly setting a good standard for new tests. A lot of folks (myself included) default to plugging in subtests or one-line "tests" in an existing Test function when developing new functionality, instead of a dedicated test that is easily identifiable by name.

At CRDB we really like the readability and expressiveness of data-driven tests. This along with new jobs infrastructure such as jobs.debug.pausepoints has motivated us to try and rewrite as much of backup_test.go as dedicated data-driven tests. I believe this can be achieved in three general steps:

• Refactor the data-driven framework and make it more featureful to support writing existing tests.
• Datadrivenify existing backup/restore tests.
• Promote a culture of first reaching for data-driven tests when testing new functionality.

Epic CRDB-7779

Jira issue: CRDB-13425