On Tue, Jul 27, 2021 at 7:19 PM Markus Zimmermann <zimm...@gmail.com> 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 > we did and why?
That will be great to hear. I am assuming your tests do not use any PostgreSQL specific functionality? This thread looks interesting as well [1] [1] https://news.ycombinator.com/item?id=10002142 > > On Tuesday, July 27, 2021 at 10:21:23 AM UTC+2 mlevi...@gmail.com 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 [and BTW if you have >> time to give feedback I'm currently working on my own, anyway that is >> completely unrelated]. >> >> It really depends on what you are looking for in terms of features. Do you >> need something that is able to error on syntax problems? That keeps track of >> the execution flow (i.e. if you insert data in your fake database, are you >> expecting it to be able to return it to you? Under what conditions?)? >> >> Mocking complex systems like SQL databases is quite hard... What I have seen >> many times is just to have a "seed-based" local database that is used in >> local integration tests. >> Another, quite efficient solution is to have a test suite's database >> initialized once and used for all subsequent unit tests. Once you have good >> unit tests for your database-interacting low-level functions, and >> integration tests for the whole flow, you can just mock the db behavior in >> other higher level unit tests because you know it'll work in production. >> >> Hope this helps! >> >> Le mar. 27 juil. 2021 à 10:04, Amit Saha <amits...@gmail.com> a écrit : >>> >>> 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 - such as tidb-lite for MySQL >>> (https://github.com/WangXiangUSTC/tidb-lite) >>> - Container based functional/integration style testing >>> >>> It will be great to hear if anybody has some other experiences to share. >>> >>> Thanks, >>> Amit. >>> >>> >>> On Saturday, October 10, 2015 at 5:30:20 AM UTC+11 kyle.a...@gmail.com >>> wrote: >>>> >>>> >>>> On Thursday, October 8, 2015 at 3:54:08 PM UTC-4, vkoch...@gmail.com wrote: >>>>> >>>>> P.S. I don’t see embedded versions of PostgreSQL or MySql. The SQLite is >>>>> not quite reach SQL implementation from enterprise point of view. >>>> >>>> >>>> Maybe have a look at tidb? >>>> (https://github.com/pingcap/tidb/blob/master/docs/USAGE.md) >>> >>> -- >>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/4fbc3ae9-b0ff-4750-bfba-1d58a1dba986n%40googlegroups.com. > > -- > 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/5829cbca-703d-42c4-9338-5f739375568an%40googlegroups.com. -- 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/CANODV3kBK5%2B25Nhf71xFAm0K1WExrZfX3wL6oiPCaza7CT6JsA%40mail.gmail.com.
