DEV Community: Paul Rijke

Distinguishing Stubs from Mocks in Mockery

Paul Rijke — Sun, 01 Feb 2026 17:39:15 +0000

In modern unit testing, the clarity of your test code is just as important as the logic itself. For years, PHP developers using Mockery have relied on shouldReceive() as a "catch-all" for test doubles. However, as the library has evolved, a clearer distinction between Stubs and Mocks has emerged that makes tests more readable and less prone to false positives.

This need for this shift was highlighted recently by Joel Clermont in his article, “Don’t forget this when writing mock assertions”. He pointed out a common pitfall: using shouldReceive() without an explicit expectation like once(). In these cases, Mockery defaults to "zero or more" calls, meaning your test might pass even if the method is never actually executed.

1. The Fundamental Difference
To write better tests, we must distinguish between how data enters your system and how signals leave it.

Stubs (Indirect Input): These provide the "canned responses" (data) your application needs to function. You don't necessarily care if the method is called once, twice, or at all—you just need it to return a specific value when it is called.
Mocks (Indirect Output): These verify that your system performed a specific action, such as sending an email or saving a record. The verification is the goal of the test.

2. Implementation: allows() vs. expects()
Mockery v1 introduced a more expressive syntax to replace the ambiguous shouldReceive().

Scenario A: Stubbing with allows()
Use this when your test object needs data from a dependency. For example, a repository finding a record:

// We are providing data so the application can continue (Input)
$userRepository->allows()->find(123)->andReturns($user);

Why use this? Using allows() signals to other developers that this is a dependency setup, not a strict requirement. If your implementation changes and calls find() twice instead of once, the test won't break unnecessarily. It is resilient to refactoring.

Scenario B: Mocking with expects()
Use this when you must verify that a side-effect occurred. For example, ensuring a notification was dispatched:

// We are verifying that an action took place (Output)
$paymentGateway->expects()->charge($amount);

Why use this? The expects() method automatically sets a default requirement that the method must be called exactly once. It eliminates the risk mentioned by Joel Clermont where an assertion is forgotten. If the method isn't called, the test fails.

3. Comparison Summary

Feature	Mockery method	Primary purpose
Stub	$m->allows()	Provide data to the test
Mock	$m->expects()	Verify an action happened
Legacy	$m->shouldReceive()	Ambiguous / Combined

Why stop using shouldReceive()?
While shouldReceive() is still working, it lacks intent. When a developer reads a test using shouldReceive(), they have to scan the rest of the chain for once() or andReturn() to understand what is being tested.

By switching to allows() and expects(), the intent is communicated immediately. You clearly separate the setup of your environment from the assertions of your behavior.

Why 100% PHP Test Coverage is (Mostly) BS

Paul Rijke — Thu, 07 Aug 2025 06:28:01 +0000

Alright, let's talk testing. Specifically, let's talk about this almost religious pursuit of 100% test coverage. You see it plastered on project dashboards, whispered in hushed tones during code reviews, and sometimes even demanded by management who might not fully grasp what it actually means. And for years, I, like many others, bought into it. "100% coverage means my code is perfect, right?" Oh, the blissful naivety. Now? I'm here to tell you, from the trenches of countless hours spent wrestling with PHPUnit and Co., that chasing 100% test coverage is, in large part, utter BS.

1. The Metric Trap: Chasing Numbers, Not Confidence

This is the big one for me. When you aim for 100% test coverage in PHP, you're inevitably shifting your focus from writing good, robust code to writing code that looks like it's being tested. And it’s eerily similar to that old programmer cliché: measuring performance by counting lines of code. More lines of code doesn't mean better code. More lines of test code doesn't automatically mean more confidence in your application.

I've spent an embarrassing amount of time writing tests that, frankly, are only there to tick a box. Tests that assert the obvious, tests that just call a method with some arbitrary data and check if it returns something, tests that barely scratch the surface of what could actually go wrong. It’s the equivalent of having a chef boast about the sheer number of obscure spices they crammed into a dish, rather than the fact that the steak is perfectly cooked and the sauce is a revelation. I’ve been there, staring at a coverage report, desperately trying to get that last 0.5% out of some obscure getter method, while the core logic of my application still feels… a bit wobbly. The pursuit of coverage becomes the goal, rather than a means to building reliable software. (Goodhart's Law)

2. The "Good Enough" Siren Song: Complacency by Report

Here’s where the laziness factor kicks in, and I’m not proud to admit how often I’ve fallen victim to it. The moment that little coverage report proudly displays "100%", a little voice in my head (and sometimes, let's be honest, my manager’s voice) says, "Great! It’s covered. We’re done." And that’s incredibly dangerous. It’s the ultimate permission slip to stop thinking critically about the quality of the tests, or more importantly, the quality of the code itself.

I’ve seen projects where, once 100% coverage was achieved, the motivation to refactor, to improve the existing code, or to even write better tests for new features just… evaporated. Why bother, when the number is already perfect? It’s like a student finishing an essay by hitting the word count and then deciding they’ve aced the assignment, without actually re-reading it to ensure it’s coherent or persuasive. This "good enough" mentality is the antithesis of craftsmanship. It encourages a superficial approach where the appearance of thoroughness trumps the actual substance of robust, maintainable code. I’ve definitely been guilty of hitting that 100% and thinking, "Phew, dodged that bullet," instead of thinking, "Okay, now how can I make this truly solid?"

3. Mission Critical Gets Drowned Out by the Noise

This is the often-overlooked consequence. When you're chasing 100% coverage, your precious development time and mental energy get spread incredibly thin. Less significant, boilerplate code gets the same attention – the same agonizing over test cases – as the mission-critical, complex pieces of logic that actually drive your application.

Think about it: some parts of your PHP application are absolutely vital. These are the bits that handle transactions, user authentication, core business rules. These are the areas where a bug can have catastrophic consequences. But when you’re aiming for absolute coverage, you end up spending an equal amount of time writing tests for a simple helper function that converts a string to lowercase. The focus gets diluted. The truly important, high-risk areas don't get the concentrated, expert attention they deserve because you’re too busy trying to cover every single line of code, no matter how trivial. I’ve witnessed firsthand how this leads to perfectly tested but ultimately flawed applications because the critical pieces were treated with the same level of scrutiny as the decorative bits. It’s like a surgeon spending more time polishing their scalpel than focusing on the intricate organ they’re operating on.

So, What's the Alternative?

Look, I'm not saying testing is bad. Far from it. Good, well-written tests are the bedrock of maintainable software. But we need to be smarter about how we test and what we aim for. Instead of a blind pursuit of 100%, let's focus on:

Meaningful tests: Tests that actually verify behavior, edge cases, and potential failure points in your critical logic.
Confidence over coverage: Aim to have high confidence in the most important parts of your application, rather than a high number for everything.
Testing what matters: Invest your time in testing the complex, risky, and core functionalities. Let the simple setters and getters fend for themselves, or test them with a minimal, sensible approach.
Continuous improvement: See testing as an ongoing process, not a one-time checkbox.

Chasing 100% PHP test coverage can feel like a tangible, reassuring goal, but in my experience, it's a distraction from the real work of building high-quality, resilient software. It’s time we stopped worshipping the coverage report and started focusing on the actual confidence and quality it’s supposed to represent. Because honestly, a well-tested 90% is far more valuable than a poorly tested, complacency-driven 100%.

TIL: Why PHPMD and SonarCloud don’t always agree

Paul Rijke — Sat, 12 Apr 2025 07:50:07 +0000

Here’s a good one for the “quirks of tooling” file. We set up both SonarCloud and PHPMD to enforce a limit on the number of public methods in our classes. Same limit, same rules... or so we thought. But then SonarCloud flagged way more issues than PHPMD, and we were left scratching our heads. Naturally, we dove in to figure out what was going on. Spoiler alert: it wasn’t a bug—it was a feature.

PHPMD Has a Secret List of “Favorite” Methods

After some investigation, we discovered that PHPMD doesn’t count every method by default. Instead, it skips certain methods based on their names. The documentation claims that only get and set methods are ignored by the TooManyMethods rule.

But wait! The actual default behavior is even sneakier. Here’s the real regex pattern PHPMD uses by default:

<property name="ignorepattern" value="(^(set|get|is|has|with))i"/>

So in reality, PHPMD also ignores methods starting with is, has, and with. This explains why SonarCloud was flagging more issues—SonarCloud doesn’t play favorites.

Fixing the Mismatch

We decided we didn’t want any special treatment—every method should count, no matter what it starts with. The obvious first step was to leave the ignorepattern empty. But PHPMD didn’t seem to understand “empty” the way we expected, so that didn’t work.

To get PHPMD to count all methods, we had to explicitly override the default pattern. Here’s the configuration we landed on:

<rule ref="rulesets/codesize.xml/TooManyMethods" message="The {0} {1} has {2}. Consider refactoring {1} to keep the number of methods under {3}.">
    <properties>
        <property name="maxmethods" value="20"/>
        <property name="ignorepattern" value="(!)i"/>
    </properties>
</rule>
<rule ref="rulesets/codesize.xml/TooManyPublicMethods">
    <properties>
        <property name="maxmethods" value="20"/>
        <property name="ignorepattern" value="(!)i"/>
    </properties>
</rule>

The regex (!)i essentially tells PHPMD: “Don’t ignore anything. Count every single method.” Now, PHPMD and SonarCloud are on the same page, and our rule enforcement is consistent.

What We Learned

PHPMD is full of surprises: Its default rules skip over methods starting with certain prefixes, and the documentation doesn’t tell the whole story.
Don’t assume tools behave the same way: Just because two tools seem to check for the same thing doesn’t mean their definitions match.
Regex saves the day: To make PHPMD truly count everything, use a pattern like (!)i to ensure no methods are skipped.

A Fun Thought

Maybe PHPMD’s on to something. If we ignored all tasks starting with “fold” or “clean,” wouldn’t life seem a whole lot easier? Unfortunately, our code doesn’t work that way, so neither can we.

Getting Doctrine's ChangeSet in a postUpdate event

Paul Rijke — Fri, 30 Sep 2022 09:11:27 +0000

Recently, I had the need of having the changes of an entity in a lifecycle event after the database was updated. Normally, the postUpdate event doesn't have access to this information. So, what to do?

I figured, that storing the changes during onFlush or preUpdate would do the trick, but how? I did not want to enforce extra database calls. Therefor, the in memory ArrayAdapter of symfony cache to the rescue.

According to the documentation:

Generally, this adapter is useful for testing purposes, as its contents are stored in memory and not persisted outside the running PHP process in any way.

So it is gone after the running process? Exactly what I needed. Here's how I set it during a preUpdate.

class DoctrineSubscriber implements EventSubscriberInterface
{
    private ArrayAdapter $arrayAdapter;

    public function __construct(
    ) {
        $this->arrayAdapter = new ArrayAdapter();
    }

    public function getSubscribedEvents(): array
    {
        return [
            Events::preUpdate, //OR
            Events::onFlush,
            // THEN
            Events::postUpdate,

        ];
    }

    public function preUpdate(PreUpdateEventArgs $args): void
    {
        $entity = $args->getObject();

        if ($entity instanceof Meeting) {
            $this->arrayAdapter->get($entity->getId(), fn () => $args->getEntityChangeSet());
        }
    }
}

Then, you can easily retrieve it using the stored id as the key, like:

public function postUpdate(LifeCycleEventArgs $args)
    {
        $entity = $args->getObject();

        if ($entity instanceof Meeting) {
            $id = $entity->getId();
            $changeSet = $this->arrayAdapter->getItem($id)->get();
        }

    }

If for some reason the database wasn't updated due to errors, the postUpdate isn't called and the changeset disappears. Just as I needed.

If you want to be sure on listeners or subscribers changes your entity before persistence, you should/could use the onFlush event instead, like this:

public function onFlush(OnFlushEventArgs $eventArgs): void
    {
        $uow = $eventArgs->getObjectManager()->getUnitOfWork();

        foreach ($uow->getScheduledEntityUpdates() as $entity) {
            if ($entity instanceof Meeting) {
                $this->arrayAdapter->get($entity->getId(), fn () => $uow->getEntityChangeSet($entity));
            }
        }
    }

Because onFlush is the last event called before database persistence, we're pretty sure nothing altered the changeset afterwards.

As a disclaimer... I use uuid as the id, so I am pretty sure the cache key will be unique for that change.

Using SQLite in test, and why you should be carefull.

Paul Rijke — Mon, 15 Feb 2021 10:07:22 +0000

I recently started using phpunit. Yeah, don't shout at me...! I am just a self taught programmer, and I have to do everything all by myself. Anyway, I become to like testing.

As I am using Symfony a lot, I always watch for tips and tricks. Then I came along this video series of Gary Clarke, which by the way, I respect highly as I am learning much of his videos.

In this video he shows a trick of using an in-memory SQLite database for very fast test-runs. After a little investigation, I started to use it as well.

All went fine, until I started to test my (date-driven) validations. In a specific case, I had to test if a new requested date was bigger than a value in the database. This is for preventing overlapping date ranges.

The used validation runs a DQL in the repository, and if records are returned, the dates overlap.

It worked perfectly in my dev environment (MariaDB), but when I started to write the tests, one assertings continually failed, which actually was valid in my manual dev test.

Here's the QueryBuilder logic involved in the validations:

 return $this->createQueryBuilder('e')
     ->andWhere('e.asset = :asset')
     ->andWhere('(:requestDateTo > e.fromDate AND :requestDateFrom < e.toDate)')
     ->setParameter('requestDateFrom', $booking->getFromDate())
     ->setParameter('requestDateTo', $booking->getToDate())
     ->setParameter('asset', $booking->getAsset())
     ->getQuery()
     ->execute();

Now this worked perfectly fine in my dev environment, but a certain assertion (which I knew had to be right) did fail in test every time.

Long story short, after a lot of debugging I discovered that SQLite (via DQL) is treating a DateTime variable differently. This translates in SQL like:

select * where '2021-01-01 00:00:000000' > date_from;

When a database record exist in the database with type = datetype and value is '2021-01-01', this doesn't return a record in MariaDB, but it will in SQLite. It seems SQLite treats '2021-01-01 00:00:000000' > '2021-01-01' as true, while MariaDB treats this as false.

I eventually solved it by forcing the date parameters in the (SQLite) matching formats, which also works in MariaDB. Ended up with:

 return $this->createQueryBuilder('e')
     ->andWhere('e.asset = :asset')
     ->andWhere('(:requestDateTo > e.fromDate AND :requestDateFrom < e.toDate)')
     ->setParameter('requestDateFrom', $booking->getFromDate()->format('Y-m-d'))
     ->setParameter('requestDateTo', $booking->getToDate()->format('Y-m-d'))
     ->setParameter('asset', $booking->getAsset())
     ->getQuery()
     ->execute();

So, as using SQLite in-memory is a badass trick to quickly run databased involved tests, beware of the quirks that can come up when using a different database typology.