-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow better support for test frameworks other than JUnit #87
Comments
Cool, thanks! In terms of structuring this, I think there's a reasonably chunky refactoring coming up in the future so it might be best to consider now. I'm thinking that:
This diagram roughly illustrates my thinking (please excuse the UML ;)): What do you think? |
@rnorth looks good! I'm thinking about some refactorings before we start (especially in case of v2.0.0), will write them down to discuss a little bit later |
I'd be very interested in a version of which does not include any Lot's of the feature I still need add to my extension are already available in testcontainers in a quite accessible and convenient manner. So I wonder how I could best integrate testconainters into my project, or help in modularising the current version of the library. As for the time being I'm still hesistant in integrating this project as long as this will include JUnit dependencies. |
@kiview thanks for the comment - sorry for the delay in responding! Yes, breaking the JUnit dependency is absolutely something I'd like to do, as you can see from this ticket. It would probably be reasonable to do #240 at the same time; either as a separate JAR for |
@rnorth sounds good for me. I have some free time this week, so I can take this task if you don't mind :) I see two tasks here - one for "JUnit-free core" and another one "separate DockerClientFactory", so we can split the work. WDYT? |
@bsideup sure, that'd be great! Does the diagram above make sense, or do you want to discuss any refinements? DockerClientFactory would probably have to move into the new containercore JAR anyway, but yeah I'd imagine the tidy-up work to make DCF be a real reusable class can follow. |
@rnorth it looks good, but I can't say exactly until I start :) Also, looks like there is only one open external PR, so I think it's a good time to start 2.x |
I'll try to explain my use cases when using this library in conjunction with the spock extension:
Bonus points for Windows support with named pipes ;) Another thing which would be awesome would be the possibility to run my tests inside a container, so I can use features like docker networking to access my testcontainers. But this seems like another project ;) (Gradle plugin maybe?) |
I'll be a bit easier to satisfy :p |
My currently used interface hast indeed quite similar methods: I even think about keeping this facade class and simply substitute the used docker library with testcontainers, since testcontainers already gives mehr a high level of abstraction. This would mean, I would use testcontainers as a high level Docker client. |
Today I pushed an experiment with JUnit 5 to the branch: Feedback is welcome :) |
It was my first thought, just wanted to confirm 😄 There is a nice hook, which is doing it: https://github.com/testcontainers/testcontainers-java/blob/master/core/src/main/java/org/testcontainers/utility/ResourceReaper.java#L362 |
@colinmorelli I did something along the lines of below pattern, which seems to work reasonably well without reliance on ClassRule mechanism (pattern is likely equally relevant for use in non-junit test frameworks):
Then you reference the static getContainer() method across your test suite whenever you need it, and it is an effective singleton for the test suite JVM in the usual case. (updated based on @bsideup confirmation that ResourceReaper uses JVM-level shutdown listener) |
@tom-haines actually, public class PostgresContainer {
private static final PostgreSQLContainer container = new PostgreSQLContainer();
static {
container.start();
}
public static PostgreSQLContainer getContainer() {
return container;
}
} |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this. |
Not stale - this is something we're always thinking about for the next breaking change release. #887 is an example of JUnit 5 support that is well integrated with the library already. |
Bumps [lombok](https://github.com/rzwitserloot/lombok) from 1.16.6 to 1.18.4. <details> <summary>Changelog</summary> *Sourced from [lombok's changelog](https://github.com/rzwitserloot/lombok/blob/master/doc/changelog.markdown).* > ### v1.18.4 (October 30th, 2018) > * PLATFORM: Support for Eclipse Photon. [Issue #1831](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1831) > * PLATFORM: Angular IDE is now recognized by the installer [Issue #1830](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1830) > * PLATFORM: Many improvements for lombok's JDK10/11 support. > * BREAKING CHANGE: The `[**FieldNameConstants**](https://github.com/FieldNameConstants)` feature has been completely redesigned. [Issue #1774](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1774) [FieldNameConstants documentation](https://projectlombok.org/features/experimental/FieldNameConstants) > * BREAKING CHANGE: Lombok will now always copy specific annotations around (from field to getter, from field to builder 'setter', etcetera): A specific curated list of known annotations where that is the right thing to do (generally, `[**NonNull**](https://github.com/NonNull)` style annotations from various libraries), as well as any annotations you explicitly list in the `lombok.copyableAnnotations` config key in your `lombok.config` file. Also, lombok is more consistent about copying these annotations. (Previous behaviour: Lombok used to copy any annotation whose simple name was `NonNull`, `Nullable`, or `CheckForNull`). [Issue #1570](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1570) and [Issue #1634](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1634) > * FEATURE: Lombok's `[**NonNull**](https://github.com/NonNull)` annotation can now be used on type usages (annotation on type usages has been introduced in JDK 8). `[**Builder**](https://github.com/Builder)`'s `[**Singular**](https://github.com/Singular)` annotation now properly deals with annotations on the generics type on the collection: `[**Singular**](https://github.com/Singular) List<[**NonNull**](https://github.com/NonNull) String> names;` now does the right thing. > * FEATURE: You can now mix `[**SuperBuilder**](https://github.com/SuperBuilder)` and `toBuilder`, and `toBuilder` no longer throws `NullPointerException` if a `[**Singular**](https://github.com/Singular)`-marked collection field is `null`. [Issue #1324](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1324) > * FEATURE: delombok now supports module paths via the `--module-path` option, and will automatically add lombok itself to the module path. This should make it possible to delombok your modularized projects. [Issue #1848](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1848) > * FEATURE: You can pass `[**args**](https://github.com/args).txt` to `delombok` to read args from the text file; useful if you have really long classpaths you need to pass to delombok. [Issue #1795](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1795) > * BUGFIX: `[**NoArgsConstructor**](https://github.com/NoArgsConstructor)(force=true)` would try to initialize already initialized final fields in Eclipse. [Issue #1829](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1829) > * BUGFIX: When using lombok to compile modularized (`module-info.java`-style) code, if the module name has dots in it, it wouldn't work. [Issue #1808](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1808) > * BUGFIX: Errors about lombok not reading a module providing `org.mapstruct.ap.spi` when trying to use lombok in jigsaw-mode on JDK 11. [Issue #1806](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1806) > * BUGFIX: Fix NetBeans compile on save. [Issue #1770](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1770) > * BUGFIX: If you manually write your builder class so you can add a few methods of your own, and those methods refer to generated methods, you'd usually run into various bizarre error messages, but only on JDK9/10/11. This one is hard to describe, but we fixed it. [Issue #1907](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1907) > > > ### v1.18.2 (July 26th, 2018) > * BUGFIX: mapstruct + lombok in eclipse should hopefully work again. [Issue #1359](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1359) and [mapstruct issue #1159](https://github-redirect.dependabot.com/mapstruct/mapstruct/issues/1159) > * BUGFIX: Equals and hashCode again exclude transient fields by default. [Issue #1724](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1724) > * BUGFIX: Eclipse 'organize imports' feature (either explicitly, or if automatically triggered on saving via 'save actions') would remove the import for `lombok.var`. [Issue #1783](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1783) > * BUGFIX: Lombok and gradle v4.9 didn't work together; that's been fixed. [Issue #1716](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1716) and [gradle-apt-plugin issue #87](https://github-redirect.dependabot.com/tbroyer/gradle-apt-plugin/issues/87) > * FEATURE: You can now make builders for type hierarchies, using the new (experimental) `[**SuperBuilder**](https://github.com/SuperBuilder)` annotation. Thanks for the contribution, Jan Rieke. [`[**SuperBuilder**](https://github.com/SuperBuilder)` documentation](https://projectlombok.org/features/experimental/SuperBuilder) > * FEATURE: `[**NoArgsConstructor**](https://github.com/NoArgsConstructor)`, including forcing one with `lombok.config: lombok.noArgsConstructor.extraPrivate=true` now take any defaults set with `[**Builder**](https://github.com/Builder).Default` into account. [Issue #1347](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1347) > ### v1.18.0 (June 5th, 2018) > * BREAKING CHANGE: The in 1.16.22 introduced configuration key `lombok.noArgsConstructor.extraPrivate` is now `false` by default. [Issue #1708](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1708) > * BUGFIX: Do not generate a private no-args constructor if that breaks the code. [Issue #1703](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1703), [Issue #1704](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1704), [Issue #1712](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1712) > * BUGFIX: Using boolean parameters in lombok annotations would fail. [Issue #1709](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1709) > * BUGFIX: Delombok would give an error message. [Issue #1705](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1705) > * BUGFIX: Eclipse java10 var support didn't work if lombok was installed in your eclipse. [Issue #1676](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1676) > * FEATURE: Google's [Flogger (a.k.a. FluentLogger)](https://google.github.io/flogger/) is now available via `[**Flogger**](https://github.com/Flogger)`. [Issue #1697](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1697) > * FEATURE: `[**FieldNameConstants**](https://github.com/FieldNameConstants)` has been extended to support prefixes and suffixes. By default, the generated constants are prefixed with `FIELD_`. [Docs on [**FieldNameConstants**](https://github.com/FieldNameConstants)](https://projectlombok.org/features/experimental/FieldNameConstants). > > ### v1.16.22 "Envious Ferret" (May 29th, 2018) > * FEATURE: Private no-args constructor for `[**Data**](https://github.com/Data)` and `[**Value**](https://github.com/Value)` to enable deserialization frameworks (like Jackson) to operate out-of-the-box. Use `lombok.noArgsConstructor.extraPrivate = false` to disable this behavior. > * FEATURE: Methods can now be marked for inclusion in `toString`, `equals`, and `hashCode` generation. There is a new mechanism to mark which fields (and now, methods) are to be included or excluded for the generation of these methods: mark the relevant member with for example `[**ToString**](https://github.com/ToString).Include` or `[**EqualsAndHashCode**](https://github.com/EqualsAndHashCode).Exclude`. [ToString documentation](https://projectlombok.org/features/ToString) [EqualsAndHashCode documentation](https://projectlombok.org/features/EqualsAndHashCode) > * FEATURE: `[**Getter**](https://github.com/Getter)` and `[**Setter**](https://github.com/Setter)` also allow `onMethod` and `onParam` when put on a type. [Issue #1653](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1653) > * FEATURE: `[**FieldNameConstants**](https://github.com/FieldNameConstants)` is a new feature that generates string constants for your field names. [Docs on [**FieldNameConstants**](https://github.com/FieldNameConstants)](https://projectlombok.org/features/experimental/FieldNameConstants). > * PLATFORM: Lombok can be compiled on JDK10, and should run on JDK10. [Issue #1693](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1693) > * PLATFORM: lombok now counts as an _incremental annotation processor_ for gradle. Should speed up your gradle builds considerably! [Issue #1580](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1580) > * PLATFORM: Fix for using lombok together with JDK9+'s new `module-info.java` feature. [Issue #985](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/985) > * BUGFIX: Solved some issues in eclipse that resulted in error 'A save participant caused problems'. [Issue #879](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/879) > * BUGFIX: Netbeans on jdk9. [Issue #1617](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1617) > * BUGFIX: Netbeans < 9. [Issue #1555](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1555) > * PROMOTION: `var` has been promoted from experimental to the main package with no changes. The 'old' experimental one is still around but is deprecated, and is an alias for the new main package one. [var documentation](https://projectlombok.org/features/var.html). > * OLD-CRUFT: `lombok.experimental.Builder` and `lombok.experimental.Value` are deprecated remnants of when these features were still in experimental. They are now removed entirely. If your project is dependent on an older version of lombok which still has those; fret not, lombok still processes these annotations. It just no longer includes them in the jar. > > ### v1.16.20 (January 9th, 2018) > * PLATFORM: Better support for jdk9 in the new IntelliJ, Netbeans and for Gradle. > * BREAKING CHANGE: _lombok config_ key `lombok.addJavaxGeneratedAnnotation` now defaults to `false` instead of true. Oracle broke this annotation with the release of JDK9, necessitating this breaking change. ></table> ... (truncated) </details> <details> <summary>Commits</summary> - [`8451c88`](projectlombok/lombok@8451c88) pre-release version bump - [`e960f48`](projectlombok/lombok@e960f48) cleaning up the changelog in preparation for a release. - [`9b06018`](projectlombok/lombok@9b06018) [fixes #1907] This one is hard to describe; due to builder being a bit overze... - [`f5b1069`](projectlombok/lombok@f5b1069) add jdk11 to docker builds - [`0336537`](projectlombok/lombok@0336537) fixing the tests added in the previous commits by janrieke to match alternati... - [`d8de0e3`](projectlombok/lombok@d8de0e3) Merge branch 'wildcardsSingularFix' of git://github.com/janrieke/lombok into ... - [`eca219e`](projectlombok/lombok@eca219e) eliminate ‘you are using private API’ warnings by streamlining all reflective... - [`182cb0c`](projectlombok/lombok@182cb0c) [java-11] up dependency on lombok.patcher, including asm7 - [`c02263a`](projectlombok/lombok@c02263a) Merge pull request [#1923](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1923) from abargnesi/fix-maven-issue-management - [`4cf36b2`](projectlombok/lombok@4cf36b2) Merge pull request [#1917](https://github-redirect.dependabot.com/rzwitserloot/lombok/issues/1917) from kkocel/master - Additional commits viewable in [compare view](projectlombok/lombok@v1.16.6...v1.18.4) </details> <br /> [![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=org.projectlombok:lombok&package-manager=maven&previous-version=1.16.6&new-version=1.18.4)](https://dependabot.com/compatibility-score.html?dependency-name=org.projectlombok:lombok&package-manager=maven&previous-version=1.16.6&new-version=1.18.4) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- **Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit. You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com). <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in the `.dependabot/config.yml` file in this repo: - Update frequency (including time of day and day of week) - Automerge options (never/patch/minor, and dev/runtime dependencies) - Pull request limits (per update run and/or open at any time) - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired) Finally, you can contact us by mentioning @dependabot. </details>
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this. |
Just quoting @rnorth
|
* removes workaround in `SerenityStepExtension` as `net.thucydides.core.steps.StepInterceptor#executeTestStepMethod` now properly detects as assumption violation (and does not consider it an error as before). * steps after a step with assumption violation are now ignored (instead of skipped) * verified with JUnit4 that this is the desired behaviour. Before the behaviour was different, because a assumption violation was handled liked an error and in case of an error following steps are skipped. The workaround mentioned above was not able to fully correct this. * `net.thucydides.core.steps.BaseStepListener#stepIgnored` => SKIPPD if previous step failed; IGNORED if e.g. previous had a assumption violation * Testcontainers currently includes a dependency to Junit4 which we don't want to have. Therefore Jnit4 is excluded in each testcontainers dependency * see also section "Limitations" in https://www.testcontainers.org/test_framework_integration/junit_5 * Looks like this will not go away soon: * testcontainers/testcontainers-java#1525 * testcontainers/testcontainers-java#87 * The required JUnit4 rule support is covered by a dependency to JUnit5 `junit-jupiter-migrationsupport` * Junit rule needs to be on the classpath, because `BrowserWebDriverContainer` extends `FailureDetectingExternalResource` which extends `org.junit.rules.TestRule`
* removes workaround in `SerenityStepExtension` as `net.thucydides.core.steps.StepInterceptor#executeTestStepMethod` now properly detects as assumption violation (and does not consider it an error as before). * steps after a step with assumption violation are now ignored (instead of skipped) * verified with JUnit4 that this is the desired behaviour. Before the behaviour was different, because a assumption violation was handled liked an error and in case of an error following steps are skipped. The workaround mentioned above was not able to fully correct this. * `net.thucydides.core.steps.BaseStepListener#stepIgnored` => SKIPPD if previous step failed; IGNORED if e.g. previous had a assumption violation * Testcontainers currently includes a dependency to Junit4 which we don't want to have. Therefore Jnit4 is excluded in each testcontainers dependency * see also section "Limitations" in https://www.testcontainers.org/test_framework_integration/junit_5 * Looks like this will not go away soon: * testcontainers/testcontainers-java#1525 * testcontainers/testcontainers-java#87 * The required JUnit4 rule support is covered by a dependency to JUnit5 `junit-jupiter-migrationsupport` * Junit rule needs to be on the classpath, because `BrowserWebDriverContainer` extends `FailureDetectingExternalResource` which extends `org.junit.rules.TestRule`
* removes workaround in `SerenityStepExtension` as `net.thucydides.core.steps.StepInterceptor#executeTestStepMethod` now properly detects as assumption violation (and does not consider it an error as before). * steps after a step with assumption violation are now ignored (instead of skipped) * verified with JUnit4 that this is the desired behaviour. Before the behaviour was different, because a assumption violation was handled liked an error and in case of an error following steps are skipped. The workaround mentioned above was not able to fully correct this. * `net.thucydides.core.steps.BaseStepListener#stepIgnored` => SKIPPD if previous step failed; IGNORED if e.g. previous had a assumption violation * Testcontainers currently includes a dependency to Junit4 which we don't want to have. Therefore Jnit4 is excluded in each testcontainers dependency * see also section "Limitations" in https://www.testcontainers.org/test_framework_integration/junit_5 * Looks like this will not go away soon: * testcontainers/testcontainers-java#1525 * testcontainers/testcontainers-java#87 * The required JUnit4 rule support is covered by a dependency to JUnit5 `junit-jupiter-migrationsupport` * Junit rule needs to be on the classpath, because `BrowserWebDriverContainer` extends `FailureDetectingExternalResource` which extends `org.junit.rules.TestRule`
* removes workaround in `SerenityStepExtension` as `net.thucydides.core.steps.StepInterceptor#executeTestStepMethod` now properly detects as assumption violation (and does not consider it an error as before). * steps after a step with assumption violation are now ignored (instead of skipped) * verified with JUnit4 that this is the desired behaviour. Before the behaviour was different, because a assumption violation was handled liked an error and in case of an error following steps are skipped. The workaround mentioned above was not able to fully correct this. * `net.thucydides.core.steps.BaseStepListener#stepIgnored` => SKIPPD if previous step failed; IGNORED if e.g. previous had a assumption violation * Testcontainers currently includes a dependency to Junit4 which we don't want to have. Therefore Jnit4 is excluded in each testcontainers dependency * see also section "Limitations" in https://www.testcontainers.org/test_framework_integration/junit_5 * Looks like this will not go away soon: * testcontainers/testcontainers-java#1525 * testcontainers/testcontainers-java#87 * The required JUnit4 rule support is covered by a dependency to JUnit5 `junit-jupiter-migrationsupport` * Junit rule needs to be on the classpath, because `BrowserWebDriverContainer` extends `FailureDetectingExternalResource` which extends `org.junit.rules.TestRule`
@rnorth Was redirected here by #1525 - although this ticket focusses on better support for other test frameworks, I would love to see for it to be completely test framework agnostic. I was thinking of the use case where you run testcontainers as the dependency within your spring-boot app in development. I just do not want to bother with (re)starting containers when starting my app. The idea is is that starting
This actually already works - but having all junit Test classes inside the application in the IDE just makes things confusing. The maven profile is there to avoid having this dependency included in the final artifact (don't want this in production, right). Adding an exclusion block for junit also is not a solution - it fails with a "weird" compile time error [ERROR] /Users/slyoldfox/Code/file-manager-module-test/src/main/java/com/samples/filemanager/FileManagerTestApplication.java:[78,61] cannot access org.junit.rules.TestRule This is of course due to:
Ideally I see a wonderful use case for testcontainers (your should call it bootcontainers ;-)) - where it can be used outside test contexts to quickly boot containers from within the app. Think spring-boot - for testcontainers ... |
@bsideup thanks for the link and interesting read - but how does work around the junit dependency being pulled in? I assume you pulled in testcontainers as a Your final artifact would then have testcontainers (and all their transitive dependencies like junit) in it? I am trying to avoid having junit (and testcontainers) on the classpath in anything else than the "dev" profile. |
@slyoldfox as described in the article, the test application is in |
@bsideup thanks for the clarification! :-) While I understand the setup now - and for the sake of discussion, your setup might work but poses some possible issues if your TestApplication includes test dependencies that interfere in development. Since you are executing this in For me, your Further more this Anyway all this won't work until the JUnit classes are decoupled from testcontainers - or until you include junit in It would make it a powerful tool though - outside of testing. |
when you run
That's just another option how to do that. You're free to use any mechanism available in Spring Boot.
You're free to put it wherever you like. Just keep in mind that Testcontainers is a library for... well... testing, so there is no guarantee that it won't have test-focused dependencies. |
See #86 for background
The text was updated successfully, but these errors were encountered: