I'd also be strongly in favor of having 1 approach to running our e2e and integration tests.
On Wed, Nov 29, 2017 at 5:59 AM, Justin Leet <justinjl...@gmail.com> wrote: > 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 > > > > > >
