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.
