
Ask HN: How should I test backing services that change frequently/break my code? - ayoubElk
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
======
jimsmart
I am using a Github repo, linked to Travis CI - Travis can do cron/scheduled
builds (daily works for me). On build failure, including if any of the tests
fail, I receive notification.

Some of my tests use mocks, others hit live remote/third-party services. If
anything external component/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 / service outage, but sometimes endpoints change
and/or return different data.

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.

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).

Bespoke monitoring code can sometimes/often leverage code that you already
have in your tests. (Almost bringing us full circle, and back to CI)

