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? Maybe there is something I don't understand.
BTW I'm interested to know if you tool is open-source? Thx! Le mar. 27 juil. 2021 à 11:49, Henry <henry.adisuma...@gmail.com> a écrit : > 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 > functionality work as intended. > > We also add code that allow the application to run tests against the > actual database during deployment. > > On Tuesday, July 27, 2021 at 3:21:23 PM UTC+7 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 >> <https://github.com/avelino/awesome-go#testing> [and BTW if you have >> time to give feedback I'm currently working on my own >> <http://github.com/mlevieux/gest>, 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>? ( >>>> 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 >>> <https://groups.google.com/d/msgid/golang-nuts/4fbc3ae9-b0ff-4750-bfba-1d58a1dba986n%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/ec72823c-d528-48a6-9d4c-704f0862fcb6n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/ec72823c-d528-48a6-9d4c-704f0862fcb6n%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/CAL4P9zyhghy_Tvu7TuNLVi4TZkk0c888F9dXMMG7WRUScf7ZBw%40mail.gmail.com.
