On Wed, Jul 28, 2021 at 12:43 AM Henry <henry.adisuma...@gmail.com> 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 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.
Thanks for sharing your experiences and approach to testing. I once again read this is as taking a layered approach to testing. I am curious about this point: >We did however thoroughly tested the tool (and the code it generates) against >actual common SQL databases. 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. > > 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 [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...@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. > > -- > 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. -- 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/CANODV3mLXPcjw1QchWGhximqL748PaZMzcKSXuJSO%3DsLWHDPtw%40mail.gmail.com.
