Robert - you meant this as a mostly-automatic thing that we would engineer, yes?
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. 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 >
