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 the code it generates) against actual common SQL databases. It is an upfront investment, so that we do not have to do similar tests for the subsequent projects.
The tool is not open-source, but there are plenty of ORM and ORM-like open source Go libraries around. You may consider writing your own. I think in the long run, it is a worthy investment. When I first started it, I just wanted to save time from having to write repetitive mapper for each data type. Our data access code were quite fragile to changes. The manually typed SQL commands were also error prone, and not everybody in the team is familiar with various SQL dialects. So I wrote the tool to auto generate the necessary code. The tool was then used by my colleagues, and over time they added their own enhancement. Now every time there is a change, I just update the data models, run the tool, and done. We do a test run against a copy of the actual database before deployment, and the final test run against the actual database during deployment. On Tuesday, July 27, 2021 at 4:55:46 PM UTC+7 mlevi...@gmail.com wrote: > 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.ad...@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...@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/df878e11-3a70-45d1-9cc3-7a73d864ee9an%40googlegroups.com.
