The Adapter Pattern in Go | Hacker News Reader

The Adapter Pattern in Go

bitfieldconsulting.com

18 pointsgus_leonel26 comments

Honestly, just use a real db in testing. Purity is all well and good, but not at the expense of more bugs caught.

Sometimes you don’t have that option. Or the database has so many constraints that creating testdata is just not worth the mountain of effort.

Imho: Everything which promotes unit testing also promotes maintainable code.

Dependency inversion with the aim of writing unit tests is helpful for logic or calculation heavy chunks of code but for everything else it actually makes the code less maintainable.

It balloons the size of the code base and as a reward you end up with a ton of mimetic tests that mirror the code and dont actually catch any bugs.

I'm sure this approach can be applied to some problem domains better than others. If you have a simple CRUD app, then yes there isn't much you can check.

But even there, you can at the very least mock the responses of the database (or other external systems) and check if the data in your response is as expected. Naturally, this works best if you work with structured data or have a well-defined domain. In case of a well defined domain, you can just mock the domain models don't even touch the module which talks to the outside world.

>But even there, you can at the very least mock the responses of the database (or other external systems) and check if the data in your response is as expected.

You certainly can but these tests end up mimicking the implementation rather than actually testing the code.

A pure CRUD app - even if it's relatively complicated - should have zero unit tests.

I guess you can technically test everything in a CRUD app as integration test. Doesn't mean you should.

Surely, you have a baseline of verification/validation logic for which unit tests are the best fit. And based on my experience of my last project, if you can't do proper unit testing you likely have the wrong granularity in your methods and classes.

I also don't see the point in mocking out your database unless you have slow tests due to hardware constraints, a huge project or your db tests not being parallelized. Regarding the latter I've had much success with a similar approach to [1], and with a few helpers in each layer (service-repo) my tests have never been cleaner.

[1]: https://kevin.burke.dev/kevin/fast-parallel-database-tests

Same. The moment my tests need to care about implementation details, is the moment I stop trying to mock/fake/stub/etc stuff and just test against the real thing if possible.

I don't want to worry about whether a library is correctly implementing the real behavior of the real thing.

I can understand wanting to mock/fake/stub/whatever stuff that is outside of your control, like a third-party HTTP API where you can't just send real requests just for testing.

But for the situation in the article, those tests just seem too fragile to me. And a lot of effort for the comparatively little confidence added by the test results.

I keep wondering why people won't test with a real database. Right, you need to create it and clean it up before or after every test, but that's a lot cheaper than having to stub everything related to the db.

Also spinning one up locally is easy thanks to Docker.

If you're using a container, you don't need to create the DB or clean it up when you run tests. Just spin up a new container and then throw it away if nothing went wrong.

Create = spin up

Clean up = throw away

> Right, you need to create it and clean it up before or after every test, but that's a lot cheaper than having to stub everything related to the db.

Depends on the bringup cost, although templates help there (create a baseline database, then copy it for each test).

Docker is great, another option I like to use is sqlite.

I'm writing a small and simple application and I'm just using an sqlite database for my tests. I have a helper function to create the db, another to add a table, and then a third to delete the db at the end.

So in total 3 functions to setup and teardown a test database. Its super quick because an sqlite db is just a file after all.

it's a real shame that sqlite and postgres have sql differences, otherwise I'd use it alot more

Yeah... Mocking is like wanting to be a lion tamer but training with a cat.

The problem with this approach in practice is that the abstraction tends to leak real fast. One day you'll need to hack something ugly to fix a performance issue in prod or whatever and it all will come crashing down.

If you want to mock a database to have a fast subset of tests, first test the client the hard way and prove you’re using the real database correctly (not just asserting what you hope it would do).

Any ideas how you test the SQL using this approach?

Mock a result that says "everything is OK" and continue watching Netflix.

I jest. I don't like mocking database methods, they don't give me much confidence. I test the SQL against Postgres in a Docker container.

It's ideal for testing all the negative paths, the error handling.

With a real DB it's not exactly easy to inject "ERROR: deadlock" at every single step.

Besides mocks hiding subtle bugs, the adapter approach can very easily hide costs. This is how you end up with O(n) SQL queries.

Can you elaborate on what you mean?

The Store interface in the post assumes a single thing is created. If requirements change and you need to create thousands, the naive change will end up calling Store(Widget) that many times and thus that many SQL queries.

Abstractions are useful, but they also leak. The wrong abstraction can make many useful things impossible.

If you use Store interfaces that are specific to the needs of the client, rather than building one universal Store that covers every possible use case, isn't it fairly easy to modify that abstraction when the need arises? (Sort of the same idea as "backend for frontend" compared to a completely general backend API.)

Those needs will change. Requirements will come that are easy to implement efficiently in terms of SQL queries, but impossible through the abstraction. You may then be able to come up with a new interface, which requires you to change your existing code.

Just like ORMs, such interfaces can be useful, but have the cost of limiting your options.

I'm not sure how I feel about it yet, but I've seen codebases that have tests asserting the number of queries that should have been run. Those tests have caught a couple of issues in the past, and they do seem to make the engineers on that team understand better what their ORM is doing.

Reply on news.ycombinator.com