-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Create example for TemporaryFolder extension #4
Comments
We actually have implemented a version of this for our tests called TempDirectory which is used in XmlReportsWritingListenerTests. It uses the I think we should provide that as an example -- if that suits your needs? |
Perfect match! Thanks for the hint/link. Will you bundle some common "well-known JUnit 4 rules" into a ported "basic JUnit 5 extensions" package? |
What else besides |
Hm, only |
I don't think something like |
It depends on the functionality of the If you just want to time tests, that is already possible. Check out the example TimingExtension. Does that suit your needs? |
Ja, that's all I need. Thanks, again. But not having a collection of default/common extensions shipping along with JUnit 5, seems a bit strange. Feels like "everybody" will write it's own base extensions. Or did almost every feature provided by Rules move to |
Please note that the rules shipped with JUnit 4 were considered examples at first, too. Nevertheless, I think we should consider providing a few basic extensions (like @junit-team/junit-lambda What do you guys think? |
What candidates do we have?
Not sure if something like Watchman and ExternalRessource make sense. 2016-03-01 8:58 GMT+01:00 Marc Philipp notifications@github.com:
|
We should definitely provide extensions for common use cases (and not just as part of the The only questions are:
Let's discuss... |
Depending on the Number of specializations of org.junit.rules.ExternalResource out there |
This adapter would have to live in a new module with junit4 dependency, right? |
it would definitely need the junit4 dependency. |
Alternatively we could have an adapter but users have to change the import of their original resource rule. |
Providing some form of adapters is definitely worth investigating. I have heard questions from various users regarding how one would migrate from rules to extensions. Along these lines, another useful adapter would be one for the |
@mmerdes, feel free to do your work in conjunction with junit-team/junit5#169 (or create a new issue if you prefer). |
Well, if we had a general Statement-like execution extension point in place we could provide an implementation that supports rules (not |
@marcphilipp, I think we should avoid introducing a Statement-like execution model in JUnit 5 for reasons discussed elsewhere in greater detail. |
I limited my proposal to create an adaptor to ExternalResource subclasses (and similar cases) because they do not need access to the Statement abstraction. |
Please take a look at: I did an experiment to support JUnit4 ExternalResource subclasses like TemporaryFolder with a new Extension. What do you think of this approach? (nb: the implementation is still sketchy and there might be a better module for it as well) |
Cool! What I'd suggest is to NOT use the original JUnit4 An alternative approach could be to provide an adapter extension like: public class ExternalResourceAdapter<T extends ExternalResource>
implements BeforeEachExtensionPoint, AfterEachExtensionPoint, MethodParameterResolver {
T create(Object[] constructorParameters);
}
public class TemporaryFolderExtension extends ExternalResourceAdapter<TemporaryFolder> {
} Would be a bit more JUnit5-ish but require more effort from rule providers. Don't know if that's feasible, though. |
Are there any news on including the TemporaryFolder Extension Rule equivalent in junit5 somewhere as official public usable? That would be really great, because we have a lot of tests which depend on this and before we migrate them all, it would be nice to have an official equivalent to this. |
@Siedlerchr, we haven't talked about this in a while, so there's no update. However, now that you've brought it up again... @junit-team/junit-lambda, let's discuss this during the next team call. Tentatively slating for 5.1 M2 to put it on the immediate radar, but the implementation (if we decide to do it) would likely come in 5.2. |
Oops... just realized this is the "samples" repo. 😮 |
FYI: I created an issue to address this in JUnit Jupiter... |
Indeed, it would be great if there is a replacement of JUnit 4 TemporaryFolder within JUnit 5. Here, I've re-engineered lot of JUnit tests for following reasons: Well, I can write my own TemporaryFolder code like ten years (or more) ago. Since a Temporaryfolder rule is available with JUnit 4 this is no longer feasible. |
I have converted the old code presented above into something that works and is written in Kotlin, for anyone, like me, looking for this: /**
* Replacement for JUnit4 `@Rule TemporaryFolder`.
*/
class TempDirectory : AfterEachCallback, ParameterResolver {
override fun supportsParameter(parameterContext: ParameterContext, extensionContext: ExtensionContext): Boolean {
return parameterContext.parameter.getAnnotation(Root::class.java) != null &&
Path::class.java == parameterContext.parameter.type
}
override fun resolveParameter(parameterContext: ParameterContext, context: ExtensionContext): Any {
return getLocalStore(context).getOrComputeIfAbsent<String, Any>(KEY) { _ -> createTempDirectory(context) }
}
override fun afterEach(context: ExtensionContext) {
val tempDirectory = getLocalStore(context).get(KEY) as? Path
if (tempDirectory != null) {
delete(tempDirectory)
}
}
private fun getLocalStore(context: ExtensionContext): ExtensionContext.Store {
return context.getStore(localNamespace(context))
}
private fun localNamespace(context: ExtensionContext): ExtensionContext.Namespace {
return ExtensionContext.Namespace.create(TempDirectory::class.java, context)
}
private fun createTempDirectory(context: ExtensionContext): Path {
try {
return Files.createTempDirectory(context.displayName)
} catch (e: IOException) {
throw ParameterResolutionException("Could not create temp directory", e)
}
}
private fun delete(tempDirectory: Path) {
Files.walkFileTree(tempDirectory, object : SimpleFileVisitor<Path>() {
override fun visitFile(file: Path?, attrs: BasicFileAttributes?): FileVisitResult {
return deleteAndContinue(file)
}
override fun postVisitDirectory(dir: Path?, exc: IOException?): FileVisitResult {
return deleteAndContinue(dir)
}
private fun deleteAndContinue(path: Path?): FileVisitResult {
Files.delete(path)
return FileVisitResult.CONTINUE
}
})
}
companion object {
private const val KEY = "tempDirectory"
}
}
@Target(AnnotationTarget.VALUE_PARAMETER)
@Retention(AnnotationRetention.RUNTIME)
@MustBeDocumented
annotation class Root At least, it seems to work (compiles and tests run). If I've made a mistake, I'd be happy to be corrected! |
@autonomousapps Good news: I understand that @marcphilipp is introducing a Thus your Kotlin example should not be strictly needed very soon. :) |
Great! Good thing it only took me a few minutes to adapt from the earlier sample :) And I'm always happy to learn new things. |
In fact I think we should close this issue in favor of junit-pioneer/junit-pioneer#69. Thanks for the reminder! 🙂 |
It only took you (now: us) two years and a couple of month! 🥂 |
What would an implementation outline look like?
Usage:
Implementation ("copied" from JUnit 4, stripped ExternalResource dependency):
The text was updated successfully, but these errors were encountered: