Re: [go-nuts] Re: What are the options to fake SQL database for testing?

On Thu, Jul 29, 2021 at 5:13 PM Brian Candler wrote: > > You might also want to look at podman, which runs containers directly as > processes under your own userid with no docker daemon - and buildah, the > corresponding tool for creating container images. I use them quite a lot for > building

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

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 wha

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

I don’t like the “solves the problem of your test running fine in isolation but fails when run in concert with other tests”. If you have that problem you have poorly written tests. > On Jul 29, 2021, at 2:05 PM, Andrew Werner wrote: > >  > Another choice to throw into the mix is > https://

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

Another choice to throw into the mix is https://github.com/cockroachdb/copyist. It comes with different trade offs but if you buy into its framework, it should be much faster than running the database. On Thu, Jul 29, 2021 at 3:13 AM Brian Candler wrote: > You might also want to look at podman,

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

You might also want to look at podman, which runs containers directly as processes under your own userid with no docker daemon - and buildah, the corresponding tool for creating container images. I use them quite a lot for building and running container images before deploying them to kubernet

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

On Thu, Jul 29, 2021 at 4:39 AM Marcin Romaszewicz wrote: > > 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

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

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- spec

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

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

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

On Wed, Jul 28, 2021 at 12:43 AM Henry wrote: > > Are we talking about testing the domain logic or the data persistence? . > > If it is about testing data persistence, rephrasing my earlier response, we > do not test data persistence, not very thoroughly anyway, because it is > auto-generated by

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

On Tue, Jul 27, 2021 at 7:19 PM Markus Zimmermann wrote: > > We switched from SQLite to PostgreSQL as our "in memory" database. We use an > SQL database so we do not have to mock DB calls and maintain an interface. If > that is something that is interesting i could trigger a blog post about what

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

On Tue, Jul 27, 2021 at 6:20 PM Levieux Michel wrote: > > Hi, > > IMO, specific mocks like DATA-DOG's tend to be complicated to use and have > behaviors that should not appear in a mock, which would ideally tend to have > no logic at all. > There are several mock packages that you can find here

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

Are we talking about testing the domain logic or the data persistence? . If it is about testing data persistence, rephrasing my earlier response, we do not test data persistence, not very thoroughly anyway, because it is auto-generated by a tool. We did however thoroughly tested the tool (and t

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

I'm not quite sure the intent is the same? Generating models only reduces the cognitive and time overhead of going back and forth from the code to the db. It does not test anything. Having a model that you are sure is a reflection of the db does not help you know that the logic going with it works?

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

We go-generate the mapping between the data models and the database. It was tedious to write such tool, but it was a time well spent. Now we just work with data models and not worry about testing the SQL instructions. Occasionally, we use SQLite in-memory database to double-check certain functi

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

We switched from SQLite to PostgreSQL as our "in memory" database. We use an SQL database so we do not have to mock DB calls and maintain an interface. If that is something that is interesting i could trigger a blog post about what we did and why? On Tuesday, July 27, 2021 at 10:21:23 AM UTC+2

Re: [go-nuts] Re: What are the options to fake SQL database for testing?

Hi, IMO, specific mocks like DATA-DOG's tend to be complicated to use and have behaviors that should not appear in a mock, which would ideally tend to have no logic at all. There are several mock packages that you can find here [and BTW if you have t

[go-nuts] Re: What are the options to fake SQL database for testing?

Hi all, I am just looking at options to write tests for parts of my application that interacts with a SQL database. So far it seems like the community has few distinct schools of thought: - Mocks (For e.g. using https://pkg.go.dev/github.com/DATA-DOG/go-sqlmock) - In-memory "real" DB solutions