You are reusing a component that has run without incident for years in another product. What does your test strategy have to say about it?

A clean history is evidence about the old system

The argument for skipping the reused component is always the same, and it is not stupid: it has run in production for four years, it has never caused an incident, and there are twenty new components competing for the same testing effort. Spending time on proven code while unproven code goes untested looks like poor prioritisation.

The flaw is in what "proven" means. Four years without incident is strong evidence that the component behaves correctly for the inputs it received, under the loads it saw, in the environment it ran in, with the callers it had. It is no evidence at all about inputs outside that range. And the entire reason you are reusing it in a new system is that the new system is different — different scale, different data, different callers, different reason for existing — which is precisely the set of ways its history stops applying.

So the strategy's job is not to re-verify the component's logic. Its job is to identify where the new context leaves the range the history covers, and to test that boundary.

Ariane 5 Flight 501 and the cost of an inherited envelope

The 1996 loss of Ariane 5 Flight 501 is the case to reach for, because it is the clean version of this failure and not a story about sloppy engineering. Inertial reference software carried over from Ariane 4 converted a 64-bit floating-point value into a 16-bit integer, the value overflowed on a trajectory the earlier vehicle had never flown, and the resulting diagnostic output was read by the control system as flight data.

What makes it the right anchor for a test-strategy answer is that the code was not defective by the standards of the system it was written for. On Ariane 4 the value could not reach the range that overflowed, so the conversion was safe, and no amount of testing against Ariane 4's flight profiles would have revealed anything. The gap was one of scope rather than of coverage. The component's assumption about its operating envelope travelled with it into a vehicle whose envelope was different, and nothing in the reuse decision required anybody to write that assumption down and check it.

Every reuse decision has this shape, usually with lower stakes. A rate limiter sized for a hundred requests per second, a parser assuming a file will fit in memory because the old system's files always did, an identifier field wide enough for the previous volume of records, a currency routine that only ever saw two decimal places, a timeout tuned to a network that was always in one region.

Surface the assumptions before choosing tests

The first piece of work is therefore an inventory of what the component assumes, because you cannot test an assumption you have not articulated. It comes from several places, none of which is a specification.

Read the code for its implicit bounds: fixed-width types and casts, buffer and array sizes, hard-coded limits, timeouts, precision of numeric types, character-set handling, anything that would behave differently at a thousand times the volume. Read its existing tests, which are a record of what its authors believed the input range was, and note which dimensions they never varied. Read its configuration defaults, since a default is a statement about the expected environment. And where they are reachable, ask the people who ran it what its worst day looked like, because the operational limits are usually known informally and written down nowhere.

Then describe the new envelope on the same axes: the volume and rate of data, the ranges and precision of values, the concurrency, the character sets and locales, the error rates of its dependencies, the platform, and who calls it and how often. The comparison is mechanical once both sides exist, and every axis where the new envelope exceeds or simply differs from the old one is a candidate test with a real justification attached.

What the strategy commits to

For the axes where the new envelope is genuinely wider, the tests are ordinary and specific: boundary values at the new limits and just beyond, volume at the new scale, the value ranges the old system could not produce. This is where the reuse decision earns its testing budget, and the case for the effort is now concrete rather than a general appeal to prudence.

Two further commitments matter as much. The first is behaviour at the boundary rather than merely within it, because the Ariane case turns on what happened when the assumption was violated: the failure was silent in the sense that a value was produced rather than an error raised, and the caller had no way to distinguish diagnostic output from data. So test what the component does when it is pushed outside its range, and if the answer is that it returns something plausible rather than failing loudly, that is a finding to report on its own, independent of any specific input.

The second is the seam. A reused component in a new system has new callers making new assumptions about it, and defects at that boundary are invisible to tests on either side: each half is correct on its own terms and the pair disagrees about units, nullability, ordering, error semantics or who validates what. Contract tests at the interface catch the whole class rather than one instance.

When nothing is written down

The common real situation is a component with no documentation, no tests and no surviving authors. The route in is characterisation tests: exercise the component with a broad range of inputs and record what it currently does, without judging whether that is correct. The result is not a correctness suite, because you have codified the behaviour including any bugs, and it must be labelled as such so nobody later mistakes it for a specification. What it gives you is a description of the current behaviour, which is the thing you need in order to notice when the new context changes it, and a safety net for the modifications the integration will require.

Where the component processes data, replaying real historical inputs through it is worth more than any hand-written case, because production data contains the malformed, legacy and edge-case records that nobody would think to invent.

The paragraph most strategies omit

Finish by stating what is not being tested and why. A strategy that lists coverage implies uniform confidence, and the inherited assumptions you decided not to verify are exactly the risk that later reads as an oversight. Write down each assumption you identified, whether the new system stays inside it, and where you chose to accept it untested — because the cost of testing was disproportionate, because the condition cannot be reproduced pre-release, or because a detection mechanism covers it instead.

That paragraph converts an inherited assumption into an accepted risk with a name attached, which is the only form in which a reuse decision can be reviewed later. It also makes the distinction an interviewer is listening for: whether a subsequent failure was a defect in the component, or a defect in the decision to reuse it without checking what it assumed.