Hi everyone!

I'd like to propose an idea that I've been playing with for a bit.

*Core problem:*

Testing an API is not too challenging, and the tests are pretty fast too 
(e.g., controller and unit tests in Ruby on Rails).
Verifying that an Elm frontend works is fairly straightforward as well and 
fast (with elm-test).

To ensure that the interactions between Elm and the API work as intended, 
one approach is to utilize an End-To-End testing approach (such as 
simulating user interaction through PhantomJS, Selenium or similar).
However, those tests are slow and therefore a tradeoff between test suite 
runtime and amount of test cases needs to be made.

*Possible solution:*

Given the constraints above, it is a prudent approach to focus End-To-End 
tests to the more mission-critical features of an application.
In my experience, such tests mostly verify that everything is plugged 
together correctly and works "at first sight" (i.e., not exploring every 
last bit of functionality).

Compatibility between the frontend application and the API endpoints being 
used is a point where bugs can easily sneak in and increase the desire for 
E2E tests.

To deal with this, a possible solution might include sharing fixtures 
between API and frontend tests, such that:
- API tests verify that responses conform with a JSON fixture file
- Frontend test use the same JSON fixture files as "stubbed" API responses

I've created a small infographic illustrating the idea with an example right 
here <https://imgur.com/2M9nb4T>.


Please let me hear your thoughts on this! :-)
Best regards,
Jan

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to