I'm exploring the use of TestContainers right now as part of the HDP 3.1
effort. Still exploring feasibility, but it is looking promising.
On Fri, May 3, 2019 at 10:46 AM Justin Leet wrote:
> I think everything Casey mentioned is a good call-out as things start to
> build into specifics. I
I didn't get a chance to say so earlier, but Justin, I also like the JUnit
5 extension suggestion. I've gone through some en-masse changes before,
e.g. standardizing the log4j construction idiom, and it honestly wasn't too
bad. Just a thought, it might make sense to kick this off by upgrading
I just want to chime in and say I'm STRONGLY in favor of a docker-based
approach to testing (I specifically like the JUnit 5 extensions
suggestion). I think that forcing a full-dev evaluation for every small PR
is a barrier to entry that I'd like to overcome. I also think that this is
going to
>
> My impression is that this is already the status quo. But, if we think we
> need to be more clear on this, let's put up a vote to change the coding
> guidelines and PR checklist. I've done this many times in the past, the
> most obvious instances are when I've made doc changes or unit test
>
Justin, what are your thoughts on leveraging this approach along with
long-lived Docker containers? I think the lifecycle would look like:
1. I need components A, B, C
2. If not started, start A, B, C
3. If started, clean/reset it
4. Setup pre-test state
5. Run test(s)
6.
Re: the integration testing point above, a strategy I used recently to
alleviate a similar problem was to exploit JUnit 5's extensions. I haven't
played with this at all in Metron's code, so 1) Take this with a several
grains of salt and 2) Feel encouraged to point out anything
Hi all,
I wanted to start a discussion on something near and dear to all of our
hearts: The role of full-dev in our testing cycle.
Right now, we require all PRs to have spun up the full-dev environment and
make sure that things flow through properly. In some cases, this is a
necessity, and in
