As an additional consideration, it would be really nice to get our current set of integration tests to be able to be run on this infrastructure as well. Or at least able to be converted in a known manner. Eventually, we could probably split out the integration tests from the unit tests entirely. It would likely improve the build times if we we're reusing the components between test classes (keep in mind right now, we only reuse between test cases in a given class).
In my mind, ideally we have a single infra for integration and e2e tests. I'd like to be able to run them from IntelliJ and debug them directly (or at least be able to easily, and in a well documented manner, be able to do remote debugging of them). Obviously, that's easier said than done, but what I'd like to avoid us having essentially two different ways to do the same thing (spin up some our of dependency components and run code against them). I'm worried that's quick vs full dev all over again. But without us being able to easily kill one because half of tests depend on one and half on the other. On Wed, Nov 29, 2017 at 1:22 AM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > What about just spinning up each of the components in their own process? > It's even lighter weight, doesn't have the complications for HDFS (you can > use the local FS easily, for example), and doesn't have any issues around > ports and port mapping with the containers. > > On Tue, Nov 28, 2017 at 3:48 PM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > > > As long as there is not a large chuck of custom deployment that has to be > > maintained docker sounds ideal. > > I would like to understand what it would take to create the docker e2e > env. > > > > > > > > On November 28, 2017 at 17:27:13, Ryan Merriman (merrim...@gmail.com) > > wrote: > > > > 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 > > >
