go-sqlmock VS go-txdb

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

I’m writing a post about it! I will post soon, but you can use https://github.com/DATA-DOG/go-sqlmock to mock your database calls

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

I use https://github.com/DATA-DOG/go-sqlmock for unit testing my data layer code. Most of the times, these tests help me to find errors whenever I do a refactor on the data layer, so I consider it a good safety net

Continuous Integration - Testify, sqlmock, Mockery, Github Actions

For testing DB queries I use https://github.com/DATA-DOG/go-sqlmock for unit tests. I then have a separate integration test suite that runs against all our services using Docker.

3 years ago I created a internal library where I worked to setup the testing with the db's. One param was the schema directory and the other one was the path of the data insertion file. It worked really well but was a little slow. It was a little bit weird to configure the container to run the tests. As I would have to give access to go container that ran the unit tests access to docker. But back then I was running boot2docker and made things very cumbersome. I think with a local docker things would be way simpler. I ended up using and normal DB from the CI/CD and https://github.com/DATA-DOG/go-txdb If I had to do it again I might do an hybrid in-between the two solutions

The first one is TestMain, which could improve the lifecycle management of the container. The second one is DATA-DOG/go-txdb, this allows you to open a new db connection running in a transaction, so each test could have its own isolated DB connection.