Forem: Philipp Scheit

The Lazy Lurk: A Mental Model for Better Tests

Philipp Scheit — Mon, 01 Dec 2025 19:58:10 +0000

You know how to write tests. Red, green, refactor. Assert this, mock that. But here's a question that might make you uncomfortable:

Could your tests pass with a completely broken implementation?

Let me show you what I mean.

The roundtrip trap

I recently saw this test for an encryption service:

public function test_encrypt_decrypt_roundtrip(): void
{
    $encrypted = $this->encrypter->encrypt('important data');

    $this->assertSame('important data', $this->encrypter->decrypt($encrypted));
}

Looks reasonable, right? Encrypt something, decrypt it, verify you get the original back. Ship it.

But here's the thing: I can make this test pass in 10 seconds.

class Encrypter
{
    public function encrypt(string $data): string
    {
        return $data;
    }

    public function decrypt(string $data): string
    {
        return $data;
    }
}

Test is green. ✅

No encryption happened. Your "important data" is stored in plain text. But the test passes, so everything's fine... right?

Meet the Lazy Lurk

Here's a mental model I use when writing tests:

Imagine the person implementing the code is a lazy lurk. They will do anything to make the test pass - even if it makes no sense.

Not malicious. Just lazy. They want green tests with minimum effort. Your job as the test writer is to make cheating impossible.

Every time you write a test, ask yourself: "What's the dumbest implementation that would pass this?"

If the answer is "do nothing" or "return a hardcoded value" - your test is incomplete.

Classic examples of tests the Lazy Lurk loves

The roundtrip test:

$this->assertSame($input, $serializer->deserialize($serializer->serialize($input)));
// Lazy implementation: return $input for both methods

The single-case test:

$this->assertSame(4, $calculator->add(2, 2));
// Lazy implementation: return 4;

The boolean trap:

$this->assertTrue($validator->isValid('test@example.com'));
// Lazy implementation: return true;

The "it works" test:

$result = $service->process($data);
$this->assertNotNull($result);
// Lazy implementation: return new Result();

How to defeat the Lazy Lurk

The fix is always the same: add another constraint that the lazy implementation can't satisfy.

For the encryption roundtrip:

public function test_encrypt_actually_encrypts(): void
{
    $plaintext = 'important data';

    $encrypted = $this->encrypter->encrypt($plaintext);

    // The Lazy Lurk can't cheat past this
    $this->assertNotSame($plaintext, $encrypted);

    // And we still verify the roundtrip
    $this->assertSame($plaintext, $this->encrypter->decrypt($encrypted));
}

Now the no-op implementation fails. The Lazy Lurk actually has to encrypt something.

For the calculator:

public function test_add(): void
{
    $this->assertSame(4, $calculator->add(2, 2));
    $this->assertSame(7, $calculator->add(3, 4));  // Can't hardcode both!
    $this->assertSame(0, $calculator->add(0, 0));
}

For the validator:

public function test_email_validation(): void
{
    $this->assertTrue($validator->isValid('test@example.com'));
    $this->assertFalse($validator->isValid('not-an-email'));  // Forces real logic
}

The pattern

See what's happening? We're adding triangulation - multiple data points that force a real implementation.

One test case = hardcodeable.
Two contradicting cases = requires actual logic.

It's like GPS. One satellite tells you nothing useful. Two gives you a line. Three gives you a position.

The Lazy Lurk always wins (a little)

Here's the uncomfortable truth: the Lazy Lurk will always get away with something.

No matter how many test cases you add, there's always a gap. Tests can only prove the absence of known issues, not the absence of all bugs. That's not a failure of your tests - that's the nature of testing.

So it's up to you to stop the circle.

TDD is not one loop

Here's something I see developers get wrong all the time (and honestly, I catch myself doing it too): they think TDD is one cycle per feature.

Write test. Red. Write code. Green. Done.

But that's not how it works. One feature is many cycles. You write a test, it fails, you make it pass. Then you think: "Wait, what if the input is empty?" New test. Red. Green. "What about special characters?" Red. Green. "What if it's called twice?" Red. Green.

Each cycle, you're blocking another cheat. Each cycle, the Lazy Lurk has fewer places to hide.

Know when to stop

But here's the trap: you can circle forever.

What about null? What about unicode? What about concurrent access? What about leap years on a Tuesday during a full moon?

At some point, you need to stop. Too detailed tests become a burden:

They're brittle and break on every refactor
They test implementation details instead of behavior
They slow down your build
They make the next developer afraid to touch anything

The Lazy Lurk will get away with something. That's okay. Your job isn't to write perfect tests - it's to write useful tests that catch the important cheats.

Ship it. If the Lazy Lurk's shortcut causes a bug in production, you've just discovered your next test case.

Gelesen: Google Mitarbeiter Nr. 59

Philipp Scheit — Mon, 01 Dec 2025 07:31:53 +0000

Gelesen: Google-Mitarbeiter Nr. 59: Der erste Insider-Bericht aus dem Weltkonzern

Nein: ich habe es nicht selbst gekauft. Und ja: ich bin trotzdem froh, dass ich es geschenkt bekommen habe.

Doug beschreibt als Google Mitarbeiter 59 fast jedes Detail seiner Arbeit bei Google. Seine Funktion als die "Stimme von Google", muss er erst finden, vielmehr erfinden. Er tut sich schwer damit, mit den Visionen der Gründer Larry und Sergey und dem Entwicklungstempo Unternehmen mitzuhalten, welches als einzige Regel "Technik hat Vorfahrt" und "Tu nichts Unmoralisches" zu kennen scheint.

Das Buch ist eigentlich eine Autobiographie eines Mitarbeiters in einem Technologie Startup-Unternehmen. Es liest sich jedoch weder wie eine Biographie, noch wie ein Insiderbericht, sondern eher wie ein Roman. Obwohl man das ein oder andere der Unternehmensgeschichte von Google schon weiß, ertappt man sich trotzdem dabei, wie man mitfiebert und hofft, dass die Maschinen in den drei Rechenzentren den 1 Milliarde-Seiten-Index tatsächlich stemmen können, den Google Yahoo verspricht.

Auch das Ende des Buches liest sich eher wie ein Happy-End einer unglaublichen Geschichte und Reise in einer Welt, die man sich nur schwerlich vorstellen kann: Masseurinnen, tausende von Küchen mit Essen umsonst, einem eigensinnigen Chefkoch inklusive gesamter Kochmannschaft, einem blue-room, um langwierige Entscheidungen in einem Computer-Game auszufighten, Segways auf den Fluren, einem Hockeyfeld auf dem Parkplatz und vieles mehr.

Wenn man die Danksagung liest, hat man fast das Gefühl, die genannten Namen als Freunde gewonnen zu haben, die alle als Akteure in diesem Märchen des Silicon Valleys agieren; Viel lachen, weinen und aneinander geraten.

Meine Gedanken dazu

Ich habe meine Kollegen bei Stammtischen stundenlang angehalten: "Das kann doch nicht sein! Dass SO größere Firmen arbeiten! Das ist einfach ineffektiv! Stell Dir ein Land vor, in dem es nur Unternehmen gibt, in denen die ganzen Zeitverschwender und Faulpelze rausgeschmissen werden und man sich auf das konzentriert, was man am Besten kann."

"Naja, P.", sagen sie, "Du bist in einer kleinen Firma. Bei einem Betrieb mit mehreren hundert Leuten ist das völlig normal."

Ich empfehle euch nur: kauft euch dieses Buch und ihr werdet eines Besseren belehrt. Ich weiß jetzt zumindest: die meisten Milchmädchen-Rechnungen, die ich schon seit Ewigkeiten aufstelle, scheinen in allen Google-Produkten und ganz Google als Unternehmen, in Formeln, Daten und Überzeugungen Platz gefunden zu haben.

Dies bekräftigt mich, weiterhin bei Stammtischen über Meetings, E-Mail-Fluten und Büros außerhalb der Stadt zu fluchen und die Diskussion über Ineffizienz erneut zu entfachen.

Beispiele:

Wenn ich mir einen zweiten Monitor kaufe, der meine Produktivität jeden Tag nur um 5 Minuten steigert, spare ich im Jahr ca 21 Stunden. Selbst bei einem Stundenlohn von 8 EUR, hat sich der Monitor nach einem Jahr rentiert.
Wenn ich einen Koch einstelle, sodass 3 meiner Mitarbeiter nicht jeden Tag insgesamt 2 Stunden von der Arbeit abgehalten werden, um das Essen vorzubereiten. Dann haben 1. meine Mitarbeiter was gesundes zu Essen, was sie produktiver macht, und 2. kann ich die gewonnenen 65 Arbeitstage meiner nicht-kochenden Mitarbeiter für etwas anderes sinnvoller nutzen.

Originally published on ps-webforge.com on February 25th, 2013

Trick for testing exceptions in PHPUnit

Philipp Scheit — Mon, 01 Dec 2025 07:14:39 +0000

When you're using PHPUnit to test for an exception you can use $this->expectException(EvatrInvalidVatNumberException::class); for setting up your test to listen to the exception. If the expected exception is not thrown your test will fail and PHPUnit will report the issue.

When you only need to assert the message (or a substring) you would use $this->expectExceptionMessage().

In most test cases this works very well. But sometimes you might want to assert some more aspects of the exception. For example if it contains some debug infos.

Of course you could try to use $this->expectExceptionObject() but this is only a shortcut for expecting the class, message and code. It won't compare properties on the exception for example (!).

You could assert that the exception is thrown when you write the whole test by hand like this:

public function testAnExceptionIsThrown(): void 
{
  try {
    $this->start();
  } catch (Domain\Exception $e) {
    $this->assertEquals('some debug info', $e->debugInfo);
    return;
  }

  $this->fail('Expected Exception is not thrown');
}

This works. But its not very nice. The fail now does not provide any information anymore which exception is thrown instead. Therefore does not convey why the tests fails. And the return in the catch is hard to read and easy to miss.

Looking closer at it, there is another issue. The exception count is wrong: assertContains when the test passes, but actually you have two assertions

The correct exception is thrown
The exception contains the debug info

A Better Approach

public function testAnExceptionIsThrownWithDebugInfo(): void
{
  $this->expectException(Domain\Exception::class);

  try {
    $this->start();
  } catch (Domain\Exception $e) {
    $this->assertEquals('some debug info', $e->debugInfo);
    throw $e;
  }
}

Testing the exception like this has some advantages:

Assertion count is now correct
Your test will still be reporting correctly if the exception is changed
It's more readable
When you miss to add the throw the test will still fail
The failing test (wrong exception thrown) will report nicely which exception is caught instead and skip the assertEquals

Insights from the comments

Be extra careful, when using something like

class Domain\Exception extends \RuntimeException
{
    public function __construct(
        string $message = '',
        int $code = 0,
        \Throwable $previous = null,
        public string $debugInfo = '';
    ) {}
}

// and in the test:
$this->expectExceptionObject(
     new Domain\Exception(
         message: 'this went wrong', 
         debugInfo: 'someDebugInfo',
      ),
);

Because the phpunit implementation (til 15) is:

final protected function expectExceptionObject(\Exception $exception): void
    {
        $this->expectException($exception::class);
        $this->expectExceptionMessage($exception->getMessage());
        $this->expectExceptionCode($exception->getCode());
    }

So the test would not compare the $debugInfo, even if it looks like it SHOULD.

Originally published on ps-webforge.com on March 3rd, 2013, updated Dec 2025