It seems common practice to mock API requests on the frontend - for good reasons, I am sure.
My counter argument is:
mocking sometimes requires as much work (or more) as just making a normal request
if my FE code under test is concerned with making requests from an API, mocking becomes tautologous
mocking can become outdated and a chore.
Any thoughts?.
It can depend on what happens if you don’t mock the API calls. In my job we mock out requests that, unless mocked, would lead a Server Build Tech to pull a server out of inventory, add RAM and Storage, then wire it into a rack and on the network.
Doing the mocking is a chore and it is possible that the mocks get out of sync with the actual API, but the cost of not mocking those API calls in the test case is too expensive.
Anything that crosses the boundaries of your application, must be mocked, stubbed… So this include dependencies and specially APis.
For APIs is good practice to follow API Design first using RAML or Swagger that will enable the use of Consumer Driven Contracts Tests, avoiding the drift between the consumer and the provider of the API, both in testing and production.
Never use an API for real in a test, like you will never send an email for real in a test.
I understand why you say this but you can say the same thing about the controller tests in a JSON API if they are only consumed by your own UI code. Your tests send some data, get some data back, make some assertions. None of that proves it will meet the expectation of the UI code, yet still these tests are very useful and provide a lot of value that is unquestioned. That data you prepare for a request? Its a mock.
When we first started testing our front-end SPA code, we struggled with this quite a lot. We use Jest which has nice mocking but still creating the mocks is tedious and very often we spend far more time preparing data mocks to get our test working than we spent coding the new functionality under test. We so far do not see nearly so much value in these tests. Where we can write unit tests (a discrete piece of logic unconnected to UI/Store/API) the value is much easier to see. Still, the component tests run very fast and so its economical to test edge cases and to add coverage for bugs once the component itself is stood up.
Actually I find it much much faster to write E2E tests (we use Cypress, which is awesome and very fast to iterate on). The Cypress tests use the Phoenix’s Plug SQL Sandbox feature so we can use ex_machina to prepare data for each test and roll it back afterward just like a controller test (we have a fixture controller the test code can invoke to create a list of mocks). When we test this way its very easy to see the value in what it is doing, but unfortunately it is slow so we only use it to test a basic critical happy-path for each module of app (and not all the ancillary features).
© Copyright Elixir Forum | Terms | Privacy & Cookies
