9

I'm getting familiar with JavaScript testing, and may be missing a point or two related to mocking api calls. Every tutorial I have found mocks api calls when doing unit or integration testing - example: https://jestjs.io/docs/en/tutorial-async

I dont understand the value of mocking a server response by providing hard coded data, and then testing the value of that hard coded data. It seems like all such a test does is tell you whether or not your tool used a mock instead of an actual api call. That result doesn't tell you anything about the behavior of your application though does it not? Am I missing something?

Additionally, what if I wanted to actually test the result of a real api call? Does that push me over into functional testing territory? Could a real test of an api call be done with a tool like Jest, or is that better suited for something like selenium or testcafe?

skyboyer
  • 22,209
  • 7
  • 57
  • 64
Winston Smith
  • 123
  • 9
  • What if your testing environment backend is down? Would you want all of your tests to fail because the api returns 500 errors? No, you want to ensure that the frontend responds correctly to an api response. Similarly, imagine having thousands of tests that all require network responses. It would take so long to run. – Wolfie Feb 06 '19 at 19:38
  • 3
    Test isolation: http://wiki.c2.com/?UnitTestIsolation If you're doing E2E testing, then you want to hit the API. If you're unit/integration testing components, then you want to `reduce the scope` of your tests - test isolation. Also, you're correct, hitting the API is better done in E2E tests with something like selenium or cypress. – Adam Jenkins Feb 06 '19 at 23:33
  • @Wolfie, noted, thanks. – Winston Smith Feb 07 '19 at 19:24
  • @Adam, good suggestion, thank you. – Winston Smith Feb 07 '19 at 19:24

2 Answers2

7

If you want to test a call to a real api, and if that call is done by a front-end application, TestCafe offers Request Hooks that enable to check that the api is called in the right way and that the response contains the right data.

Mocking an API Response enables to do some kind of chaos testing: what happens to the front-end when API sends an HTTP 500/400/404/202/... or when the API never sends a response...

hdorgeval
  • 3,000
  • 8
  • 17
  • `Mocking an API Response enables to do some kind of chaos testing` +1. Can you imagine if you had to go and muck with your backend to send .a 500 just so you could test that your front end doesn't blow up if it gets one? – Adam Jenkins Feb 06 '19 at 23:35
  • @Adam You wouldn't need to "muck with your backend" for error responses. Those could easily be mocked in addition to a real API response for any 200s. And then you don't need to muck around with mock data that could easily get out of sync with a real response the server may send. – AJB Jan 06 '20 at 00:22
2

That result doesn't tell you anything about the behavior of your application though does it not

Sure it does. It tells you your front end component was able to correctly handle the received data (put it in a redux store, localStorage, update the UI, etc).

Adam Jenkins
  • 51,445
  • 11
  • 72
  • 100
  • I'm gathering that handling the received data is one of the missing pieces of the tutorials I looked at - they pretty much just do the mock and then end the test. – Winston Smith Feb 07 '19 at 17:14