Currently the e2e tests for our Alerts UI depends on full dev being up and
running.  This is not a good long term solution because it forces a
contributor/reviewer to run the tests manually with full dev running.  It
would be better if the backend services could be made available to the e2e
tests while running in Travis.  This would allow us to add the e2e tests to
our automated build process.

What is the right approach?  Here are some options I can think of:

   - Use the in-memory components we use for the backend integration tests
   - Use a Docker approach
   - Use mock components designed for the e2e tests

Mocking the backend would be my least favorite option because it would
introduce a complex module of code that we have to maintain.

The in-memory approach has some shortcomings but we may be able to solve
some of those by moving components to their own process and spinning them
up/down at the beginning/end of tests.  Plus we are already using them.

My preference would be Docker because it most closely mimics a real
installation and gives you isolation, networking and dependency management
features OOTB.  In many cases Dockerfiles are maintained and published by a
third party and require no work other than some setup like loading data or
templates/schemas.  Elasticsearch is a good example.

I believe we could make any of these approaches work in Travis.  What does
everyone think?

Ryan

Reply via email to