On Mon, Jan 21, 2019 at 10:42 PM Kenneth Knowles <k...@google.com> wrote: > > Robert - you meant this as a mostly-automatic thing that we would engineer, > yes?
Yes, something like TestPipeline that buffers up the pipelines and then executes on class teardown (details TBD). > A lighter-weight fake, like using something in-process sharing a Java > interface (versus today a locally running service sharing an RPC interface) > is still much better than a mock. +1 > > Kenn > > On Mon, Jan 21, 2019 at 7:17 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: >> >> Hi, >> >> it makes sense to use embedded backend when: >> >> 1. it's possible to easily embed the backend >> 2. when the backend is "predictable". >> >> If it's easy to embed and the backend behavior is predictable, then it >> makes sense. >> In other cases, we can fallback to mock. >> >> Regards >> JB >> >> On 21/01/2019 10:07, Etienne Chauchot wrote: >> > Hi guys, >> > >> > Lately I have been fixing various Elasticsearch flakiness issues in the >> > UTests by: introducing timeouts, countdown latches, force refresh, >> > embedded cluster size decrease ... >> > >> > These flakiness issues are due to the embedded Elasticsearch not coping >> > well with the jenkins overload. Still, IMHO I believe that having >> > embedded backend for UTests are a lot better than mocks. Even if they >> > are less tolerant to load, I prefer having UTests 100% representative of >> > real backend and add countermeasures to protect against jenkins overload. >> > >> > WDYT ? >> > >> > Etienne >> > >> > >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com
