TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: How do you write integration tests for complex pipelines?

2 点作者 dondraper36超过 2 年前
Apart from obvious unit tests and some mocks (no love for mocks, honestly speaking), there comes a point when you need to make sure that the end-to-end logic is correct in your application while it interacts with other services, the database, etc.<p>To be more specific, let&#x27;s say there is a service that has a few endpoints with tricky behaviors.<p>For example, creating a resource might require:<p>* Making a call to service A * Creating new records in table X * Creating new records in table Y ... * Making a call to service B<p>You get the idea. Even writing mocks for such cases is tiresome, not to mention that it might say nothing about the real interactions in the wild.<p>My current approach is using dockertest (I use Go for this project and Postgres), spinning PG in a Docker container and, well, testing each endpoint method completely.<p>Having said that, I would be interested in knowing how other people write such tests, how granular they are, what exactly is tested.<p>Probably, you can recommend some nice resources on integration testing you know of and find illuminating.

1 comment

brodouevencode超过 2 年前
The first step is to really question if you need this level of complexity. Remove the things that provide no value. Break out data transformations into their own processes or microservices. Isolate them and really treat them like a black box. Unit test heavily here. Go is built for microservices. I&#x27;ve got a go application that I&#x27;ve inherited that&#x27;s very light on the unit testing and heavy on the end to end integration testing. Golang doesn&#x27;t make this sort of thing easy or enjoyable. I&#x27;ll probably rip a lot of that out if we wind up changing major parts of it.<p>Remember, testing is an insurance policy. It provides no direct value to the business. That&#x27;s not to say it shouldn&#x27;t be done, it most certainly should. But when testing becomes the majority of your coding effort then it&#x27;s time to start re-evaluating your testing approach.