TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: How should I test backing services that change frequently/break my code?

2 pointsby ayoubElkover 5 years ago
Hi folks,<p>I&#x27;m working on a nodeJS application that acts as an API gateway for a mobile app being actively developed. This API gateway doesn&#x27;t have any database, and formats&#x2F;forwards requests to their appropriate services, then returns the expected response to the mobile app.<p>Obviously testing my code and mocking the backing services is necessary to make sure it works as expected. However those services are complex, aren&#x27;t always stable, and sometimes changes are introduced to them that break the functionality of my API.<p>I&#x27;m wondering what the best testing&#x2F;monitoring strategy would be here that would allow me to reduce bugs in my API, and in case of breaking changes be notified in order to make the necessary changes?<p>Thanks

1 comment

jimsmartover 5 years ago
I am using a Github repo, linked to Travis CI - Travis can do cron&#x2F;scheduled builds (daily works for me). On build failure, including if any of the tests fail, I receive notification.<p>Some of my tests use mocks, others hit live remote&#x2F;third-party services. If anything external component&#x2F;system changes, or is down, I get to know about it, and can decide what is the best action to take. Sometimes it’s nothing more than a network glitch &#x2F; service outage, but sometimes endpoints change and&#x2F;or return different data.<p>You should definitely consider setting up a monitoring service for your app’s live HTTP endpoint. There are online services that may provide the functionality you require, but otherwise it’s NBD to write your own.<p>It can be a good idea to run monitoring from a different network, e.g. a different host, from the office, from home (or all of these).<p>Bespoke monitoring code can sometimes&#x2F;often leverage code that you already have in your tests. (Almost bringing us full circle, and back to CI)