[Golang docs feedback] Extend the existing tutorial using more testing libraries

[mdelapenya]

Problem description

I think this is not a problem but instead a suggestion.

For the sake of covering more available options, we would like to contribute a section that demonstrates how to test with Testcontainers for Go (the additional benefit is that it is available in multiple languages too, so we can bring even more content). We believe this will be beneficial for the community, and the way we learned about the article is from someone who started with ory's version after reading the page but then migrated to Testcontainers as they found it more convenient for their use case, so we want to make sure that the page reflects all available options for devs to choose from.

Problem location

• I suggest a change at the following URL: https://docs.docker.com/language/golang/run-tests/

• Other: As a Go developer, I'd like to see different options on testing Docker containers.

Suggestions for a fix

I would be able to contribute a tutorial using other testing libraries, but I do not know how that would fit into the current page structure, so I'd appreciate your guidance in defining it.

[olliefr]

Hello, @mdelapenya!

I'm the original author of the Language-specific guide for Golang for Docker.

I don't develop in Go as a part of my day job anymore, but I would like to point out a few things to consider before the decision is made to replace existing content.

Firstly, it would have been prudent to mention that you are the chief contributor for the testcontainers-go module. It is understandable that a creator would like to promote their work, but it's always best practice to disclose this.

From comparing the popularity of testcontainers-go and dockertest, I see that at 3.1k GitHub stars dockertest is almost twice more popular than testcontainers-go standing at 1.7k GitHub stars.

According to the official Go Package Directory, dockertest is imported by 192 other packages versus testcontainers-go at 126, so there's about 1/3 difference not in favour of testcontainers-go.

dockertest clocks in 35 mentions on libhunt while testcontainers-go lists only 5.

Another point, and this one is more worrying, is the surface area of dependencies. The latest version of dockertest has 33 dependencies, of which only 15 are indirect. The latest version of testcontainers-go weighs in at... 150 dependencies, of which 131 are indirect. This worries me. There are multiple errors in testcontainers-go dependency declarations.

It does appear, by considering GitHub contributors statistics, that testcontainers-go is more actively maintained than dockertest in the last 12 months.

On the subject of ease of use, please be aware that as an author, you will always find your creation easier to use than the alternatives. And the community around testcontainers-go would display a self-selection bias in favour of testcontainers-go, naturally.

The point of the "run tests" section in the language-specific guide was and still is to show that Docker containers are useful for testing. So, I went with a simple example for clarity purposes. I doubt that making "the page [reflect] all available options for devs to choose from" is a realistic target, given the diversity of Go module ecosystem and how fast things change. Replacing one testing framework with another in a tutorial article does not, IMO, add significant value.

So here's that.

So what could you do? I would suggest that you could:

• write an article for golang.testcontainers.org to compare your framework to the main competitors, such as dockertest, and articulating the value proposition with examples and comparisons;

• add a section at the end of "run tests" section of the Docker Golang guide to list other popular frameworks, including yours. You could even link your article to it.

This way more developers will be exposed to it and it will grow organically.

Btw, I'm not in any way affiliated with @ory and do not have emotional attachment to dockertest. This is just my frank opinion on this matter. I'm not an authority on Docker, or Go, or testing, so please don't take what I say too seriously. This is just some food for thought 🙃

[mdelapenya]

Hi @olliefr, thanks for your feedback.I much appreciate it and I’m taking notes on it to improve testcontainers-go as a project, especially regarding technical details, such as dependencies (you can see it here testcontainers/testcontainers-go#646).

I'd like to apologize if I did not present myself as the core maintainer of the project, this is something I usually do when talking to other OSS communities, and I probably missed it. In fact I created an issue in the original repository of the Go project used in the tutorial (see olliefr/docker-gs-ping#6) adding copies of the existing tests with dockertest, created with testcontainers-go.

It was never my intention to replace the existing docs regarding dockertest, since I acknowledge it as an important testing library in the Go ecosystem. As I said in the issue description, I merely wanted to extend the documentation with an additional example regarding testcontainers-go, which was based on the feedback from users in our community.

I created this issue to have exactly this discussion on whether the addition makes sense or not. Thanks for the suggestion of adding an article to our docs and potentially linking to it from the Docker Golang guide, that is a great idea as well.

What do the maintainers of the Docker documentation think? What is the most convenient way to proceed, regarding readers of the documentation and Docker users? I would still happily extend the guide with a testcontainers-go example, but adding a link also sounds like a good compromise.

[olliefr]

Hello, @mdelapenya! I suppose the quickest win would be if you update the "Run tests" section in the following manner:

• Add a statement to the intro paragraph to say that in the current tutorial we will consider two competing approaches to managing containerised tests and the reader is welcome to do one or the other (or both, if they feel like it);
• Leave dockertest sections as they are;
• Add testcontainers-go sections after the dockertest sections;
• Insert two links into the intro paragraph, each linking to the corresponding header (dockertest & testcontainers-go).

Submit a PR to Docker docs.
Submit a PR with code changes to olliefr/docker-gs-ping

This is just a suggestion, obviously, but if you follow it you don't have to worry about changing the structure too much and can focus on the new content instead.

[mdelapenya]

@olliefr hi again! Sorry for the radio silence but I was on parental leave for a few weeks.

Did you have the chance to look at olliefr/docker-gs-ping#7? It adds the testcontainers-go tests to the play 🙏

At the same time, #16598 is the extension of the current Docker tutorial. We'd appreciate your feedback

Thanks in advance

[olliefr]

Hello!

Apologies for radio silence, it's been quite a busy start of the year at work :(

I've responded in olliefr/docker-gs-ping#7

[docker-robot]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[docker-robot]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked