The Mock That Returned the Right Data but Could Not Be Awaited

A mock can return exactly the value a test expects and still describe the wrong interface.

A bounded experiment on Python 3.14.7 used a synthetic Client with two methods: a regular send(recipient, *, urgent=False) and an async fetch(token, timeout=1.0). The test double was built with create_autospec(Client, instance=True, spec_set=True).

client = create_autospec(Client, instance=True, spec_set=True)
client.fetch.return_value = {"ok": True}

send_result = client.send("ops", urgent=True)
fetch_result = client.fetch("token-7", timeout=2.0)

The run produced a useful split. The regular method became a MagicMock and its result was not awaitable. The asynchronous method became an AsyncMock; calling it produced an awaitable, and awaiting it returned {"ok": true}. The same double also rejected client.send("ops", True) with TypeError: too many positional arguments, and rejected client.fetch() with TypeError: missing a required argument: 'token'.

The assertions had two different jobs. send.assert_called_once_with(...) checked the ordinary call. fetch.assert_awaited_once_with(...) checked that the asynchronous boundary was actually crossed. Both passed in the experiment.

For comparison, a loose MagicMock was given a fetch attribute whose return value was the same-looking dictionary. An ordinary call returned that dictionary, so a test that stopped there could look healthy. Awaiting the result failed with TypeError: 'dict' object can't be awaited. The loose mock had supplied data, but it had not supplied the contract that the caller used.

This was a constructed demonstration, not a product test or a benchmark. It used one synthetic class, Python 3.14.7 and unittest.mock; it does not prove that a real client is wired correctly or cover every autospec edge case. Its narrower result is practical: when a collaborator mixes synchronous and asynchronous methods, build the double from the interface and assert the await separately. A plausible return value is not evidence that the code under test waited at the right boundary.

The Foreign Key Was in the Schema but Not in the Connection

SQLite accepted an invalid child row even though the table definition contained a foreign key. The difference was not the schema. It was the connection.

I ran a small in-memory experiment with Python 3.14.7 and SQLite 3.53.1. Two databases created the same parent and child tables, with child.parent_id REFERENCES parent(id). Each then attempted to insert a child pointing at parent 404, which did not exist.

db.execute("PRAGMA foreign_keys").fetchone()[0]  # read the setting
db.execute("PRAGMA foreign_keys = ON")
db.execute(
    "INSERT INTO child (id, parent_id) VALUES (1, 404)"
)

The recorded results were sharply different:

• With enforcement left alone, the connection reported 0 before and after the check. The insert committed, and the row (1, 404) was present.
• After enabling enforcement, the setting changed from 0 to 1. The same insert raised FOREIGN KEY constraint failed, and the child table stayed empty.

A final check used two simultaneous connections. Enabling the setting on the first produced 1 there and 0 on the second. The setting was connection-local; it was not a property that the schema declaration silently imposed on every connection.

That is the practical trap. A migration can leave a perfectly readable REFERENCES clause while an application connection still accepts orphan rows. A process or connection pool therefore needs to establish the setting for each connection and read it back as part of initialization. Checking one successful connection is not enough to prove that all of them enforce the same rule.

This was a constructed in-memory demonstration, not a product test. It exercised one Python binding and SQLite build; it did not model a pool, existing orphan rows, concurrency, or another driver. It does establish the narrower result shown here: in this setup, foreign-key enforcement was runtime connection state. If SQLite is carrying relational data, treat that state as something to initialize and verify, not something to infer from the table definition.

The Booking Test That Passed the Wrong Answer

Take an existing booking [10, 20) and a requested booking [5, 25). They share ten units of time, so the request must be rejected. Yet a tempting overlap check asks only whether the new booking's start or end falls inside the existing one. Both endpoints sit outside [10, 20), so that check returns False. A booking that surrounds another has slipped through.

The boundary convention matters. These are half-open intervals: the start is included and the end is excluded. A booking ending at 20 may therefore sit next to one starting at 20 without a conflict. For positive-duration intervals, the compact rule is that each booking must start before the other one ends:

def overlaps(new_start, new_end, existing_start, existing_end):
    return new_start < existing_end and existing_start < new_end


cases = [
    ((5, 25, 10, 20), True),
    ((5, 10, 10, 20), False),
    ((20, 25, 10, 20), False),
]

for args, expected in cases:
    assert overlaps(*args) is expected

print("checked", len(cases), "cases")

This small snippet was executed as written and checked the surrounding case plus both touching boundaries. It is an illustration, not a production booking component: it does not validate inputs or address dates, time zones, storage, concurrency, or multiple existing bookings.

The more interesting failure is in the test oracle. In the bounded demonstration, a weak suite included the surrounding interval but calculated its expected answer with a copied version of the same endpoint-only rule. The deliberately faulty implementation passed all 9 of those tests. When the expected answers came instead from the written interval contract, it passed 8 of 9 and failed exactly on [5, 25). The corrected predicate passed all 9 requirement cases. It also failed the weak suite on that same case, because the weak suite expected the wrong answer.

That is why adding more examples to a circular oracle is not enough. Write the requirement table first and make its expected results literal: gaps before and after, touching at either boundary, partial overlaps, a booking contained inside another, a booking that contains the existing one, and identical intervals. Then run both the suspected implementation and the test oracle against that table. A correct implementation should not be forced to agree with a copied mistake.

For AI-assisted testing, the same order is useful: ask for the cases and expected outcomes from the stated booking rules before asking for executable tests. Review the surrounding and touching cases yourself. This demonstration used nine selected integer intervals, not a failure-rate estimate or evidence about generated code in general. It establishes one precise counterexample and a practical way to keep the specification separate from the predicate.

The Fields a Contact Export Forgot

A deliberately constructed contact-migration test produced a result that is easy to misread: a flat CSV imported cleanly, and all three rows came back. The reconstructed contacts still differed from their originals in nine contact fields.

This was a constructed synthetic demonstration, not real product testing or an AI benchmark. The input contained three invented contacts. Each had an identifier, a name, two labelled phone numbers, two tags and a note.

What the narrow format dropped

The first export used only three columns: id, name and phone. Its exporter selected the first phone number. The matching importer recreated one unlabelled number, an empty tag list and an empty note. Names and first numbers survived. String identifiers such as 0007 kept their leading zeroes.

For each contact, the phone list, tag list and note changed. Across the three contacts, that meant three secondary numbers disappeared, all six phone labels disappeared, all six tags disappeared and all three notes disappeared. Counting imported rows would have reported success while missing every one of those losses.

The difference is in the schema, not in the comma. A representation that stores only one scalar phone value cannot preserve a list of labelled numbers. A representation that stores the list as structured data can, provided the importer understands that structure.

Here is the small self-contained comparison used for the illustrative example:

import json

contact = {
    "id": "0007",
    "phones": [{"label": "mobile", "number": "+1-202-555-0101"}],
}
flat_row = {"id": contact["id"], "phone": contact["phones"][0]["number"]}
complete_row = {
    "id": contact["id"],
    "phones_json": json.dumps(contact["phones"]),
}
print(flat_row["id"], flat_row["phone"])
print(json.loads(complete_row["phones_json"])[0]["label"])

0007 +1-202-555-0101
mobile

The full demonstration also tried a versioned JSON export and a CSV whose list fields were JSON-encoded. Both reconstructed the three synthetic contacts exactly. That result applies to those deliberately paired exporters and importers; it does not prove that another application will understand the same encoding or support every field.

Before moving an address book

1. Create disposable test contacts with multiple labelled numbers, several tags, a multiline note and, if supported, an identifier with a leading zero.
2. Export them and import into a separate test address book.
3. Compare fields individually: secondary numbers, labels, tags, notes and identifier types. Do not stop at the contact count.
4. Keep the original address book and its backup until those checks pass.

An export is a schema even when it looks like a harmless spreadsheet. The row count tells you how many records crossed the boundary; the fields tell you whether the address book did.

Keep One Strange Word

Put two translations of the same short poem side by side. In one, every sentence moves easily. In the other, a clause sounds slightly wrong: the order is unfamiliar, or a verb seems to carry more weight than the surrounding prose can comfortably hold. Most readers will reach for the smooth version first. It feels finished.

That instinct is understandable, but a translation that removes every snag can remove the choices the original forced. A translation does not transfer words like luggage from one language to another. It rebuilds decisions under different conditions. Some decisions can be made invisible. Others need to remain audible.

Suppose the source contains a verb that could mean hold, keep, or carry. The translator has to choose. “Hold” suggests an action in the present; “keep” introduces possession or refusal; “carry” gives the action duration and weight. None is a neutral replacement. The reader does not receive a dictionary entry. The reader receives a person doing something, and the chosen verb determines what that something is.

This does not make awkwardness automatically virtuous. A typo is not a mystery. Dead syntax is not depth. A joke that depends on a sound may need to be rebuilt rather than preserved literally. The useful question is not, “Does this sentence sound foreign?” It is, “What work was the difficulty doing?” If the strange order creates hesitation, that hesitation may belong in the new version. If it only blocks the meaning, solve it. If the original contains a wordplay that cannot survive, create a different pressure elsewhere or admit that something was lost.

Readers can test this without knowing the source language. Read the smooth version aloud, then return to the sentence that felt resistant in the other. Mark what changed: the pace, the actor, the direction of an action, the degree of certainty. Sometimes the awkward line is merely poor writing. Sometimes it is the only place where the translator has refused to make a decision on the reader’s behalf.

There is a genuine trade-off. A translation meant to be read by many people cannot turn every sentence into a puzzle. Smoothness is useful. The problem is unearned smoothness: prose so polished that no trace remains of the uncertainty, conflict, or double meaning that had to be resolved. Fluency can become a disguise for interpretation.

The translation worth keeping is not necessarily the one that feels most comfortable. It is the one whose difficult choices can still be located. When a sentence resists a second reading, that resistance may be a defect—or it may be evidence that the source has not been flattened into a single convenient answer. When a translated sentence becomes effortless, did it become clearer, or did someone quietly decide for you?

A Discount Answers Only One Question

Imagine an online cart containing a replacement filter and a notebook. The total is €47.60. The checkout page promises free delivery at €50, so you add a €4.20 cable you had not planned to buy. Nothing about the filter changed. Nothing about the notebook changed. The only new problem is that the cart is below a line drawn by the seller.

The arithmetic presented by the page is seductive: spend €4.20 and avoid a delivery charge. But the real comparison is not “buy the cable or pay for delivery.” It is “buy the cable and receive delivery” versus “keep the original order, pay for delivery, and keep €4.20.” The word free has moved the shipping cost out of one column and placed a new purchase in another. The total may be lower; it may not. More importantly, the threshold has changed what counts as the decision.

A minimum is easy to mistake for a finish line. You are no longer asking only whether an item solves a problem. You are asking how close you are to qualifying. Distance becomes evidence. A cable selected because it closes a gap can feel justified even when the gap was never yours to close. It may become useful later. That possibility is not proof that it was needed now.

Thresholds are not automatically bad. If you already need detergent next week, adding it to an order can be sensible. If the delivery charge is large compared with the original purchase, accepting the extra cost may be poor arithmetic. If the added object replaces a trip you would make anyway, the calculation changes again. The point is not to reject the offer. It is to keep the original need visible while considering it.

The checkout page does not have to prove that the cable is a good cable. It only has to make the gap noticeable. A progress bar saying “€2.40 to free delivery” turns an optional purchase into a near miss. The number creates a small unfinished shape, and the easiest way to complete it is to buy something. The screen has made its threshold feel like your task.

A simple test is to remove the last item and look at the order again. State the original problem in one sentence. Then compare the cost of solving that problem with delivery included against the cost of adding an item chosen mainly to cross the line. If the extra item has a separate use you can name, it remains a genuine candidate. If its only job is to defeat the checkout message, it is not saving money; it is changing the subject.

The same distinction applies to a sale sticker. A forty-percent reduction answers how much less an object costs than before. It does not answer whether the remaining price belongs in your plans, your storage, or your week. A lower number is useful information, but it is not a reason by itself.

Before paying, remove the last item and let the original order stand on its own. If it still makes sense with its actual delivery cost, you have a choice. If the added item is doing all the persuading, the offer has not helped you complete the purchase. It has given you a different problem: how to justify the thing you bought to reach the threshold.

A Photograph Without a Name

Imagine opening a cardboard box during a house move. The prints inside are dry, their edges unbent, and most have a date or a name written on the back. One shows three people standing beside a fence: a child in a striped shirt, an older woman holding a hat, and a man looking away from the camera. On the reverse there is only "July 1987." The picture has survived. The part that would let a stranger place it has not.

That missing note is not a minor defect. It changes what the photograph can do. Anyone can inspect the faces, clothing, weather, and arrangement of bodies. They cannot tell who the people were to one another, where the fence stood, or why this particular afternoon deserved a place in the box. The image remains visible, but its connections have been cut.

Preservation has two jobs. The first protects the object: keep the paper dry, the file readable, the recording intact. The second preserves enough context for another person to use what was saved. Without the second, an archive becomes a collection of survivals rather than a body of knowledge. It contains evidence, but fewer ways to ask the evidence a sensible question.

A short caption can change that. "Mara, Petru, and their neighbour at the orchard, 1987" does not explain the whole scene, and it does not need to. It gives a future reader several handles: three names, a relationship that may still need clarification, a place, and an approximate date. A note saying "people unknown" is also useful. It records a boundary instead of silently inviting guesses to harden into facts.

This is why labeling is not clerical decoration. It is part of preserving the thing itself. The label may be wrong, so it should distinguish memory from certainty; it may be incomplete, so it should leave questions visible. But postponing every explanation until later assumes that later will contain the same witnesses, the same vocabulary, and the same reason for keeping the object. Those conditions are not guaranteed.

The same distinction applies beyond photographs. A box of tools without names, dates, or notes about a repair can outlast the person who knew what each one was for. A folder of recordings can remain perfectly playable while losing the conversation around them. Keeping the container is not the same as keeping the route back to its contents.

Context also has a time dimension. The person writing a caption may know which details seem obvious today and therefore leave them unstated. Years later, a familiar name can become an unexplained label, and a place known to everyone in one household can become nowhere in particular to the next reader. Writing down the obvious is often the part most likely to be skipped because it feels too ordinary to deserve preservation. A caption admits that knowledge has an expiry date.

Good archiving does not require a grand account of every item. It requires enough honest detail that someone else can tell recognition from invention. When we say we are saving something for the future, are we saving the object—or the chance for someone to understand what they are looking at?

The Lost Phone Is Part of the Login

Imagine a contractor arriving at a client site, opening a laptop, and finding the password rejected. The reset link goes to an old address. The second factor goes to a phone left in a taxi. The recovery codes are printed in a drawer that is now locked. Nothing has necessarily been hacked. The person has simply reached the part of the system that the login screen never described.

A password reset is not a recovery plan. It changes a secret when one particular route remains available. Recovery begins when that route is gone: the phone is lost, the mailbox is inaccessible, the authenticator was replaced, or the account was created by someone who no longer works there. The central question is no longer whether this user can choose a new password. It is what evidence the system can still accept that this account belongs to this person.

That distinction matters because the two jobs have different failure modes. A reset that is too easy can hand an account to whoever controls a weak fallback. A recovery process that demands a vanished device or an unreachable administrator can turn the rightful owner into an intruder in their own account. There is no frictionless solution hiding between those outcomes. The design chooses where the friction will be paid: during setup, during an emergency, or by the people who review an exception.

Consider three recovery options: a link by email, a code from an authenticator, and a support review. This looks like redundancy until all three depend on the same old phone, mailbox, or employer. They are then separate buttons attached to one dependency. A more durable arrangement spreads the proof across places that do not fail together: a code stored outside the device, a current contact route, a documented way to retire the old device, and an escalation path with evidence requirements. Each item adds work before it is needed. That is not waste; it is the price of having more than one way back.

The awkward part is that recovery plans decay. People change numbers, close addresses, replace phones, leave teams, and forget where they put the codes. A plan can be perfectly designed on the day it is written and useless a year later. It needs a small test while the normal login still works. Can the backup code be found? Does the recovery address still receive mail? Can the old device be removed without first using the old device? These are not hypothetical questions to the person standing outside the account.

This is also why a reset link is a poor answer to an outage or lockout. The link proves that one channel is reachable. It does not prove that the account's other dependencies are known, current, or independent. A recovery process is closer to a continuity plan than to a forgotten-password feature. It describes what happens when the most convenient proof disappears, not just how to repeat the usual login with a new secret.

There is a human cost to getting this wrong, but it is not solved by making support improvise. The person who cannot log in may be careless, unlucky, or under attack; the interface cannot settle that by sympathy. It needs a defined boundary between evidence and assertion, and a way to record which recovery choices are still trustworthy. Otherwise the system oscillates between a dangerous shortcut and an inflexible refusal.

The next time a service offers Forgot password?, the useful question is what remains when the link, phone, and remembered secret fail together. That answer is the real recovery design. When the ordinary login disappears, what does the system still recognize, and who decided that it would?

A Recipe Cannot Taste for You

Imagine a recipe card propped against a jar beside a mixing bowl. The instructions are tidy: add the flour, stir until combined, season to taste. Nothing is obviously wrong with them. The trouble begins when the hand holding the spoon has to decide what “combined” looks like.

At first, the mixture is loose and streaked. A little later, it forms a mass but still clings to the spoon. Later still, it becomes smooth enough to hold its shape. All three states could be defended as an honest reading of the instruction. The card has named an action and skipped the evidence that would tell the cook when the action has done its work.

This is the central weakness of many instructions: they describe movement more readily than judgment. Stir. Fold. Reduce. Season. These verbs make a recipe look complete, but each one contains a small decision. How long is enough? What change matters? Which imperfection is harmless, and which one means stop?

A more useful recipe does not need to become a lecture. It can add a visible or sensory checkpoint. The mixture should stop leaving dry streaks around the bowl. The sauce should coat the back of the spoon instead of running away at once. The salt should make the other flavors clearer, not announce itself as a separate event. These details do not replace the cook’s judgment. They give it something to work against.

There is a trade-off here. Measurements and fixed times make instructions easy to copy, but they can create false confidence when the important condition is not the number. Cues such as texture, smell, color, or resistance are harder to standardize. They also expose the part of the task that cannot be outsourced to the card. That makes the recipe less mechanical, but more honest.

“Season to taste” is often treated as a casual phrase, almost an apology for imprecision. It is better understood as a handover. The writer has reached the point where a private judgment must be made by the person at the counter. That handover can be sensible. It can also be lazy. The difference is whether the recipe has supplied enough surrounding detail to make the decision possible.

This distinction matters when a dish goes wrong. The useful question is not simply whether the cook followed the steps. It is which observation the instructions failed to name. Was the mixture still streaked? Did the sauce remain thin? Did the seasoning disappear rather than balance? A finished plate cannot answer those questions by itself; the missing checkpoint has already vanished into the process.

A recipe is therefore more than a list of actions, but less than a guarantee. Its job is not to taste for you. Its job is to show where taste, sight, touch, and timing must take over—and to make that boundary visible before the bowl is full.

The Shelf Comes Up Short

Imagine a shelf board laid across two brackets. You mark the line, make the cut, and lift the board into place. It comes up short. Not dramatically; just enough that one end no longer reaches its support. No one saw the cut, so there is no audience to blame. There is only the board, the brackets, and the plan you thought you were following.

The first temptation is to treat the shortage as a verdict. Throw the board away and start again. The second is to conceal it: move a bracket, add a spacer, or push the board toward one side until the mismatch is less visible. One response protects the material by sacrificing the plan. The other protects the plan by asking the installation to absorb the mistake.

A better question is not simply, “How do I make this fit?” It is, “Which part of the arrangement is actually fixed?” The board may be replaceable. The bracket positions may already be dictated by holes in the wall. The deadline may matter more than the original length. The appearance may be negotiable, or it may be the point of the shelf. Until those constraints are separated, every correction looks like failure because the first drawing is being treated as sacred.

This is the useful lesson in a small workshop problem: a correction is part of making, not proof that the first plan must be protected. There are at least three honest choices. Replace the board. Reset the brackets and keep the material. Or change the design so the shorter board has a deliberate purpose, perhaps as a narrower shelf beside the original one. None of these choices is automatically wise. What matters is that the new object is chosen rather than disguised.

That distinction matters because adaptation can become evasion. A spacer that is visible, stable, and included in the design is one thing. A hurried patch hidden behind the board is another. From the front, both may appear to solve the same problem. They do not make the same claim about the work. One says, “The arrangement changed.” The other says, “Please do not inspect the joint.”

The physical details keep the judgment honest. A moved bracket leaves old holes. A discarded board leaves a cost. A shortened shelf changes what can be placed on it. A new plan may be less elegant than the first sketch and more useful in the actual wall. Those consequences are not punishments for being imperfect; they are information about what the correction requires.

This is also why “make it fit” is too small a goal. Fit can be achieved by forcing, hiding, or redesigning. Only one of those necessarily produces an arrangement worth keeping. Before reaching for another patch, identify the constraint you are preserving: the material, the mounting points, the schedule, the appearance, or the intended use. Then make the next cut answerable to that choice.

When the shelf comes up short, the real decision is not whether the first measurement was embarrassing. It is whether the next version will be a concealed mistake or a different object that can stand on its own.