etcd launcher, by exec-ing instead of Testcontainers

[vorburger]

It can be useful for projects using this jetcd project to be able to start etcd server in their respective tests. And not just for tests, but possibly also to simplify at least development (but probably never production) set ups - think "embedded database" (à la Derby, h2, MariaDB4j & Co.).

The tests in this project use Testcontainers. Projects using jetcd could also use Testcontainers for above. For simple Windows users, or even Linux noobs without Docker installed, this could sometimes be a PITA.

An alternative is to just start jetcd via exec. I'm doing this over in my EtcdLauncher. (That as-is currently just assumes that one has done e.g. sudo dnf install etcd ... it's also imaginable to make native binaries available as dependencies, such as how e.g. MariaDB4j and similar projects for other databases do it.)

Would a contribution with such a Launcher, or perhaps even some work for a simple etcd launch API which can start it either via Testcontainers or via exec, be of interest to this project?

If so, would using (and having a dependency from a jetcd:launcher artifact to) https://github.com/vorburger/ch.vorburger.exec for such a feature be acceptable, or do you have any preference for another similar launcher utility?

[lburgazzoli]

we were using a similar strategy in the past but it was not the best solution so I’d really like ti keep testcontainers for integration test and have a better mock framework for unit tests. But an ‘exec’ server could be useful so if you have time to contribute it, just send a pr and we’ll review it :)

On Mon, 20 Aug 2018 at 19:36, Michael Vorburger ⛑️ ***@***.***> wrote: It can be useful for projects using this jetcd project to be able to start etcd server in their respective tests. And not just for tests, but possibly also to simplify at least development (but probably never production) set ups - think "embedded database" (à la Derby, h2, MariaDB4j <https://github.com/vorburger/MariaDB4j/> & Co.). The tests in this project use Testcontainers <https://www.testcontainers.org>. Projects using jetcd could also use Testcontainers for above. For simple Windows users, or even Linux noobs without Docker installed, this could sometimes be a PITA. An alternative is to just start jetcd via exec. I'm doing this over in my EtcdLauncher <https://github.com/vorburger/opendaylight-etcd/blob/e2eb2dac17b399e142128c0d96971bc80995e14f/launcher/src/main/java/org/opendaylight/etcd/launcher/EtcdLauncher.java>. (That as-is currently just assumes that one has done e.g. sudo dnf install etcd ... it's also imaginable to make native binaries available as dependencies, such as how e.g. MariaDB4j <https://github.com/vorburger/MariaDB4j/> and similar projects for other databases do it.) Would a contribution with such a Launcher, or perhaps even some work for a simple etcd launch API which can start it either via Testcontainers or via exec, be of interest to this project? If so, would using (and having a dependency from a jetcd:launcher artifact to) https://github.com/vorburger/ch.vorburger.exec for such a feature be acceptable, or do you have any preference for another similar launcher utility? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#361>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AByEhQwowZ03lsiLaP29g8o74f8Vvaljks5uSvOzgaJpZM4WEa5d> .

-- -- Luca Burgazzoli

[bsideup]

Hi @vorburger,

I'm a member of Testcontainers project and would really like to hear from you what kind of issues you had, especially on Windows :)
We want to make it painless and happy to collect any kind of feedback 👍

[vorburger]

@bsideup nice to meet you. I have not had any particular issues with Testcontainers; it seems great!

It's just that if one were to use etcd as a data store in a project and had integration tests for it, and would require all (possibly many) developers to have Docker installed to be able to run TestContainers, that could raise the barrier to entry to another (not this jetcd) project. However I totally agree this is not a burning problem - this issue was more of an idea for the medium term.

To be honest, what really happened is that I wrote my EtcdLauncher using https://github.com/vorburger/ch.vorburger.exec/ BEFORE I first saw the Testcontainers utilities which are hidden inside this (jetc) project. So in #384 as a first step I'm proposing to better expose that! Perhaps I'll pick this idea up after (and based on / as an option of) that - later.

[cherrylzhao]

@vorburger
how about this issue going on, it is better to provide a mock EtcdLauncher framework for unit test

[vorburger]

how about this issue going on, it is better to provide a mock EtcdLauncher framework for unit test

@cherrylzhao I don't currently have plans to work on this. But if you would you like to take this, go! 😄

not a burning problem - this issue was more of an idea for the medium term.

To avoid future confusion, let me close this (old) issue.

[vorburger]

More FTR (I'm not still planning to implement this issue; of course others can) just FYI: TestContainers CAN some times be a little bit of a PITA... e.g. testcontainers/testcontainers-java#1356 and testcontainers/testcontainers-java#955.

[bsideup]

I'm sorry, but the PITA here is Docker and Docker's distribution, also Docker Compose (and we do not recommend using it, there are many more things on Docker Compose which really suck compared to generic containers, e.g. this: docker/compose#6636 ) :)