-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Framework-agnostic container & test lifecycle #702
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
package org.testcontainers.lifecycle; | ||
|
||
public interface Startable extends AutoCloseable { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why to we need this interface in this PR? It seems it's not used anyhwere (besides being implemented). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it defines a unified set of methods for both |
||
|
||
void start(); | ||
|
||
void stop(); | ||
|
||
@Override | ||
default void close() { | ||
stop(); | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
package org.testcontainers.lifecycle; | ||
|
||
import java.util.Optional; | ||
|
||
public interface TestDescription { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if we need all methods as the public interface. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What would you suggest? :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it makes sense to not have Or if we want to make it convenient, we could maybe have the default implementation here?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
But we have this use case at least in one place.
I don't think this is a good default implementation to be honest, I would rather keep it explicit and let framework adapters think about it, what's the best way to provide a FS friendly name of the test There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about omitting the default implementation completely then? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fine by me :) |
||
|
||
String getTestId(); | ||
|
||
default String getDisplayName() { | ||
return getTestId(); | ||
} | ||
|
||
default Optional<String[]> getNameParts() { | ||
return Optional.empty(); | ||
} | ||
|
||
default Optional<String> getFilesystemFriendlyName() { | ||
return Optional.empty(); | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
package org.testcontainers.lifecycle; | ||
|
||
import java.util.Optional; | ||
|
||
public interface TestLifecycleAware { | ||
|
||
default void beforeTestBlock(TestDescription description) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just in case if some Test frameworks define There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I would prefer removing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok, I summon @rnorth as a tiebreaker 😄 |
||
|
||
} | ||
|
||
default void afterTestBlock(TestDescription description, Optional<Throwable> throwable) { | ||
|
||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see it's just copied from the old implementation, but does this acutally happen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, to give you a bit of history here:
When I was implementing https://github.com/testcontainers/testcontainers-java/pull/106/files, we wanted to keep the backward compatibility as much as possible, and one of such is Logger based on image's name :)