dockertest VS go-sqlmock

I am using https://github.com/ory/dockertest for tests, specifically for databases. Is there any advantage to use Testcontainers?

Now, let's run the tests. For this purpose, we are going to use dockertest, but test containers is also a good solution.

During my path learning go so far I have come across some amazing libraries and utilites, one of my favourite for integration testing is dockertest.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

I've used dockertest a bunch and it is really amazing.

Reminds me of https://github.com/ory/dockertest

If your project is relatively simple and you can get away with recreating your scenarios against a real mock database and run other related services locally. It would be good to setup docker containers for your test scripts and write e2e tests. I believe e2e tests are harder but more useful in understanding/reasoning how users are impacted.

Just a heads up, the repository in your comment is invalid, the correct link is https://github.com/ory/dockertest

Don't mock. Use https://github.com/ory/dockertest to actually run tests against a dockerized DB.

Use a library like ory/dockertest to spin up a test database for integration tests. It's easy to use, and tests are still fast. It'll take a minute to download the mysql docker image the first time. But, once it's been downloaded, starting the db, running migrations, and running the tests is still pretty quick.

For that, I used the lib go-sqlmock. So, for example, the following snippet is part of the person/service_test.go file:

It's not the right call IMO to skip mocking the database connection to achieve 100% test coverage. How your app will behave in failure scenarios that are impossible to imitate during integration tests is part of the software contract. If your choice is to panic, or return an error, document that by testing that behavior. If another dev, or future you inadvertently breaks the contract, the test suite will fail. That's what you want. For unit tests against your database you should be using either go-sqlmock if testing against database/sql or pgxmock if testing against pgx. That being said, the points raised elsewhere in this thread regarding unit tests potentially hiding edge cases in terms of how an actual database will interact with your application that are not reflective of your understanding when writing mocks are 100% valid. You should do both. Unit test your app and write integration tests as well. On my team, we run integration tests using docker-compose.

I use Sqlmock for that purpose

There is a good lib for db tests https://github.com/DATA-DOG/go-sqlmock