Also, though I think it's easy to slip into tests that test the mocks if you don't pay attention, you can have arbitrarily numerous mocks without having bad tests. Unit tests are not designed to reflect your runtime environment at all, they're here to make sure your function (program unit) does what it's supposed to do under different conditions. If your function accesses a DB for data, a Redis instance for (i don't know) cached identifiers, and an http API for other data, then you can mock the three of them (db, redis, and http API) and still have good unit tests, you just need to make sure you don't test that the mocks do what mocks do, but rather that your function responds well to different contexts.
Le mer. 28 juil. 2021 à 20:39, Marcin Romaszewicz <marc...@gmail.com> a écrit : > I have this exact testing issue at my company, we have many Go services > which use Postgres in production, but are unit tested against SQLite. > > The latest SQLite covers the vast majority of Postgres queries, so most > tests simply use an SQLite in-memory DB. > > For the tests which require Postgres- specific functionality, such as > partitioned tables, for example, we use > https://github.com/testcontainers/testcontainers-go. This is a library > which talks to Docker and can create your test prerequisites as docker > containers and gives you connection information once they're up. This makes > unit tests incredibly slower, but at least functional. > > The danger with mocking too much is that your unit tests end up testing > the mocks, and not anything remotely like your runtime environment, so > we've chosen to mock as little as possible. > > -- Marcin > > On Wed, Jul 28, 2021 at 4:09 AM Henry <henry.adisuma...@gmail.com> wrote: > >> On Wednesday, July 28, 2021 at 3:05:43 PM UTC+7 amits...@gmail.com wrote: >> >>> That sounds interesting - is the tool generating or is able to >>> generate SQL for different databases? That must have been a pretty big >>> effort to create such an abstraction. >>> >>> >> It produces different SQL for different databases. It supports a limited >> number of databases. Note that quite a number of Go ORM libraries already >> support multiple databases. So it is not new. The difference is that other >> ORM libraries usually provide a general purpose data access library, >> whereas ours generates more specific codes. Other than that, they serve a >> similar purpose. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/9c81746a-4fb4-4fb5-8e5f-605169a3f2afn%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/9c81746a-4fb4-4fb5-8e5f-605169a3f2afn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lv83-4yDijNmukf0Vx%2BoBVZXJPR11bqA_B5CY1mNhOowA%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lv83-4yDijNmukf0Vx%2BoBVZXJPR11bqA_B5CY1mNhOowA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAL4P9zwx2tiDhKfPGTzB_vseh%3D-bCq06Pv7LwRJeS%2B1-2fmdJg%40mail.gmail.com.
