Respawn VS testhelper.mod

ImMemoryDb isnt recommended for testing as it doesnt behave as a real database. Save yourself trouble and use a real database paired with Respawn.

I come from a .NET background and in the .NET environment I used to seed the database with the necessary data on each test and then clean the database at the end of the test using the Respawn library.

This was our initial approach (using sqlite) but our migrations take a while to run and this resulted in slow tests. Using Respawn to clean the db significantly improved test performance (https://github.com/jbogard/Respawn)

Have you used something like Respwan https://github.com/jbogard/Respawn instead of creating and cleaning or deleting database every time? Not sure if it would help you. But I thought it might make your workflow little simpler. Respawn lets to restore db to a restore point.

NUnit, FluentAssertions, Moq & Respawn

You will need a separate test database purely for integration tests. You will need to reset the state of the DB every time using something like https://github.com/jbogard/Respawn. I always use the (localdb)\mssqllocal SQL instance that comes as standard with VS for dev and integration test databases.

The standard Go testing environment is very good, certainly for unit testing. You might want to use some test helper packages to provide some missing features. For instance, table-driven testing where you have a table of test-specific structures providing inputs and expected results which you iterate over, is a good way of organising your tests. One downside is that the test failure will all be reported from the same line and it can be hard to find the failing test. A useful helper to identify the failing test is the ID struct from github.com/nickwells/testhelper.mod/v2/testhelper which if created using the MkID function will show the filename and line of the failing test. This package also offers standardised comparison checks and support for Golden files and lots more.

You can get the testhelper package with