DEV Community: Grégoire Paris

Wiremock + testcontainers + Algolia + Go = ❤️

Grégoire Paris — Fri, 20 Jun 2025 08:16:02 +0000

When dealing with a SaaS like Algolia, testing can be a hassle. Ideally, you should not "mock what you do not own". In other words, you should not mock libraries such as the Algolia SDK, not just because it might evolve in unforeseen ways, but also because writing unit tests for a piece of code where the logic is dictated by something external to the code is not a good idea: you would not be testing the part that has the most complexity.

To take a concrete example, let's imagine you want to index documents in Algolia. There is an end goal behind that, and the end goal is that it is possible to search for these documents.

Ideally, you would have a Docker container running Algolia locally that would be super fast at indexing and use the same code your production Algolia app uses, but sadly that does not exist, and I'm not hopeful it ever will.

In a legacy service I worked on, we have a test Algolia app that we use for integration tests. It worked great, but in the past years, Algolia introduced a new cloud-based architecture, and with this architecture, an indexing task can take a lot more time to be "published". As a result, using a test application on the cloud-based architecture is not an option anymore, as it slows the test suite down to a crawl. 🐌

On a new project, I decided to re-evaluate my options, and remembered a tool that seems to be the next best thing for the job: Wiremock.

In this post, I will guide you through the process of setting Wiremock and testcontainers to test Algolia's own quickstart guide for Golang.

Wiremock: a VCR for HTTP

Wiremock is a testing tool that comes with a so-called "record and
playback" feature.

It means you can do this once in your local environment:

┌────────────┐          ┌────────────────────────────┐       ┌─────────┐
│            ├─────────►│                            ├──────►│         │
│Your service│          │ Wiremock in recording mode │       │ Algolia │
│            │◄─────────┤                            │◄──────┤         │
└────────────┘          └────────────────────────────┘       └─────────┘

In recording mode, you give Wiremock a URL to record, and it will store files representing the requests you made, and the corresponding responses. With Algolia, it can be quite long, especially if you wait for operations.
What happens in practice is that the SDK will use a polling mechanism to check if your task is published. This will result in a lot of similarly looking files.
This is not very interesting to reproduce in your test, so I recommend simply deleting files representing a negative response to the question: "are the changes published yet?". Those typically contain a JSON field called status set to notPublished in their body, like so:

{"status": "notPublished", "pendingTask":false}

When the file is published, this becomes:

{"status": "published", "pendingTask":false}

The files have names that are a bit ugly, so I usually rename them for clarity.
For example, you might rename 1_indexes_test-index_task_226434943725-6e8689fa-9bbb-43fb-9d24-6824c02fc7d5.json
to index_test_task_published.json.

Once your recording is done, you can run your tests like this:

┌────────────┐          ┌───────────────────────────┐
│            ├─────────►│                           │
│Your service│          │ Wiremock in playback mode │
│            │◄─────────┤                           │
└────────────┘          └───────────────────────────┘

In playback mode, Wiremock will respond to your request with the mappings it has stored previously, and pretend to be Algolia. 🥸

While this does not shield you against breaking changes in the Algolia HTTP API, it does come with a few advantages:

It shields you against breaking changes or bugs in the Algolia SDK.
You no longer have to mock the SDK, which is a bad practice and a pain to do. A consequence of that is that your tests become easier to understand, and more expressive, and that they check things at a higher level rather than focusing on implementation details.
It still means that at least once, you do run the tests against the real thing, so if there is some issue that can only be detected at runtime, you will know about it.

Wiremock is a java application, but that shouldn't matter too much, especially given there is an official Docker image you can use.

Testcontainers: Docker for your tests

At ManoMano, we use Gitlab CI. While it is possible to define a Gitlab CI service with the aforementioned Docker image, that's not a great solution because Gitlab services do not expose the full power of Docker. For instance, mounting a volume is not possible, probably not without heavy involvement of privileged users.

A great alternative is testcontainers + testcontainers Cloud. Testcontainers is a library available in many languages that allows you to start and stop Docker containers during your tests, making it possible to get good isolation between tests.
Testcontainers Cloud is a service that allows you to run said containers on a remote infrastructure, as opposed to running them on your own infrastructure, which, if you want to use Kubernetes runners for Gitlab, implies using Docker in Docker, which is not great from the security standpoint.
Locally, you would still use a local docker container, but in the CI,
tescontainers will send requests to testcontainers cloud, to start and stop containers. Enough unpaid endorsement, let's get to the code.

Demo time

Let us follow Algolia's quickstart guide for Golang and see how easy it is to
test.

If you want to follow along, install mise-en-place and let's go!

For the sake of brevity, I will not systematically show the entirety of a file I edit in all snippets, however I have tried to create one commit per step in this Github repository, in case you would like to play with the code or simply read it in your own editor.

Installing Go

$ mise use go@1.24

Creating a new project

$ go mod init algolia-wiremock-testcontainers

Installing the Algolia SDK

$ go get github.com/algolia/algoliasearch-client-go/v4

Setting up the environment

At this point, you will need to set up a test Algolia application. Once you are done, you should have an application ID and an API key.

Let us use an unversioned env file to store our credentials.

# mise.toml
[env]
_.file = ".env"

# .env
ALGOLIA_APP_ID=changeme
ALGOLIA_API_KEY=changeme

You will need to replace ALGOLIA_APP_ID and ALGOLIA_API_KEY with values from your account.

# .gitignore
/.env

Writing the code to be tested

Let us take the code from Algolia's quickstart guide and split it into two files:

First, we have the code under test where the only changes are getting the environment variables from the actual environment, and renaming packages and functions.

// indexer.go

package indexer

import (
    "os"

    "github.com/algolia/algoliasearch-client-go/v4/algolia/search"
)

func indexRecord() {
    // Get Algolia credentials from environment variables
    appID := os.Getenv("ALGOLIA_APP_ID")
    apiKey := os.Getenv("ALGOLIA_API_KEY")
    indexName := "test-index"

    record := map[string]any{
        "objectID": "object-1",
        "name":     "test record",
    }

    // Create a new Algolia client
    client, err := search.NewClient(appID, apiKey)

    if err != nil {
        panic(err)
    }

    // Add record to an index
    saveResp, err := client.SaveObject(
        client.NewApiSaveObjectRequest(indexName, record),
    )

    if err != nil {
        panic(err)
    }

    // Wait until indexing is done
    _, err = client.WaitForTask(indexName, saveResp.TaskID)

    if err != nil {
        panic(err)
    }
}

To make it work, you will need to install the Algolia SDK:

$ go get github.com/algolia/algoliasearch-client-go/v4
$ go mod tidy

That call to WaitForTask is what is going to take the most time, and a good reason not to use a real Algolia instance in your test suite. That's what we are going to try first though.

Writing the test with a real Algolia instance

Let's start simple and write a first version of the test that talks directly to Algolia:

// indexer_test.go

package indexer

import (
    "os"
    "testing"

    "github.com/algolia/algoliasearch-client-go/v4/algolia/debug"
    "github.com/algolia/algoliasearch-client-go/v4/algolia/search"
)

func TestIndexRecord(t *testing.T) {
    // helps with seeing the progress, since this is super long
    debug.Enable()

    appID := os.Getenv("ALGOLIA_APP_ID")
    apiKey := os.Getenv("ALGOLIA_API_KEY")
    indexName := "test-index"

    client, err := search.NewClient(appID, apiKey)
    if err != nil {
        t.Fatalf("Failed to create client: %v", err)
    }

    // Create index indirectly by setting settings
    _, err = client.SetSettings(client.NewApiSetSettingsRequest(
        "test-index",
        search.NewEmptyIndexSettings().SetSearchableAttributes(
            []string{"name"},
        ),
    ))

    if err != nil {
        t.Fatalf("Failed to set settings: %v", err)
    }

    t.Cleanup(func() {
        // Ensure the test index is deleted after the test completes
        _, err := client.DeleteIndex(client.NewApiDeleteIndexRequest(
            indexName,
        ))
        if err != nil {
            t.Fatalf("Failed to delete index: %v", err)
        }
    })

    // Call the function under test
    // this should index a record in Algolia
    indexRecord()

    // Verify the record was indexed by searching for it
    // This search should return record with "test" in their contents
    // The quickstart guide currently uses a more complex version of this
    searchResp, err := client.SearchSingleIndex(
        client.NewApiSearchSingleIndexRequest(indexName).
            WithSearchParams(
                search.SearchParamsObjectAsSearchParams(
                    search.NewEmptySearchParamsObject().
                        SetQuery("test"),
                ),
            ),
    )

    if err != nil {
        panic(err)
    }

    // Assert that there are hits
    if len(searchResp.Hits) == 0 {
        t.Fatal("No hits found")
    }
}

aaaaand that doesn't work:

panic: The maximum number of retries exceeded. (50/50) [recovered]
        panic: The maximum number of retries exceeded. (50/50)

goroutine 7 [running]:
testing.tRunner.func1.2({0x800600, 0xc00028d640})
        /home/gregoire/.local/share/mise/installs/go/1.24.2/src/testing/testing.go:1734 +0x21c
testing.tRunner.func1()
        /home/gregoire/.local/share/mise/installs/go/1.24.2/src/testing/testing.go:1737 +0x35e
panic({0x800600?, 0xc00028d640?})
        /home/gregoire/.local/share/mise/installs/go/1.24.2/src/runtime/panic.go:792 +0x132
algolia-wiremock-testcontainers.indexRecord()
        /home/gregoire/Documents/blogging/wiremock/indexer.go:39 +0x166
algolia-wiremock-testcontainers.TestIndexRecord(0xc000198540)
        /home/gregoire/Documents/blogging/wiremock/indexer_test.go:40 +0x20a
testing.tRunner(0xc000198540, 0x8a6c10)
        /home/gregoire/.local/share/mise/installs/go/1.24.2/src/testing/testing.go:1792 +0xf4
created by testing.(*T).Run in goroutine 1
        /home/gregoire/.local/share/mise/installs/go/1.24.2/src/testing/testing.go:1851 +0x413
FAIL    algolia-wiremock-testcontainers 185.745s
FAIL

I have many applications on this instance, some of which are very busy, let us patch that real quick:

// Wait until indexing is done
_, err = client.WaitForTask(
    indexName,
    saveResp.TaskID,
    search.WithMaxRetries(100),
)

Exactly the type of thing that unit tests will not catch.

After that, the test passes (but it takes between several seconds or several minutes to run depending on how busy the instance on which the application is running is). Great! Now, let's add a proxy in the middle, and record all this.

Adding Wiremock in record mode 📼

We are using Docker, so if we want to obtain the so-called "mapping files" Wiremock will create, we need to mount a volume on our Docker container, and mount it in the right location.

Let us add 2 new dependencies to our project:

We could interact with Wiremock by calling the REST API with the net/http package, but as it turns out, there is a dedicated SDK for that, and it supports recording since this pull request I sent. Let's install it.

$ go get github.com/wiremock/go-wiremock@v1.13.0

Next, we will need a way to start and stop the Wiremock container, and for that
as well, there is a library:

$ go get github.com/wiremock/wiremock-testcontainers-go@v1.0.1

Let us start the container, with a volume mounting testdata in the current directory on /home/wiremock/mappings in the container. This is where Wiremock will create json files.

// indexer_test.go

// for some reason wiremock doesn't like the testing context
ctx := context.Background() 

absolutePath, err := os.Getwd()
if err != nil {
    t.Fatalf("Failed to get current working directory: %v", err)
}

// Start the Wiremock container,  using the testcontainers library
container, err := testcontainers_wiremock.RunContainerAndStopOnCleanup(
    ctx,
    t,
    testcontainers.WithHostConfigModifier(func(
        hostConfig *container.HostConfig,
    ) {
        hostConfig.Binds = []string{
            absolutePath + "/testdata:/home/wiremock/mappings",
        }
    }),
    testcontainers_wiremock.WithImage("wiremock/wiremock:3.12.1"),
)

if err != nil {
    t.Fatalf("Failed to create wiremock container: %v", err)
}

// The endpoint changes every time, so we need to obtain it at runtime
host, err := container.Endpoint(ctx, "")

if err != nil {
    t.Fatalf("Failed to get wiremock container endpoint: %v", err)
}

Next, we need to change how we instantiate the Algolia client, so that it calls Wiremock instead of Algolia:

algoliaClient, err := search.NewClientWithConfig(
    search.SearchConfiguration{
        Configuration: transport.Configuration{
            AppID:  appID,
            ApiKey: apiKey,
            Hosts: []transport.StatefulHost{
                transport.NewStatefulHost(
                    "http",
                    host,
                    func(k call.Kind) bool {
                        return true
                    },
                ),
            },
        },
    },
)

if err != nil {
    t.Fatalf("Failed to create client: %v", err)
}

Note that I have renamed the client to algoliaClient to avoid confusion with the Algolia client and the Wiremock client.

Let us also refactor our indexRecord() function to take the client as an argument:

// indexer.go

func indexRecord(client *search.APIClient) {
    indexName := "test-index"

    record := map[string]any{
        "objectID": "object-1",
        "name":     "test record",
    }

    saveResp, err := client.SaveObject(
        client.NewApiSaveObjectRequest(indexName, record),
    )

    if err != nil {
        panic(err)
    }

    _, err = client.WaitForTask(
        indexName,
        saveResp.TaskID,
        search.WithMaxRetries(100),
    )

    if err != nil {
        panic(err)
    }
}

Next, let's start the recording, and for that we need a client to call Wiremock's administration API:

// indexer_test.go

wiremockClient := wiremock.NewClient("http://" + host)
t.Cleanup(func() {
    err := wiremockClient.Reset()
    if err != nil {
        t.Fatalf("Failed to reset wiremock: %v", err)
    }
})

// Call Wiremock's administration API to start recording
err = wiremockClient.StartRecording(fmt.Sprintf(
    "https://%s-dsn.algolia.net",
    appID,
))

if err != nil {
    t.Fatalf("Failed to start recording: %v", err)
}

t.Cleanup(func() {
    // Call Wiremock's administration API
        // to stop recording and dump the mappings
    err := wiremockClient.StopRecording()
    if err != nil {
        t.Fatalf("Failed to stop recording: %v", err)
    }
})

// code that interacts with Algolia must be after

Now, let's run our tests again, check our testdata directory, and see what's new.

$ ls -1 testdata
1_indexes_test-index-4c8f560d-010a-4db9-916c-f5c112481fc8.json
1_indexes_test-index-e766b4bf-6087-499b-975f-722c451f1d4a.json
1_indexes_test-index_query-e08439bf-fd60-4fac-8181-11b72f7a7a1c.json
1_indexes_test-index_settings-9de043d2-5803-40a0-b19b-49d0d2a17dde.json
1_indexes_test-index_task_228603771246-0004a7a6-3759-452c-8d0d-ea2a2f948ea1.json
1_indexes_test-index_task_228603771246-012f5d71-2645-496c-ba68-b85dcafbce51.json
1_indexes_test-index_task_228603771246-050f8624-f6f5-4815-96ed-03f319cdbda0.json
1_indexes_test-index_task_228603771246-05510684-a31f-41a6-96aa-d722a7527e87.json
1_indexes_test-index_task_228603771246-07651b21-23b0-45b4-9e13-386775c37432.json
1_indexes_test-index_task_228603771246-0bfcad3d-4d19-403f-9197-2fe6214beeb2.json
1_indexes_test-index_task_228603771246-0d450b99-1af0-4761-8d92-d7b92a68c702.json
1_indexes_test-index_task_228603771246-0dd66ddc-d7e2-4f70-8a3f-f5934ade7ac1.json
1_indexes_test-index_task_228603771246-1490e160-63e7-466d-9405-9437efd31c68.json
1_indexes_test-index_task_228603771246-1d25eb69-2a0f-448d-ae60-7075c380837d.json
1_indexes_test-index_task_228603771246-1f675d54-54bc-41cc-a3b4-f3dcc153cb0b.json
1_indexes_test-index_task_228603771246-1f829991-f442-45b6-9463-6ad064eb7576.json
1_indexes_test-index_task_228603771246-22837672-68b3-4684-a1f0-5bf19a8a3e8d.json
1_indexes_test-index_task_228603771246-25162e07-d196-4527-b476-173b7d62acf7.json
1_indexes_test-index_task_228603771246-26087497-e8ee-429a-a98e-a0100219c112.json
1_indexes_test-index_task_228603771246-264ce294-058a-482e-8d33-8be46740c7e9.json
1_indexes_test-index_task_228603771246-272cd045-d145-4b26-86b7-accad674a2db.json
1_indexes_test-index_task_228603771246-2ac3189e-9737-46df-a1b5-269e63a4d36a.json
1_indexes_test-index_task_228603771246-30a023df-b21b-43e7-b1a0-3f3c6ceec6d4.json
1_indexes_test-index_task_228603771246-315a9105-a169-4228-9d6a-7f20e9db3e4a.json
1_indexes_test-index_task_228603771246-3358c4a2-9c5d-4c7f-982f-1ca49c413b08.json
1_indexes_test-index_task_228603771246-34ef8259-1204-4026-9c1d-d43731a8d489.json
1_indexes_test-index_task_228603771246-37be5ee5-2f56-43a9-afe3-866859945d72.json
1_indexes_test-index_task_228603771246-3ba76a13-6052-4b9d-a7f2-61d3d364714d.json
1_indexes_test-index_task_228603771246-3be6df0a-3bcc-4104-81e0-28462875ed86.json
1_indexes_test-index_task_228603771246-3da6c29e-5603-4262-bfa8-37a06b021297.json
1_indexes_test-index_task_228603771246-3e321244-de3c-420e-978e-60b995839ca2.json
1_indexes_test-index_task_228603771246-41ed4f34-d05b-4e30-a9da-fd1b84d85aaa.json
1_indexes_test-index_task_228603771246-420e2d2c-2aa0-4afd-9cdd-5ac6ecc7bd20.json
1_indexes_test-index_task_228603771246-4220ae1a-447c-419f-86f9-6ee5bc40a121.json
1_indexes_test-index_task_228603771246-42b9612d-005a-4e5e-bb8c-e0e431790404.json
1_indexes_test-index_task_228603771246-450ab804-2980-478f-b1f2-c9cef5ba021c.json
1_indexes_test-index_task_228603771246-472b813d-f05a-4bca-bc14-c8f0b085388c.json
1_indexes_test-index_task_228603771246-4802a463-b49f-4ddf-83cd-49af7615c66a.json
1_indexes_test-index_task_228603771246-49ed408e-d531-4bc5-a711-2f1e4acc4ae2.json
1_indexes_test-index_task_228603771246-4a9c9104-f042-4f9a-a56b-dc4a9976bde7.json
1_indexes_test-index_task_228603771246-4ae60200-dbed-4c1b-878f-6dcf53cf4954.json
1_indexes_test-index_task_228603771246-4df81e83-7ce3-4ed1-9102-48c987a675de.json
1_indexes_test-index_task_228603771246-4e11ef64-ade6-40ca-b5c0-8a35684f73cd.json
1_indexes_test-index_task_228603771246-5383a9a9-7023-41f9-8092-09bbde387e7d.json
1_indexes_test-index_task_228603771246-55f8777f-8ff1-4fdb-ae35-86bd8d1641f6.json
1_indexes_test-index_task_228603771246-581cce11-3bbe-4492-b9b2-4bb4db47e50f.json
1_indexes_test-index_task_228603771246-58a94473-05f6-460d-b595-87d67a6389cc.json
1_indexes_test-index_task_228603771246-5aadb748-f27e-40b5-8166-33e61de59888.json
1_indexes_test-index_task_228603771246-5eabca6c-637d-4a3d-a883-9a0ac8d40449.json
1_indexes_test-index_task_228603771246-628fb430-b307-4257-8a23-becfcd8c1649.json
1_indexes_test-index_task_228603771246-660b5321-6c43-41e1-83d8-02f936a09bc9.json
1_indexes_test-index_task_228603771246-6b15a9eb-886f-43ff-af1e-2b82a8dacdf2.json
1_indexes_test-index_task_228603771246-6c610574-d0cf-4272-9260-cd5c42954b1c.json
1_indexes_test-index_task_228603771246-6e0d4b06-c3dc-47b8-858b-1d66ed65f708.json
1_indexes_test-index_task_228603771246-70303855-6eb1-465e-949b-40c85e6b5d2e.json
1_indexes_test-index_task_228603771246-712fc20e-8877-43e0-998b-3408c85a1645.json
1_indexes_test-index_task_228603771246-71ede81b-df18-4f39-97ea-757967a84599.json
1_indexes_test-index_task_228603771246-72c592d9-6d61-4a22-bf3e-3d2559b319a8.json
1_indexes_test-index_task_228603771246-72de2fd6-675c-42e6-85d0-21b3947b3fc1.json
1_indexes_test-index_task_228603771246-74ca6363-881f-49b8-8dac-efd6f5c8d449.json
1_indexes_test-index_task_228603771246-75f4709b-ef34-4eed-9d2e-002a3237a880.json
1_indexes_test-index_task_228603771246-773d2b22-6e45-4b0b-943b-b8e261c38d9b.json
1_indexes_test-index_task_228603771246-7accc591-6809-4483-9b39-578557dcabd3.json
1_indexes_test-index_task_228603771246-7bd2b559-9f16-4c57-92bb-0020763419b1.json
1_indexes_test-index_task_228603771246-837f6509-a8b8-4f0a-98fd-4f3b82349acc.json
1_indexes_test-index_task_228603771246-8875e9eb-07f3-4565-9e45-9db6b8c4a662.json
1_indexes_test-index_task_228603771246-8b464ab1-bef7-4975-972a-c472bfca9a90.json
1_indexes_test-index_task_228603771246-8c42ea24-0b42-4ed3-91a3-7cbce16828e0.json
1_indexes_test-index_task_228603771246-932fe93f-2121-4b1a-bedb-334a4518b986.json
1_indexes_test-index_task_228603771246-9697ecdf-4079-4af0-9df5-2d3f44f2b26c.json
1_indexes_test-index_task_228603771246-9bbbf58d-a4ea-47ba-af43-d7a455cc333a.json
1_indexes_test-index_task_228603771246-9d4fbd76-3f4c-4605-aa88-49d105bf718c.json
1_indexes_test-index_task_228603771246-9f126ad6-8a7a-4a37-80ef-7528c62f939d.json
1_indexes_test-index_task_228603771246-9f247f3d-9ba1-447f-a9d1-f61919a40d65.json
1_indexes_test-index_task_228603771246-a01ab516-b606-47b2-b4db-c1188fd9527a.json
1_indexes_test-index_task_228603771246-a057d6b6-00fe-40ea-aee8-bc0873bfe66d.json
1_indexes_test-index_task_228603771246-a460d1b7-6d5f-46b4-9196-a0a49c6c9e10.json
1_indexes_test-index_task_228603771246-a7c15221-1a8f-48b2-9c20-c90bdb6f0074.json
1_indexes_test-index_task_228603771246-a90bdd7d-7be0-428b-973f-1ba429c10f99.json
1_indexes_test-index_task_228603771246-b06c842b-102e-4ca9-99b2-38d838166480.json
1_indexes_test-index_task_228603771246-b2fbbe73-e3cb-49ee-a008-05a3eb66c93d.json
1_indexes_test-index_task_228603771246-b4a8ce95-12f3-4786-9dca-e989f86873ef.json
1_indexes_test-index_task_228603771246-baf4c6a3-ac78-44df-9e5d-8798e9dcf1ff.json
1_indexes_test-index_task_228603771246-bee44a4d-b090-4ebf-b2c7-3b85a0c92000.json
1_indexes_test-index_task_228603771246-c367963c-3aca-41dd-a570-c3135702c841.json
1_indexes_test-index_task_228603771246-c4f8d672-f2ed-4b37-ad51-04ceacf8f3e0.json
1_indexes_test-index_task_228603771246-cbf506c8-70c9-406a-afaa-7db6b7212345.json
1_indexes_test-index_task_228603771246-cc952870-85f4-4057-bb42-24940e3a9050.json
1_indexes_test-index_task_228603771246-d46e09e2-0634-40c6-b121-9c488000a698.json
1_indexes_test-index_task_228603771246-d85de2d1-2dbd-472f-b7d7-e288f833867c.json
1_indexes_test-index_task_228603771246-d998fa67-ef81-407d-9ced-4549b63be22e.json
1_indexes_test-index_task_228603771246-dbebd7ae-ef9a-41b4-9f67-8e8cb871522f.json
1_indexes_test-index_task_228603771246-dec87bcc-2c17-4f38-97dc-f00d3346a00b.json
1_indexes_test-index_task_228603771246-e1228862-9f69-4224-8f46-135b307edd5a.json
1_indexes_test-index_task_228603771246-e4ea7ed5-6f42-4eb7-a54c-f25609c54f3a.json
1_indexes_test-index_task_228603771246-e4fdbcf5-1941-44bd-87bb-8f7c9b0c4718.json
1_indexes_test-index_task_228603771246-ea16fd95-c2ca-474f-a4d2-e556c5bd158c.json
1_indexes_test-index_task_228603771246-f657c74c-0e47-4a6b-887d-e003ba7118c6.json
1_indexes_test-index_task_228603771246-fa7feea5-229a-49af-ac9d-f4754539eb55.json
1_indexes_test-index_task_228603771246-fb081872-590e-443a-8c8b-957ac58fa541.json
1_indexes_test-index_task_228603771246-ff880e8d-f1cf-43ad-9e21-dfe5dab7a3c7.json

… OK that is quite a lot of files. 😅 As mentioned earlier, a lot of them are about polling.

Let's find the one that we should keep:

$ grep -i published testdata/*task*

testdata/1_indexes_test-index_task_228603771246-0004a7a6-3759-452c-8d0d-ea2a2f948ea1.json:    "body" : "{\"status\":\"notPublished\",\"pendingTask\":false}",
testdata/1_indexes_test-index_task_228603771246-012f5d71-2645-496c-ba68-b85dcafbce51.json:    "body" : "{\"status\":\"notPublished\",\"pendingTask\":false}",
…
testdata/1_indexes_test-index_task_228603771246-3ba76a13-6052-4b9d-a7f2-61d3d364714d.json:    "body" : "{\"status\":\"published\",\"pendingTask\":false}",
…
testdata/1_indexes_test-index_task_228603771246-fb081872-590e-443a-8c8b-957ac58fa541.json:    "body" : "{\"status\":\"notPublished\",\"pendingTask\":false}",
testdata/1_indexes_test-index_task_228603771246-ff880e8d-f1cf-43ad-9e21-dfe5dab7a3c7.json:    "body" : "{\"status\":\"notPublished\",\"pendingTask\":false}",

After removing the files with notPublished, we are left with the following mapping files:

$ ls -1 testdata
1_indexes_test-index-4c8f560d-010a-4db9-916c-f5c112481fc8.json
1_indexes_test-index-e766b4bf-6087-499b-975f-722c451f1d4a.json
1_indexes_test-index_query-e08439bf-fd60-4fac-8181-11b72f7a7a1c.json
1_indexes_test-index_settings-9de043d2-5803-40a0-b19b-49d0d2a17dde.json
1_indexes_test-index_task_228603771246-3ba76a13-6052-4b9d-a7f2-61d3d364714d.json

Switching to playback mode 📺

Now that we have our mapping files, we can switch to playback mode. Let us introduce a constant to turn recording and Algolia debugging on and off:

// indexer_test.go

const record = false

// …

if record {
    debug.Enable()

    err = wiremockClient.StartRecording(fmt.Sprintf(
        "https://%s-dsn.algolia.net",
        appID,
    ))

    if err != nil {
        t.Fatalf("Failed to start recording: %v", err)
    }

    t.Cleanup(func() {
        err := wiremockClient.StopRecording()
        if err != nil {
            t.Fatalf("Failed to stop recording: %v", err)
        }
    })
}

Note that I also moved the call to debug.Enable() to the recording block, when replaying the tests, we do not really need to clutter the output with Algolia debug information.

And now the test fails, with a rather clear error: apparently deleting the files was not enough, and we need to also edit the scenario name to outline that this is no longer the 43rd attempt.

--- FAIL: TestIndexRecord (1.87s)
panic: API error [404]
                                                       Request was not matched
                                                       =======================

        -----------------------------------------------------------------------------------------------------------------------
        | Closest stub                                             | Request                                                  |
        -----------------------------------------------------------------------------------------------------------------------
                                                                   |
        1_indexes_test-index_task_226434943725                     |
                                                                   |
        GET                                                        | GET
        /1/indexes/test-index/task/226434943725                    | /1/indexes/test-index/task/226434943725
                                                                   |
        [Scenario                                                  | [Scenario                                           <<<<< Scenario does not match
        'scenario-1-1-indexes-test-index-task-226434943725'        | 'scenario-1-1-indexes-test-index-task-226434943725'
        state:                                                     | state: Started]
        scenario-1-1-indexes-test-index-task-226434943725-43]      |
                                                                   |
        -----------------------------------------------------------------------------------------------------------------------
         [recovered]
        panic: API error [404]
                                                       Request was not matched
                                                       =======================

        -----------------------------------------------------------------------------------------------------------------------
        | Closest stub                                             | Request                                                  |
        -----------------------------------------------------------------------------------------------------------------------
                                                                   |
        1_indexes_test-index_task_226434943725                     |
                                                                   |
        GET                                                        | GET
        /1/indexes/test-index/task/226434943725                    | /1/indexes/test-index/task/226434943725
                                                                   |
        [Scenario                                                  | [Scenario                                           <<<<< Scenario does not match
        'scenario-1-1-indexes-test-index-task-226434943725'        | 'scenario-1-1-indexes-test-index-task-226434943725'
        state:                                                     | state: Started]
        scenario-1-1-indexes-test-index-task-226434943725-43]      |
                                                                   |
        -----------------------------------------------------------------------------------------------------------------------

After dropping "requiredScenarioState" : "scenario-1-1-indexes-test-index-task-226434943725-43", from the mapping file about polling, the test passes again, only this time, it passes in under 2 seconds.
It is possible to mention which scenario a mapping belongs to, allowing to do things like "On the first 2 calls respond A, and on the 3rd return B". Based on that, it is possible to build a complex choreography of requests/responses, fulfilling all sorts of requirements.

Making it work in the CI

After pushing the code, I got a bad surprise: the test fails in the CI, with the following message:

tc-wiremock.go:73: create container: container create: Error response from daemon: Invalid bind mount config: mount source "/builds/product-discovery/ms.indexer/internal/import/brandsuggestion/testdata" is forbidden by the allow list [/home /tmp] - update the bind mounts configuration and restart the agent to enable

It would seem that we cannot use a bind mount in the CI. Let us use our record constant to make the container options conditional:

// indexer_test.go

if record {
    // Use a bind mount
    opts = append(opts, testcontainers.WithHostConfigModifier(func(hostConfig *container.HostConfig) {
        hostConfig.Binds = []string{
            absolutePath + "/testdata:/home/wiremock/mappings",
        }
    }))
} else {
    // Use a copy operation
    mappingFiles, err := os.ReadDir(absolutePath + "/testdata")
    if err != nil {
        t.Fatalf("Failed to read testdata directory: %v", err)
    }
    for _, mappingFile := range mappingFiles {
        opts = append(opts, testcontainers_wiremock.WithMappingFile(
            mappingFile.Name(),
            "testdata/"+mappingFile.Name(),
        ))
    }
}

When recording, we mount the volume, which is not an issue because we are not in the CI.
Otherwise, we use the WithMappingFile function which relies on a copy operation.
That function is provided by the
wiremock-testcontainers-go library, which abstracts away the low-level testcontainers API so that we can think in terms of mapping files rather than just JSON files.

Not super satisfying, but it works.

Wrapping up

The test is a bit long now, but some parts look generic and reusable. Let us extract them to helpers.

// indexer_test.go

package indexer

import (
    "context"
    "fmt"
    "os"
    "testing"

    "github.com/algolia/algoliasearch-client-go/v4/algolia/call"
    "github.com/algolia/algoliasearch-client-go/v4/algolia/debug"
    "github.com/algolia/algoliasearch-client-go/v4/algolia/search"
    "github.com/algolia/algoliasearch-client-go/v4/algolia/transport"
    "github.com/docker/docker/api/types/container"
    "github.com/testcontainers/testcontainers-go"

    "github.com/wiremock/go-wiremock"
    testcontainers_wiremock "github.com/wiremock/wiremock-testcontainers-go"
)

const record = false

func spinUpContainer(t *testing.T) string {
    t.Helper()

    ctx := context.Background()

    absolutePath, err := os.Getwd()
    if err != nil {
        t.Fatalf("Failed to get current working directory: %v", err)
    }

    var opts []testcontainers.ContainerCustomizer

    opts = append(opts, testcontainers_wiremock.WithImage(
        "wiremock/wiremock:3.12.1",
    ))

    if record {
        opts = append(
            opts,
            testcontainers.WithHostConfigModifier(
                func(hostConfig *container.HostConfig) {
                    hostConfig.Binds = []string{
                        absolutePath + "/testdata:/home/wiremock/mappings",
                    }
                },
            ))
    } else {
        mappingFiles, err := os.ReadDir(absolutePath + "/testdata")
        if err != nil {
            t.Fatalf("Failed to read testdata directory: %v", err)
        }
        for _, mappingFile := range mappingFiles {
            opts = append(opts, testcontainers_wiremock.WithMappingFile(
                mappingFile.Name(),
                "testdata/"+mappingFile.Name(),
            ))
        }
    }

    container, err := testcontainers_wiremock.RunContainerAndStopOnCleanup(
        ctx,
        t,
        opts...,
    )

    if err != nil {
        t.Fatalf("Failed to create wiremock container: %v", err)
    }

    host, err := container.Endpoint(ctx, "")

    if err != nil {
        t.Fatalf("Failed to get wiremock container endpoint: %v", err)
    }

    return host
}

func startRecording(t *testing.T, host string, appID string) {
    t.Helper()

    wiremockClient := wiremock.NewClient("http://" + host)
    t.Cleanup(func() {
        err := wiremockClient.Reset()
        if err != nil {
            t.Fatalf("Failed to reset wiremock: %v", err)
        }
    })

    if !record {
        return
    }
    debug.Enable()
    err := wiremockClient.StartRecording(fmt.Sprintf(
        "https://%s-dsn.algolia.net",
        appID,
    ))

    if err != nil {
        t.Fatalf("Failed to start recording: %v", err)
    }

    t.Cleanup(func() {
        err := wiremockClient.StopRecording()
        if err != nil {
            t.Fatalf("Failed to stop recording: %v", err)
        }
    })
}

func newTestClient(
    t *testing.T,
    host,
    appID,
    apiKey string,
) *search.APIClient {
    t.Helper()

    algoliaClient, err := search.NewClientWithConfig(
        search.SearchConfiguration{
            Configuration: transport.Configuration{
                AppID:  appID,
                ApiKey: apiKey,
                Hosts: []transport.StatefulHost{
                    transport.NewStatefulHost(
                        "http",
                        host,
                        func(k call.Kind) bool {
                            return true
                        },
                    ),
                },
            },
        })

    if err != nil {
        t.Fatalf("Failed to create client: %v", err)
    }

    return algoliaClient
}

func TestIndexRecord(t *testing.T) {

    appID := os.Getenv("ALGOLIA_APP_ID")
    apiKey := os.Getenv("ALGOLIA_API_KEY")
    indexName := "test-index"

    host := spinUpContainer(t)

    startRecording(t, host, appID)

    algoliaClient := newTestClient(t, host, appID, apiKey)

    _, err := algoliaClient.SetSettings(
        algoliaClient.NewApiSetSettingsRequest(
            "test-index",
            search.NewEmptyIndexSettings().
                SetSearchableAttributes(
                    []string{"name"},
                ),
        ),
    )

    if err != nil {
        t.Fatalf("Failed to set settings: %v", err)
    }

    t.Cleanup(func() {
        _, err := algoliaClient.DeleteIndex(
            algoliaClient.NewApiDeleteIndexRequest(indexName),
        )
        if err != nil {
            t.Fatalf("Failed to delete index: %v", err)
        }
    })

    indexRecord(algoliaClient)

    searchResp, err := algoliaClient.SearchSingleIndex(
        algoliaClient.NewApiSearchSingleIndexRequest(indexName).
            WithSearchParams(
                search.SearchParamsObjectAsSearchParams(
                    search.NewEmptySearchParamsObject().
                        SetQuery("test"),
                ),
            ),
    )

    if err != nil {
        panic(err)
    }

    if len(searchResp.Hits) == 0 {
        t.Fatal("No hits found")
    }

    firstHit := searchResp.Hits[0]

    // Assert that the first hit has the expected name
    if firstHit.AdditionalProperties["name"] != "test record" {
        t.Fatalf(
            "Expected name to be 'test record', got '%s'",
            firstHit.AdditionalProperties["name"],
        )
    }
}

And now our test fits on a single screen 🙂
I also added an extra assertion just to be sure we get the expected record, and that's OK, since it does not mean extra calls to Algolia.
Now that we have paid the cost of writing that first step, writing more tests should be easier, and bring a lot of value to the project.

Bisecting vendors

Grégoire Paris — Fri, 05 Jan 2024 12:10:11 +0000

Hey there! If you're landing on this page, it's probably because somebody (most likely me), asked you to "bisect this regression down to a single commit". If that's not the case but you are still interested in helpfully reporting a regression, read on.

I promise we'll see what this technical mumbo jumbo could possibly mean, but first, let us understand what the issue is.

Regression! 💥

You have an application you are working on, and you update your dependencies regularly, because you know hygiene matters. 🚿 The only way you will feel clean is when seeing composer outdated outputs nothing.

And then, one day, after an upgrade, one of your automated tests breaks. That's a regression, and since the only thing you did was upgrading your packages, it must be caused by a vendor. Since you're upgrading regularly, the list of packages you upgraded is quite small, and after reverting the upgrade, and upgrading the packages one by one, you narrow it down to a single package, that we will call doctrine/orm to protect the innocent and the guilty.

You know the right thing to do is to report the issue, and you proceed to do so, making sure to let people know that the issue didn't occur in "version 2.16.x" and then everything broke after upgrading to "version 2.17.x".

And then… crickets… 🦗 Days elapse, and nobody answers. Why is that?

Open source development

If you compare 2.17.x with 2.16.x, you can see quite a few contributions, over a long period of time, and by many different people. Some of them are part of the Doctrine core team, some others are returning contributors, and a few made their very first contribution to that repository. They all do that on their spare time, sometimes after a long day of paid work, take vacations, have a family to take care of. The core team is subscribed to issues, but it's unlikely that contributors are.

At least you known what to do now: ping them all in a new message, of course! Hold on, hold on, I was just kidding, step away from that keyboard please. 🙏

There is no need to ping anyone… it's possible that a maintainer already took a glance at the releases and tried to find a commit title that looks like it could have to do with your issue. And if they did not respond, then it's probably not that obvious.

What would really help would be finding the right person to ping. This means you have to find the pull request, or even better, the commit that introduced the issue. The first thing to do is to update the issue and mention the exact version before and after the upgrade. It does count as narrowing things down.

After checking, you find that you were on 2.16.3, and then upgraded to 2.17.0.

Git bisect to the rescue

If you don't know what git bisect is, please hit pause on this blog post, and take a moment to go watch a part of this talk by Pauline Vos at Forum PHP 2021, and to practice git bisect a bit yourself. This blog post can wait.

youtube.com

You're back? Great! Now… how can you apply that to this problem? Does Composer maybe have a magical subcommand to do this? Not quite it seems. There's a plan for something, but it won't help finding a single commit:

Composer bisect command #11119

Seldaek posted on Oct 13, 2022

Discussed in https://github.com/composer/composer/discussions/11072

^{Originally posted by mad-briller September 21, 2022} This is just a random idea i've had while upgrading projects and having a hard time narrowing down issues, not sure if issues or discussions is the right place to put this.

Even with all the will in the world to respect semver, packages inevitability break backwards compatibility in ways they did not forsee, everyone is human afterall.

Chasing the version that introduced the issue can be quite hard currently, as you have to load up packagist and look at released versions and install them one by one to see if they are the issue. This reduces the likelihood that a developer will report the issue to the package maintainers, and also makes the developer less likely to actually update the package, as its safer to stay on the "last working version" and put an explicit version number in composer.json.

When a incorrect change is introduced in git, git bisect makes it super easy to chase the commit that introduced the issue. It would be great if composer had a composer bisect <package> that worked similarly. This would make narrowing down which version introduced a bc break much easier.

Thanks for your time.

View on GitHub

Let's do it manually then. The first issue you are facing is that doctrine/orm is probably not installed as a git repository, but was probably unpacked from an archive instead, so… there is no git history, this is just a snapshot. This means you cannot use git bisect yet, you first have to reinstall doctrine/orm as a git repository.

To be fair, it's not going to be completely manual, Composer can still help us a lot here. There are ways you can make it prefer an install from source rather than from a tarball, and the simplest way I know to do this is to run composer reinstall doctrine/orm --prefer-source. You should see some cloning happening:

$ composer reinstall doctrine/orm --prefer-source
  - Removing doctrine/orm (2.17.2)
  - Syncing doctrine/orm (2.17.2) into cache
  - Installing doctrine/orm (2.17.2): Cloning 393679a479 from cache

Now the fun begins. Here is how to proceed:

$ cd vendor/doctrine/orm
$ git switch --detach 2.16.3

At this point you should maybe clear some caches, and check that things work. If they do work, you can start the bisection.

$ git bisect start
status: waiting for both good and bad commits
$ git bisect good # because it works 👍
status: waiting for bad commit, 1 good commit known
$ git switch --detach 2.17.0
warning: you are switching branch while bisecting

At this point, you should clear the same caches, and check that the regression still happens.

Does it still happen? Great. Mark the current commit as bad.

$ git bisect bad # because it broke 👎
Bisecting: 33 revisions left to test after this (roughly 5 steps)
[some-hash] Merge pull request #42 from well-known-maintainer/tedious-maintenance-work

Boom! Bisection started. Clear the caches… does it work? If yes, run git bisect good, if not, run git bisect bad, and repeat until you see something like the following:

somehashffe340934df9 is the first bad commit
commit somehashffe340934df9
Author: Well Meaning Contributor <well-meaning@contribut.or>
Date:   Tue Feb 31 25:34:19 2026 +0200

    Cool change that hopefully breaks nothing (#12345)

 path/to/mission/critical/file.php | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Congrats, now you have a name, a commit hash, and a pull request number (if you are lucky). Mention all three in your issue and you will get far better help. It should go without saying, and sadly often does not, but be nice when doing so.

After that:

The author is more likely to be aware of the issue and fix it.
You and maintainers can examine the commit to see if they are able to spot the issue, which just became way more likely to get fixed.

If you do not see a pull request number, you should try finding the commit on Github first (at https://github.com/doctrine/orm/commit/somehashffe340934df9), and on that page, the pull request should appear right above the name of the author.

Bisecting a monorepository split

Ok, but what if the issue is not with doctrine/orm, but with symfony/dependency-injection? The hash will be for symfony/dependency-injection, and the corresponding hash for symfony/symfony will be different. I often forget to mention this when asked to explain why I am not a huge fan of monorepositories, but this is definitely one of the reasons. You are not stuck though, it's just a bit more involving. What you can do in this kind of case is bypass Composer completely and symlink to a local clone:

Clones the monorepository somewhere on your disk (for instance in /tmp/symfony)
Run rm -fr vendor/symfony/dependency-injection.
Create a symlink from vendor/symfony/dependency-injection to /tmp/symfony/src/Symfony/Component/DependencyInjection.
Finally proceed with the bisection.

If you know of more elegant ways to do this, please let us know in the comments, and I will edit this post.

Happy troubleshooting!

Feedback on sfCon 2022

Grégoire Paris — Thu, 15 Dec 2022 10:18:34 +0000

This year, the SymfonyCon was even more magical than it usually is, as it took place in Disneyland Paris, thus contributing sparkles on top of the nice features announced during the keynote.

Did you know that Symfony currently has no less than roughly 200 components? At the SymfonyCon, 2 new components were announced, that should make it into Symfony 6.3:

Webhook: can be used to host a webhook, or call a webhook, typically with payment providers. Handles validity, security and signature checks.
RemoteEvent: used to represent events produced outside Symfony

Here is the diff if you want to deep-dive head first!

This is a big event, so there were no less than 4 tracks, which means I had to choose.

First, I went to see a conference about Sylius and learnings the main maintainer has gathered over the past few years.
He mentioned ADRs, which we do use at ManoMano, and which would certainly be useful to also use in an open source setup (Doctrine maybe?).

Next, I went to see Nicolas Grekas' talk about proxies: he presented different ways to implement a proxy system, and examples of each one that can be found in Symfony or Doctrine.
Doctrine has an old implementation in doctrine/common that we are trying to get rid off, and Nicolas has proposed to replace those with Lazy Ghost proxies.
I know, I know, funny name. 👻
Lazy ghost proxies cannot be used with final classes, or internal classes, but do allow to use a fluent API, which makes them a good fit for doctrine/orm entities.

If you know me, you know I literally cannot shut up about Git, so for my next choice, I picked "advanced git magic" by Pauline Vos.
The highlight was definitely this explanation about git bisect:

After lunch, I heard there was a talk by one of my Doctrine fellows, Claudio Zizza a.k.a SenseException, which I first met in person at that conference, so of course, I had to pick that one.
Main takeways:

Always clear your entity manager at the end of a business class to avoid nasty side effects with $entityManager->clear();
(Postgre)SQL is very powerful, for instance you don't necessarily need to resort to the nested set model to build a menu, you can use WITH RECURSIVE

That was followed by a frightening talk form Sebastian Bergmann (himself!), who gave us a presentation of PHP's supply chain, and how each part of that chain has been exploited in the past, in PHP or for other ecosystems.
Some of these vulnerabilities are so bad they have got their own website:

All the links above are safe to visit, I swear! That last one might require a bit more processing power though.

Sebastian told us about the concept of Software bill of materials a.k.a. SBOM, as a way for you to know your dependencies and if they are vulnerable. You can try ./phpunit.phar --sbom to see it in action (only available when using the PHAR though).

I had already seen Kevin Dunglas' talk about FrankenPHP at the "Forum PHP", which also took place at Disneyland the previous month (yes, really), but I decided to watch it again because of how packed with information it was.
FrankenPHP provides a new PHP SAPI, that comes with a worker mode, that behaves much like Swoole or Roadrunner.
Unlike php-fpm, it does not require a separate nginx container to run: it's built on top of the Caddy webserver, which is written in Go, and is also written in Go.
Thanks to Kévin, Caddy is capable of forwarding 1xx HTTP responses it receives from its upstream, which unlocks using 103 Early Hints in PHP, a status code that aims at providing the browser with the urls of CSS files, JS files and other resources it might need before even sending the final response.

// Detect dark theme var iframe = document.getElementById('tweet-1557064869035347969-206'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1557064869035347969&theme=dark" }

Next, I went on a conference about the impostor syndrome, and one of the main takeaway was that it's so common and equally spread that we should rather call it impostor phenomenon. It's estimated to be have been experienced by 70% of people (and yes, that includes me). If you're unfamiliar with it, you can tell yourself that it is close to atychiphobia or kakorraphiophobia. Hope this helps.

That concluded the first day of conference. The 2 days were separated by a very nice evening with exclusive access to the Walt Disney Studios Park, which I must say is amazing, but I'll stop here because I don't want to make you jealous. But it was cool.

On the second day, I started with a conference about climate change and IT. As a staff engineer, I'm currently working on upgrading many of our microservices from PHP 7 to PHP 8, and I was glad to learn that PHP 8.1 is estimated to be 30% faster/less electricity-consuming than PHP 7.4.
There wasn't a similar figure to share about Symfony because it's harder to determine, but upgrading it is highly recommended as well.
I learnt that the carbon footprint can be evaluated in several scope, and that for an IT company like ManoMano, most of it is in Scope 3, which is all about the cloud, Scope 1 and 2 being about office heating and electricity. To lower
our impact, we should:

Upgrade our software
Optimize our apps (with a profiler)
Deploy to greener AWS regions: France, the Scandinavian peninsula (or Fennoscandia for geography nerds), the Netherlands.

This was very interesting, so I continued with a talk on the same theme: it was about computing carbon emissions in the cloud.
I learnt that "net zero" means the emissions of green house gases is equal to the removals, and that we are of course, very far from it, although it's a goal for 2050, that gets harder and harder to reach as time passes.
There is a formula to compute the carbon footprint of a VM. For each capacity, such as the CPU, storage, network, you have a matching emission factor expressed in watts, and a Power Usage Effectiveness that depends on the cloud provider you are using, which is a constant > 1 that is better the closest it is to 1. You then multiply that by the carbon intensity, that depends on the region where you are deploying, and is a factor that allows you to transform watts in CO2 emissions.

As the conference was getting closer to its end, I attended a talk about TDD.
The speaker dove into detail about TDD and gave us pointers about methods to do it properly, such as "fake it till you make it", which means you should write dummy code until you have written enough tests that force you to ditch your
initial, dummy implementation, or "triangulation", which consists in proving via tests that all parameters of a function are important, one by one.

Next we had a talk about automated upgrades by Tomáš Votruba, the author of Rector. He told us about tooling you can have in your projects to make it easier to upgrade. For instance, you can use so-called PHPStan collectors to measure type coverage, and ensure it only ever increases. Having type information is very important for static analysis, which Rector relies upon to understand your code and migrate it. Likewise, using PHP configuration instead of YAML configuration can help avoiding mistakes thanks to Static Analysis (which exists for PHP but not for YAML). He showed us a demo of using Rector in the CI to continuously upgrade the code.

The next talk I attended was by another fellow Doctrine maintainer: Alexander Turek. Alexander showed us strategies to modernize a legacy application with Symfony. It's possible for instance to introduce a global variable with the Symfony Kernel inside it to make Symfony services available inside the legacy application. That's called a micro rewrite because instead of migrating a full route to Symfony, you can migrate a service, deploy, rinse and repeat.
Something we might want to apply to our legacy ManoMano application?

The last talk I attended was by Mathieu Santostefano, a core team member. He presented the new AccessTokenAuthenticator shipped with Symfony 6.2, explaining how it had been waiting for other lower-level Symfony components to be ready over the years. Part of the talk was about the contribution process, and I remember a hilarious slide showing 2 contributors opening 2 pull requests about the very same thing (implementing that authenticator).

For the closing keynote, we had a light-hearted talk by Mickey Mouse himself presenting the evolution of Symfony over the past few months!

If this feedback piqued your interest, you can find many of the talks here:

SymfonyCon / 2022-talks

SymfonyCon - Paris 2022 talks

All talks are in english.
You can send feedback and love to speakers on their twitter account
See all tweets during the event

Keynote

Slides
~~Video~~

By Fabien Potencier
@fabpot
@fabpot

From monolith to decoupled…wait, why is that one getting bigger?!?

Description: Monolithic apps are getting broken down left and right into dedicated services and teams, all under the banners of separating concerns, higher efficiency, and more. The strategy that is implemented will be crucial to ensure decoupling is a beacon of efficiency and not a migration nightmare
In this talk, we’ll discuss how decoupling following the strangler fig approach will seem counter-intuitive, as your monolith continues to grow alongside your new decoupled architecture. But this approach, when done right, makes dismantling a monolith a process that is structured and safe, slow but agile, and without major service interruptions or massive interface changes that…

View on GitHub

Plotting the memory of a PHP process with Gnuplot 📈

Grégoire Paris — Fri, 26 Aug 2022 14:52:33 +0000

Lately, I have been troubleshooting memory issues on a process my team owns.
I started by watching this video about memory leaks from Benoît Jacquemont:

I learned a lot in the process, but also noticed the nice memory graphs in the video and figured it would be hard to troubleshoot anything if I didn't have them.
When using php extensions such as Benoît's or Arnaud Le Blanc's to take a snapshot of the memory, it's great to think about the most appropriate moment to take that snapshot in order to capture the memory leak you might be hunting.
Sure, you can use Monolog's MemoryUsageProcessor to that end, but I thought it would be more useful to get something a bit more ✨visual✨.

On our environments, we use Datadog, but on my development setup, I don't have that.

There are several metrics you can track for troubleshooting a memory issue, some provided by the OS, and typically reported by Datadog, some others by PHP through memory_get_usage() (which I don't currently have a way to monitor in production).

Measuring from PHP

PHP provides several methods to understand what is happening memory-wise. First, you have memory_get_usage(), which takes a boolean argument. Depending on that argument, the method returns the memory used by PHP, or the memory allocated to PHP. When freeing some memory, you will typically see the former decrease, while the latter stays stable.

Then, you have memory_get_peak_usage() which reports the highest value of used or allocated memory since the beginning of the script. That's useful because it can help the developer figure out that they are not calling memory_get_usage() where memory usage is at its highest.

Producing metrics

In the case of the script I was troubleshooting, I had a main loop that was frequently executed (but not at an even rate). That's still a good candidate for gathering metrics, as we will see.

Here is what I put inside that loop:

<?php
file_put_contents(
    'memory.tsv',
    time() . "\t" .
    memory_get_usage(true) / 1024 / 1024 . "\t" .
    memory_get_usage(false) / 1024 / 1024 . "\t".
    memory_get_peak_usage(true) / 1024 / 1024 . "\t" .
    memory_get_peak_usage(false) / 1024 / 1024 . "\n",
    FILE_APPEND
);

This produces a TSV file that looks like this:


1660831187  20  8.1252593994141 20.359375   19.608978271484
1660831187  20  8.1281814575195 20.359375   19.608978271484
1660831187  20  8.131103515625  20.359375   19.608978271484
1660831187  20  8.134033203125  20.359375   19.608978271484
1660831187  20  8.1369552612305 20.359375   19.608978271484
1660831187  20  8.1398773193359 20.359375   19.608978271484
1660831190  22  8.2328033447266 24.42578125 22.869613647461
1660831190  22  8.2357330322266 24.42578125 22.869613647461
1660831190  22  8.2386627197266 24.42578125 22.869613647461
1660831190  22  8.2415924072266 24.42578125 22.869613647461

Looking at the first column, what stands out is that there are groups of lines that can be several seconds apart, so the production of metrics is really, really not paced regularly.

Plotting graphs

Then, to create the graph, I turned to gnuplot, which seems like a whole universe of its own as well as a very robust piece of software. I started by creating the following configuration file:

# config.plt
set term png small size 800,600
set output "/tmp/memory_get_usage-graph.png"

set ylabel "memory in MB"

set yrange [0:*]

set xdata time # x is not just a random number
set timefmt "%s" # we use UNIX timestamps

plot "memory.tsv" using 1:2 with lines axes x1y1 title "memory_get_usage(true) in MB", \
     "memory.tsv" using 1:3 with lines axes x1y1 title "memory_get_usage(false) in MB", \
     "memory.tsv" using 1:4 with lines axes x1y1 title "memory_get_peak_usage(true) in MB", \
     "memory.tsv" using 1:5 with lines axes x1y1 title "memory_get_peak_usage(false) in MB"

As you can see, it's possible to let gnuplot know that the x axis represents time, which ensures you have a nicely formatted X axis.

The graph is created by running gnuplot config.plt.

Rendering the graph

What would be handy would be a graph that refreshes over time. For that, you will need 2 tiny programs: watch and feh.

Run watch gnuplot config.plt, to ensure a png is created every 2 seconds (which is watch’s default).
In parallel of that, you run feh /tmp/memory_get_usage-graph.png to display the png file. What's great with feh is that it refreshes automatically, so you don't need to do anything special to get your live graph. 🤯 feh does very little, but does it well.

2 interesting things to note here:

Only the graph for memory_get_usage(false) goes down, but it does go down, so there is no memory leak
The defaults of gnuplot are a bit ugly, and I am no frontend developer, so it will stay ugly.

Measuring from Linux

Producing metrics

Here, to produce the metrics, you can use ps.

while true; do
    ps --pid $(pgrep -f some_string_that_identifies_your_process) \
    -o pid=,%mem=,vsz= >> /tmp/mem.log
    gnuplot config.plt
    sleep 1
done

Note that you can of course use this for any process, not just PHP processes.

Plotting graphs

This time it's a bit more tricky, I am telling gnuplot to plot 2 metrics that
have different units on the same graph.

The left Y axis will have a scale for the first metric, and the right Y axis
will have a scale for the second metric.

I do not configure the X axis this time, since I'm producing metrics at a
regular pace.

This is all shamelessly stolen from Stack Overflow

set term png small size 800,600
set output "/tmp/mem-graph.png"

set ylabel "VSZ"
set y2label "%MEM"

set ytics nomirror
set y2tics nomirror in

set yrange [0:*]
set y2range [0:*]

plot "/tmp/mem.log" using 3 with lines axes x1y1 title "VSZ", \
     "/tmp/mem.log" using 2 with lines axes x1y2 title "%MEM"

Here you can see that the figures are different than from inside PHP. I will not get into this because that is off topic, but when troubleshooting memory issues, it can also be important to compare both aspects.

Takeaway

Those graphs helped me understand the differences between memory_get_usage(true) and memory_get_usage(false), and gave me a better understanding of my application. In particular, I understood that the batch processing I was doing relied on batches of objects that were not all the same size, and that making sure they were all roughly the same size would help avoid situations where a series of big objects caused an out-of-memory error.

How to deprecate a type in php

Grégoire Paris — Sat, 29 Dec 2018 18:09:23 +0000

So you have this class or interface you want to rename to something else, because you need to move that type to another package, or you have new coding standard rules that need to be applied to its name. One solution is to use inheritance and move all the code to the new type:

<?php

// LegacyFoo.php

/**
 * @deprecated please use ShinyNewFoo instead!
 */
interface LegacyFoo extends ShinyNewFoo
{
}

This approach is great until your users write code that expects the old type, and gets the new type from your code instead:

<?php

class Bar // registered and invoked by your library
{
    public function __invoke(LegacyFoo $foo) // crash
    {
    }
}

But fear not, there is another approach, that consists in creating an alias for your type.

<?php

// LegacyFoo.php

class_alias(ShinyNewFoo::class, LegacyFoo::class);

This creates an alias from interface LegacyFoo, to interface ShinyNewFoo. You read that right, although it is class_alias and I used the class constant, both work for interfaces. But this is not enough, because nothing guarantees LegacyFoo will be autoloaded at some point. Using that type in a parameter type declaration does not trigger autoload, because surely the type should be autoloaded when the object passed as parameter is instantiated. Well, this optimization does not work for type aliases, which means we have to manually trigger the autoload at the bottom of ShinyNewFoo.php.

<?php

// ShinyNewFoo.php

class_exists(LegacyFoo::class);

Think this is over? Not so fast, there is more. Now that it all works, let us put this in production, and see it burst into flames! class_alias calls are so rarely used that Composer does not look for them when generating its autoloader classmap. Autoload classmaps are a way to know which files to load without checking the filesystem first, which is faster. To trick Composer into detecting the legacy type, we can declare it as a piece of dead code:

<?php

// LegacyFoo.php

class_alias(ShinyNewFoo::class, LegacyFoo::class);

if (false) {
    class LegacyFoo extends ShinyNewFoo
    {
    }
}

This will also fool most IDEs into providing auto-complete.

And finally, what if we want to trigger a deprecation error when the legacy type is used? We cannot just do it since it will be autoloaded every time we use the new type. All we can do is implement a best-effort solution:

<?php

if (!class_exists(ShinyNewFoo::class, false)) {
    @trigger_error(
        'LegacyFoo is deprecated!',
        E_USER_DEPRECATED
    );
}

This checks first if ShinyNewFoo exists, without triggering autoload. If it does not, then LegacyFoo is referenced somewhere and we can safely trigger a deprecation.

Done? The following seems to have been fixed with recent versions of php, you can ignore it if your library requires php >= 7.4.0.

Otherwise… nope, not done, you sweet summer child! It goes deeper.

This is an even rarer occurrence, but let us consider an interface that you expose, and that used the deprecated type in one of its signature and was switched to the new type:

<?php

interface Bar
{
    public function baz(ShinyNewFoo $foo);
}

What should happen to the implementation of your consumers?

Let us also consider that class that does something similar, but that you did not mark as final… (or that could be abstract, same issue).

<?php

abstract class Foobar
{
    abstract public function foobar(ShinyNewFoo $foo);
}

What should happen to extending classes of your consumers?

Well they shall crash and burn, of course! Since type declarations do not trigger autoload, the alias does not exist, so PHP cannot know both type declarations mean the same thing.

<?php

final class ExtendingFoobar extends Foobar implements Bar
{
    public function baz(LegacyFoo $foo) // 💥
    {
    }

    public function foobar(LegacyFoo $foo) // 💥
    {
    }
}

Unless… you guessed it, we need to add yet another call to class_exists (or interface_exists) call to trigger the autoload. In order not to get a deprecation, we will use that on the new type, and it will in turn silently load the old type and do the class alias.

<?php

interface Bar
{
    public function baz(ShinyNewFoo $foo);
}
class_exists(\ShinyNewFoo::class);

To sum things up, every extensible interface, every interface that uses the old type in one of its signatures should make sure to autoload the new type.

Done. Until next time. Wow that was hard, and I cannot say it feels very satisfying. I wish there were a native way in php to do all this.

If you want to tinker with this problem yourself and try things out, here is a repo that might serve as a good starting point for you: https://github.com/greg0ire/type_deprecation_experiment

The case for multiline signatures

Grégoire Paris — Sat, 21 Oct 2017 18:18:29 +0000

Hopefully, my last blog post convinced you to avoid long lines. The php community has a nice coding style guide called PSR-2 that says the following:

There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

Basically this means: do whatever you want, but your editor will warn if you go above 120 characters. The 80 characters limit is probably here to encourage people to add linebreaks even if their line is just 121 chars instead of saying "come on, it's only 1 character".

Some projects take advantage of the limit being soft and disregard the soft limit for method signatures and will write this:

<?php
public function connect(?string $sourceId, $sourceValue, ?string $destId, $destValue = null, string $reference = null, bool $lazy = false, bool $weak = false);

rather than this:

<?php
    public function connect(
        ?string $sourceId,
        $sourceValue,
        ?string $destId,
        $destValue = null,
        string $reference = null,
        bool $lazy = false,
        bool $weak = false
    );

Behind that decision are many arguments that I'd like to discuss here. Just to be clear though: I'm not suggesting you should always use multiline signatures. In my opinion, they should only be used when the line length exceeds 120 characters.

Method signatures are not real code

The main argument seems to be that method signatures are not "real code", because they declare things instead of doing things, and should thus not pollute the screen real estate. Except that they describe the interface of your method, and changes to them are very important, and should be reviewed carefully, because that is where most BC-breaks happen. Also, since php 7.0, function signatures are getting far more type hinting than before, which makes them longer, but also more useful, because they describe what type of variables you are dealing with. This is not always obvious unless you use hungarian notation, which you absolutely shouldn't.
Having multiline signatures is not only useful for reviewers, but for people that edit that part of the code. If one argument maps to one line, navigating from argument to argument is suddenly way easier than whatever IDE shortcuts you would use otherwise.
Still not convinced? Consider using code folding instead of making the code uglier for everyone else, including and especially reviewers. If this suggestion sounds stupid, maybe it is and the signatures do matter after all?

Parameter types are already described in the phpdoc

Then remove the phpdoc, unless you wrote something very interesting in it. Forcing people to describe each and every parameter in the phpdoc always results in the same paraphrasing comments in my experience, which has a very bad consequence: people stop reading the comments. Surely you can give the real estate you gave to the phpdoc to a piece of code? Most IDEs display comments in light gray nowadays, probably because of this, but I feel comments should not be mainly aimed at doc-extracting tools or annotation libraries. They should be helpful messages for your team, when your code fails to achieve enough clarity.

Long method signatures are an alarm signal about having too many arguments

That one is really moot, because if you have a 100000-character long line, it will still be one line, whereas if your screen is filled with a signature, the alarm signal will only be louder, and tools like phpmd will warn about your method having too many arguments.
The first step towards realizing how wrong things are for this method is definitely using a multiline signature:

<?php
    /**
     * Product constructor.
     * @param \Magento\Framework\Model\Context $context
     * @param \Magento\Framework\Registry $registry
     * @param \Magento\Framework\Api\ExtensionAttributesFactory $extensionFactory
     * @param AttributeValueFactory $customAttributeFactory
     * @param \Magento\Store\Model\StoreManagerInterface $storeManager
     * @param \Magento\Catalog\Api\ProductAttributeRepositoryInterface $metadataService
     * @param Product\Url $url
     * @param Product\Link $productLink
     * @param Product\Configuration\Item\OptionFactory $itemOptionFactory
     * @param \Magento\CatalogInventory\Api\Data\StockItemInterfaceFactory $stockItemFactory
     * @param Product\OptionFactory $catalogProductOptionFactory
     * @param Product\Visibility $catalogProductVisibility
     * @param Product\Attribute\Source\Status $catalogProductStatus
     * @param Product\Media\Config $catalogProductMediaConfig
     * @param Product\Type $catalogProductType
     * @param \Magento\Framework\Module\Manager $moduleManager
     * @param \Magento\Catalog\Helper\Product $catalogProduct
     * @param ResourceModel\Product $resource
     * @param ResourceModel\Product\Collection $resourceCollection
     * @param \Magento\Framework\Data\CollectionFactory $collectionFactory
     * @param \Magento\Framework\Filesystem $filesystem
     * @param \Magento\Framework\Indexer\IndexerRegistry $indexerRegistry
     * @param Indexer\Product\Flat\Processor $productFlatIndexerProcessor
     * @param Indexer\Product\Price\Processor $productPriceIndexerProcessor
     * @param Indexer\Product\Eav\Processor $productEavIndexerProcessor
     * @param CategoryRepositoryInterface $categoryRepository
     * @param Product\Image\CacheFactory $imageCacheFactory
     * @param ProductLink\CollectionProvider $entityCollectionProvider
     * @param Product\LinkTypeProvider $linkTypeProvider
     * @param \Magento\Catalog\Api\Data\ProductLinkInterfaceFactory $productLinkFactory
     * @param \Magento\Catalog\Api\Data\ProductLinkExtensionFactory $productLinkExtensionFactory
     * @param EntryConverterPool $mediaGalleryEntryConverterPool
     * @param \Magento\Framework\Api\DataObjectHelper $dataObjectHelper
     * @param \Magento\Framework\Api\ExtensionAttribute\JoinProcessorInterface $joinProcessor
     * @param array $data
     *
     * @SuppressWarnings(PHPMD.ExcessiveParameterList)
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,
        \Magento\Framework\Api\ExtensionAttributesFactory $extensionFactory,
        AttributeValueFactory $customAttributeFactory,
        \Magento\Store\Model\StoreManagerInterface $storeManager,
        \Magento\Catalog\Api\ProductAttributeRepositoryInterface $metadataService,
        Product\Url $url,
        Product\Link $productLink,
        \Magento\Catalog\Model\Product\Configuration\Item\OptionFactory $itemOptionFactory,
        \Magento\CatalogInventory\Api\Data\StockItemInterfaceFactory $stockItemFactory,
        \Magento\Catalog\Model\Product\OptionFactory $catalogProductOptionFactory,
        \Magento\Catalog\Model\Product\Visibility $catalogProductVisibility,
        \Magento\Catalog\Model\Product\Attribute\Source\Status $catalogProductStatus,
        \Magento\Catalog\Model\Product\Media\Config $catalogProductMediaConfig,
        Product\Type $catalogProductType,
        \Magento\Framework\Module\Manager $moduleManager,
        \Magento\Catalog\Helper\Product $catalogProduct,
        \Magento\Catalog\Model\ResourceModel\Product $resource,
        \Magento\Catalog\Model\ResourceModel\Product\Collection $resourceCollection,
        \Magento\Framework\Data\CollectionFactory $collectionFactory,
        \Magento\Framework\Filesystem $filesystem,
        \Magento\Framework\Indexer\IndexerRegistry $indexerRegistry,
        \Magento\Catalog\Model\Indexer\Product\Flat\Processor $productFlatIndexerProcessor,
        \Magento\Catalog\Model\Indexer\Product\Price\Processor $productPriceIndexerProcessor,
        \Magento\Catalog\Model\Indexer\Product\Eav\Processor $productEavIndexerProcessor,
        CategoryRepositoryInterface $categoryRepository,
        Product\Image\CacheFactory $imageCacheFactory,
        \Magento\Catalog\Model\ProductLink\CollectionProvider $entityCollectionProvider,
        \Magento\Catalog\Model\Product\LinkTypeProvider $linkTypeProvider,
        \Magento\Catalog\Api\Data\ProductLinkInterfaceFactory $productLinkFactory,
        \Magento\Catalog\Api\Data\ProductLinkExtensionFactory $productLinkExtensionFactory,
        EntryConverterPool $mediaGalleryEntryConverterPool,
        \Magento\Framework\Api\DataObjectHelper $dataObjectHelper,
        \Magento\Framework\Api\ExtensionAttribute\JoinProcessorInterface $joinProcessor,
        array $data = []
    ) {

Besides, with the php 7.0 type hinting, long signatures are going to happen way more often, and you may want to know if the cause is the number of arguments, the length of the type hints, the length of the variable names or a combination of all of these. If you address the real problem behind that, you might end up with more little methods with fewer arguments, which is usually easier to reason about. Don't sweep things under the rug, heed the warnings and design better code. Symfony's Options Resolver Component might help with that if your arguments are actually interchangeable configuration options for something.

Framework X, which my library uses, forbids multiline signatures

You should strive to make your library framework-agnostic, and segregate it from framework-integrations layers. Style is part of that, use your own, don't let bad decisions spread like as many diseases, especially if you can't help but having many arguments with long names and long type hints because you love Java.

Switching to multiline signatures will be the source of many conflicts

I'm a maintainer of some libraries that do not use multiline signatures. Guess where a big part of the conflicts happen? That's right, they happen on long lines, which nowadays practically only occur with long signatures. So maybe the conflicts are worth it in the long run.

Also, consider that switching to multiline signatures does not have to be done in one-shot: just allow switching to them, and enforce them on newly created methods when they are too long.

Multiline signatures look weird

Remember switching to PSR-2? I remember, it felt horrible at first to have to write

<?php
if (defractulatorIsReady()) {
    defraculate();
}

instead of

<?php
if (defractulatorIsReady())
{
    defraculate();
}

like some of us did for years. But it was also nice to finally have a standard everyone could agree with, so I went with it anyway, and it felt horrible… for about half a day, and that was it. So if multiline signatures feel horrible, please try them a bit longer, instead of clinging to old habits, the language evolves, and so should you!

Why I keep pestering everyone about long lines

Grégoire Paris — Sat, 09 Sep 2017 21:17:18 +0000

When I decided to switch from Eclipse to vim, I remember being apprehensive of the clumsiness I would have to experience while facing vim's supposedly steep learning curve. I would have to lose lots of handy features, try to regain some of them plugin by plugin and survive with vim's at the time somewhat alien interface until I got comfortable with it.

One thing that helped me regain a lot of the speed I formerly had was a very low-level feature: the ability to split windows. While on Eclipse, I had not
even considered doing it because my window was filled with very "handy" panes that would show me a file tree, methods in the current file and so on. Once on vim, I found plugins to have those kind of panes back, but I did not seek to enable them by default because by the time I found those plugins I had realized a very important thing for my new workflow, something even more important than the fact that I did not really need a menu:

Being able to see several files at a time is way, way, way more important than having any of those panes.

It is the same kind of feeling you get when you start working with an additional monitor.

When I work on a piece of code, I typically have my vim window split in 4 or more vim "windows": the separation of concerns makes it so that you will often work with a service, a controller, corresponding tests, a template, some models and will need to quickly switch back and forth between them. When using Eclipse, I would often Ctrl+click keywords and navigate through the code, each click leaving me with one new tab I did not really care about, and then I would cleanup tabs I did not need. With vim, those tabs do not show up. They are still in the so-called buffer list, but that one is not visible by default.
I found that a bit stupid at first, but then it clicked: just split your window several times, and display files you really care about. Instead of remembering their name and looking for them in a long list of tabs only a few of which you actually care about, just look at your screen and recognize the file by its contents. The switch is instant. And that is if you need to switch, because sometimes, all you need is to read something in the file, not edit it. And if the file you want is not displayed, either split even more or consider replacing one of the windows you already have with the buffer that has the file you need. That file switch is a very low level action, and it is important to get right because you have to do it all the time.

And that's when I started paying a lot more attention to the length of the lines in my code. Nowadays, widescreens are the norm, and it seems to be an argument for people who disregard any limit in line length. But it is not about being able to edit files on an 80-chars wide terminal, like they often claim it is: it is about being able to see several files side by side.

And even if you do not see the benefit of split windows, ask yourself why this blog post does not span all your screen, or why newspapers use columns.
Spoiler alert, it is, among other reasons, because it is far more efficient to scan that than a long line of text. Convinced? Then start writing your code for human beings, start using split windows and tell your fellow developer about that.

Why using Yoda conditions you should probably not be

Grégoire Paris — Wed, 02 Aug 2017 21:47:31 +0000

I had been using Yoda conditions for some time before I stumbled upon this now deleted Stack Overflow Question, later backed up in this blog post. I remember thinking "This could have saved me a lot of time!". Indeed, who can claim they have never written code like this:

<?php
if ($name = 'Luke Skywalker') {
   // this piece of code will always be executed
}

So how do Yoda conditions work? Well it is basically a knee-jerk reaction you have to develop: whenever you write a condition, put the operand that cannot be assigned on the left. This should give you an error message if you make an assignment when you actually meant to make a comparison.

In our case, this gives the following:

<?php
if ('Luke Skywalker' = $name) { // Parse error: syntax error, unexpected '='
}

and finally, if you go all in and use strict comparison, this:

<?php
if ('Luke Skywalker' === $name) {
}

In english, this translates to "If Luke Skywalker is the name", which should feel very familiar if you are from Dagobah or whichever planet Yoda actually came from, but is just cognitive load if you are used to english syntax, which you should if you are writing programs.

I believe it has to become a knee-jerk reaction because if it does not, there is no point to it: if you can think of using Yoda conditions, then for sure you can think of checking if you really mean to write an assignment here or not. You have to use them without thinking.

So let us say that you develop the knee-jerk reaction. You might end up with code like this:

<?php
if ('Luke Skywalker' === $this->getName()) {
}

Do you see the issue here? Neither operands can be assigned, so there is no benefit, but the downside is still there.

Soon enough, the disease spreads to inequalities, even in the documentation of my favorite framework, and you end up with needlessly convoluted code like this:

<?php
if (42 < $force) {
}

There are a few things to ponder before picking Yoda.

First, the only person who benefits from Yoda conditions, is you, the writer. It just makes life slightly harder for the people that read your code, which includes code reviewers, coworkers, or potential contributors.

Also, if you test every code path, you should be able to spot the problem before it reaches the next step of your development pipeline. Tests can help with that, especially if you write them before writing the actual code, in a healthy red-green-refactor cycle

Next, code review (including and especially self code-review) should catch the mistake if tests fail to do that.

And finally, if you are not feeling a strong need for assignments in conditions anyway, you may as well use a static analyzer to enforce a rule that forbids them. If you still would like to be able to use them you can also prevent Yoda conditions and only them.

So go ahead, get rid of Yoda conditions today, and death to the Jedi.

Image by Daryl Mandryk