skip to content

What does a conditional on the deployed target's name inside a case body cost a suite over a year?

level: seniorimportance: should knowfreq 41%

answer

  1. One branch, two bodies, one run
  2. The path nobody runs never fails
  3. Cases start describing the estate
  4. Move the difference into data

basics

~20 s

Each branch adds a path that a single run cannot exercise, so the untaken one rots unnoticed. Over a year the case stops describing the product and starts describing the deployments, and nobody can say what it actually verifies.

solid answer

~50 s

One conditional looks harmless, and the problem is arithmetic. A case that branches on the deployment's name has two bodies; any given run executes one of them, so the other is never run and never fails. It rots silently until the day someone points the suite at that deployment and finds a check that has been wrong for months. Branches also multiply, because the second one is added on the grounds that the first was acceptable. Within a year the case reads as a description of the estate rather than of the behaviour, and expectations have drifted per deployment until nobody can state what the case asserts. The repair is to move the variation out of the case and onto the resolved target as **data** — an address, an attribute, a capability, an expected value the case reads — so the case body is one path everywhere.

code

pseudocode · 14 lines
pseudocode
# rots: half of this case is never executed by any single run
case "checkout applies tax":
    if target.name == "prerelease":
        expected = 0.20
    else if target.name == "local":
        expected = 0.00
    else:
        expected = 0.19
    ...

# one path everywhere: the difference is data on the resolved target
case "checkout applies tax":
    order = place_order(target)
    expect order.tax_rate == target.expected_tax_rate

go deeper

for a junior

Know that a case should read the same on every deployment, and that differences belong in the data the run hands it rather than in a conditional you write. Recall that a branch a run does not take is a branch that run has not checked.

for a middle

Explain the arithmetic: each branch adds a path a single run cannot exercise, so it stops being verified the moment it is written. Be able to name the variations — address, feature presence, expected value — and where each of them belongs instead.

for a senior

Show the year-long shape: branches multiply, expectations drift per deployment, and a case that once described behaviour ends up describing the estate. Talk about how you locate accumulated branching and the order in which you would unwind it.

for a principal

Own the standard that keeps it out: no case reads the deployment's name, differences are declared as data, and genuinely different behaviour becomes two cases. Be ready to justify that rule against the argument that one conditional is cheaper than a table entry.

## The arithmetic of an unrun branch A case with no conditional has one path, and every run executes it. Add a branch on the deployment's name and the case has two paths, of which a run executes exactly one. The other one is not merely untested; it is *unverifiable by the suite that contains it*, because no run against any single deployment can reach it. | Branches on the deployment's name | Paths in the case | Paths a single run exercises | Paths silently unverified | |---|---|---|---| | none | 1 | 1 | 0 | | one | 2 | 1 | 1 | | two | 3 | 1 | 2 | | three | 4 | 1 | 3 | This is why "it passed when I added it" is not reassurance. The branch was correct on the day it was written, against the product as it was that day, and from then on nothing checks it. The expectation inside it drifts with the product while the suite stays green, and the discovery happens at the worst possible moment — when somebody finally points a run at that deployment, usually because something else has gone wrong there. ## Three kinds of variation, and where each belongs Almost every conditional on a deployment's name is one of three things wearing a disguise. | The variation | The disguise | Where it belongs | |---|---|---| | An address, port or path prefix | `if name == ... then use this host` | an attribute on the resolved target | | A feature that is present or absent | `if name == ... then skip the assertion` | a declared capability and a required-capability skip | | An expected value that legitimately differs | `if name == ... then expect this number` | data on the resolved target the case reads | | Genuinely different behaviour by design | one case with two bodies | two cases, each requiring its own capability | The fourth row is the one people miss. When two deployments really are meant to behave differently, that is two behaviours, and two behaviours want two cases with two names — each with a single path, each skipped where it does not apply, each readable on its own. A single case with a conditional is the same information stored in the shape that hides it. ## What a year of this actually looks like - **Month one.** One branch, added under time pressure, clearly written, with a comment explaining why. - **Month three.** A second branch, added because the first made it normal. The comment is now wrong about the first one. - **Month six.** The expected value in one branch has drifted, and nobody notices because that deployment is rarely targeted. - **Month nine.** A new person reads the case to find out what the product should do, and instead learns the shape of the estate. They cannot tell which expectation is authoritative, so they copy the branch pattern into their own case. - **Month twelve.** Someone runs the suite against a deployment it has not seen for a while. A third of the cases fail, none of them for a real defect, and the team concludes the suite is unreliable rather than that the branches were never checked. That last step is the real cost, and it is not the maintenance minutes. It is trust: a suite that fails wholesale when pointed somewhere new gets treated as advisory, and an advisory suite is not doing the job it was funded for. ## Getting the branches out 1. **Find them.** Any read of the deployment's name below the setup layer is the marker. Count the occurrences; that count is a health number you can drive down and keep down, unlike a one-off audit. 2. **Rank by exposure.** The dangerous branches are the ones serving deployments that are rarely targeted, because those have had the longest to rot. The branch on the deployment you run hourly is the least urgent one. 3. **Convert the cheap ones first.** Address and value branches become attributes on the resolved target mechanically, one at a time, with no change to the assertion. 4. **Split the honest ones.** Where the branch encodes genuinely different behaviour, write two cases and let the runner's selection do what the conditional was doing. 5. **Hold the line.** Once the count is at zero, a read of the deployment's name inside a case body is a question in review — not a style note, but "which of the three variations is this, and why is it not data?" The rule that keeps it from coming back is short enough to remember: **a case reads what a deployment *is*, and never reacts to what it is *called*.**

  • Some deployments genuinely behave differently by design. How do you express that without a branch?
    As two cases, each declaring the capability it needs, rather than one case with two bodies. Each case then has a single path, is skipped where it does not apply, and states its own expectation in its own name. The runner's selection does what the conditional was doing, and both cases are readable on their own.
  • Is a single conditional ever acceptable inside a case body?
    Rarely, and only as a stopgap with a removal date attached to a tracked item. The honest framing is that you are knowingly accepting a path the suite will not exercise. If it outlives the date it has stopped being a stopgap, so treat its presence in a review as a question to answer rather than a style preference.
  • How do you find the branching that has already accumulated across a large suite?
    Search below the setup layer for reads of the deployment's name — that identifier appearing inside a case body is the marker, and the count is a usable health number. Rank what you find by how rarely each deployment is targeted, since those branches have had the longest to rot, and convert the cheapest ones into attributes first.

It is the untested emergency exit: it is only ever tried on the day it matters, and that is the day you find it painted shut.

saying these in an interview costs you the question

  • It is only one branch, and it is clearly written
  • The other branch is fine because it passed when added
  • Reading the deployment's name in a case to pick an expected value
  • Adding a branch instead of adding an attribute to the target
  • Believing a green run proves every branch still works