Hacker News new | ask | show | jobs
by randomtask 1536 days ago
So, they suggest that you spin up the dependent services as part of the test runner and run tests for your service against those? I've worked on a codebase that did this extensively. Over time it lead to a test suite that takes a long time to run, slowing down the release process considerably, and inevitably requiring further engineering effort to make the tests run in a reasonable amount of time. I can't say I would recommend it as an approach based on my experience with it, but YMMV.
3 comments

Didn't even knew that Spotify wrote an article about this "methodology" thanks for sharing.

No, all you have to do is spin up your service under test, its database and the service bus/event hub/whatever you use to communicate between services.

Nowadays with Docker it's really easy and fast to spin up test instances during your test run. (4-5 LoC with a good library in C#).

Since 1 or 2 years I'm doing the exactly same thing on my projects and it works great to speed-up development process and if a bug pops in production it's really easy to add it as a future test case.

You're only attached to the input request (endpoint, query params, request body) and the response body. But that's ok because it's already a part of the contract between the API and its consumers. That's it.

>Over time it lead to a test suite that takes a long time to run, slowing down the release process considerably

Slower, but the test suite is far more effective at catching bugs.

These tests do take more up front engineering but since they arent pale imitations of the code they also dont need to be totally rewritten every time the code is refactored. Higher capex, lower opex.

You don’t use persistent databases to run these tests but put them on a tmpfs or in memory, right?
Can you (or someone else) tell me more about how to run database tests efficiently?

I'm working on an app that has 200+ tables and requires a lot of data to be in the database before anything even works at all. Of course good tests interacting with the database need a fresh database every time so even a test suite of about 10 tests can take 10-20 minutes already.

Yes correct then you can do Them in parallel