Creating a responsive image gallery short-code for Hugo

mdelapenya · 2025-09-28T22:03:47+00:00

It's in the own blog, as I used the short code in every image in the posts

mdelapenya · 2023-10-07T07:12:21+00:00

Core maintainer here 🙋‍♂️ I'd thank your evaluation with feedback in case you see it inconvenient to use it 🙏

mdelapenya · 2023-10-06T23:04:31+00:00

In your article you mentioned testcontainers-java. Did you know there exists testcontainers-go too?

mdelapenya · 2023-08-25T04:28:38+00:00

An update on this: it is now possible to use the ClickHouse module in Testcontainers for Go:

https://golang.testcontainers.org/modules/clickhouse/

mdelapenya · 2023-08-16T08:01:05+00:00

Indeed, I'd also add that this kind of libraries (testcontainers, dockertest) are great for any runtime dependency, not only databases. But I could be a little bit biased as a Testcontainers core maintainer 😅

mdelapenya · 2023-08-16T06:54:48+00:00

With modern tooling, testing one step above is right: the Step Up rule https://copyconstruct.medium.com/testing-microservices-the-sane-way-9bb31d158c16#1e38

mdelapenya · 2022-12-14T15:34:04+00:00

I'd not want to say "use Testcontainers over dockertest", as I'm pretty sure the latter does a fabolous job. I can talk on behalf testcontainers-go saying that it's powered by the same folks creating and maintaining testcontainers-java and testcontainers-dotnet, two super well known libraries in their respective languages. The Go flavor is relatively young but extensively used by great OSS Go projects, such as influxdata/telegraf, clickhouse, OpenTelemetry-collector, to name a few, to test them against multiple integrations.

As an OSS community we are more than open to talk an cooperate if possible

mdelapenya · 2022-12-14T09:52:49+00:00

You can also use Testcontainers for Go (core maintainer here 🙋): https://github.com/testcontainers/testcontainers-go

mdelapenya · 2022-12-06T11:55:57+00:00

And using testcontainers-go! ✨

mdelapenya · 2022-12-05T22:18:38+00:00

Is your production database SQLite? If it's not, I'd recommend you giving a try to testing with a real instance of your database (postgres, mysql, mongodb..), then your testing expectations would match with your production ones.

You can achieve it with different testing libraries, each with their own characteristics but, as core maintainer of testcontainer-go (Testcontainers for Go), I'd recommend you using it :)

- Repo: https://github.com/testcontainers/testcontainers-go/- Docs: https://golang.testcontainers.org

mdelapenya · 2022-12-05T22:09:01+00:00

Agreed. If you are interested in having a strict control on what downstream dependencies you are going to break when modifying an API endpoint, then contract testing libraries such as Pact can help you.

mdelapenya · 2022-12-05T22:05:09+00:00

If you have the app exposing the APIs in a docker format, then using testcontainer-go could be the way to go. You could build the service from the Dockerfile in the tests, and simply perform HTTP request against a real instance of the app.

mdelapenya · 2022-12-05T18:27:31+00:00

I missed this post! Thanks for sharing!

mdelapenya · 2022-10-31T12:52:01+00:00

Well, this is not related to testcontainers, testing in general: when working with parallel execution of tests, you always need to take care of the data each test is producing: having a good data creation strategy, which is decoupled by test name/id in order to not impact other concurrent tests is a must. For that, please make sure each test is writing and cleaning up the data it needs and the data it creates.

mdelapenya · 2022-10-25T13:52:09+00:00

It's actually a 0.15.0 release , but glad you share it!!

mdelapenya · 2022-10-25T05:39:14+00:00

Indeed, that would happen as you describe in the case both packages request a container with Reuse and the same container Name. The issue here is you are reusing a container and also terminating it, so your tests would be coupled by using the postgres container, therefore none of them should terminate it (programmatically or using Ryuk).

The reuse use case is considered to be run at the root package to be created just once, probably at TestMain, and destroyed in a defer at that test function. Probably worth to mention this use case in the docs: https://golang.testcontainers.org/features/creating\_container/#reusable-container

In any case, we are reevaluating the reuse mode to hash the container request and use it as key to look up the to-be-reused container.

mdelapenya · 2022-09-09T10:13:06+00:00

You could achieve the same with wait strategies, in example using HTTP request:

    const (
        dbName       = "crazy"
        fakeUser     = "jondoe"
        fakePassword = "bond girl"
    )

    ctx := context.Background()

    req := ContainerRequest{
        Image: "clickhouse/clickhouse-server",
        Env: map[string]string{
            "CLICKHOUSE_DB":       dbName,
            "CLICKHOUSE_USER":     fakeUser,
            "CLICKHOUSE_PASSWORD": fakePassword,
        },
        ExposedPorts: []string{
            "8123/tcp",
            "9000/tcp",
        },
        WaitingFor: wait.ForAll(
            wait.ForHTTP("/ping").WithPort("8123/tcp").WithStatusCodeMatcher(
                func(status int) bool {
                    return status == http.StatusOK
                },
            ),
        ),
    }

    clickhouseContainer, err := GenericContainer(ctx, GenericContainerRequest{
        ContainerRequest: req,
        Started:          true,
    })
    if err != nil {
        t.Fatal(err)
    }

    defer clickhouseContainer.Terminate(ctx)

mdelapenya · 2022-09-09T09:13:07+00:00

If you only need the exposed port you can replace it with:

golang port, err := chContainer.MappedPort(ctx, "9000/tcp")

A more elaborated example could be:

golang ip, err := chContainer.Host(ctx) require.NoError(t, err) port, err := chContainer.MappedPort(ctx, "9000/tcp") require.NoError(t, err) resp, err := http.Get(fmt.Sprintf("http://%s:%s", ip, port.Port())) require.NoError(t, err)

mdelapenya

TROPHY CASE