`@TempDir` with `File` annotated elements should fail fast if temp directory file system is not default

[scordio]

TempDirFactory implementations based on non-default file systems like jimfs and memoryfilesystem cannot work with @TempDir annotated elements of type File.

See also the Path::toFile Javadoc:

Throws:
UnsupportedOperationException - if this Path is not associated with the default provider

Right now, a test like the example in the user guide, but with tempDir of type File:

@Test
void test(@TempDir(factory = JimfsTempDirFactory.class) File tempDir) {
    // perform test
}

static class JimfsTempDirFactory implements TempDirFactory {

    private final FileSystem fileSystem = Jimfs.newFileSystem(Configuration.unix());

    @Override
    public Path createTempDirectory(AnnotatedElementContext elementContext, ExtensionContext extensionContext) throws IOException {
        return Files.createTempDirectory(fileSystem.getPath("/"), "junit-");
    }

    @Override
    public void close() throws IOException {
        fileSystem.close();
    }

}

fails with:

org.junit.jupiter.api.extension.ParameterResolutionException: Failed to resolve parameter [java.io.File arg0] in method [void io.github.scordio.jimfs.junit.jupiter.Tests.test(java.io.File)]

	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
Caused by: java.lang.UnsupportedOperationException
	at com.google.common.jimfs.JimfsPath.toFile(JimfsPath.java:386)
	... 2 more

I would like to improve the user experience, clearly stating that File annotated elements are not supported.

As of today, the factory doesn't have easy access to the type of the annotated element.

In my extension for Jimfs, I've implemented a workaround:

https://github.com/scordio/jimfs-junit-jupiter/blob/ac6f085a89368823e7f515f335eb44f21d981447/src/main/java/io/github/scordio/jimfs/junit/jupiter/JimfsTempDirFactory.java#L86-L107

Deliverables

I see two possible directions:

1. JUnit owns the error handling and asks the factory if File annotated elements are supported
   • This could be done with a new default method in TempDirFactory, e.g., boolean supportsFile().
2. The error handling happens in the factory
   • AnnotatedElementContext should expose the element type somehow so that the factory can build up the error handling around it without having to cast the result of getAnnotatedElement(). For example, a new Class<?> getAnnotatedElementType() method could be added to AnnotatedElementContext.

My preference goes to option 1 to reduce duplication in each TempDirFactory implementation.

I'm happy to contribute once a solution is agreed.

---

Relates to:

• scordio/jimfs-junit-jupiter@99d946e
• JUnit5 test fails with: memory file system does not support #toFile() marschall/memoryfilesystem-junit-provider#2

CC @marschall

[marcphilipp]

Thanks for reporting! I'm wondering if we should instead introduce a List<Class<?>> getSupportedTypes() method in case we want to support some hypothetical other type in the future. Thoughts?

[scordio]

My first feeling about List<Class<?>> getSupportedTypes() was that it leaves too much space to the factory, but that's probably not a problem since JUnit would only do contains checks on the returned list/set based on the target type.

Do you imagine to always return Arrays.asList(Path.class, File.class) (or equivalent) in the default method, and let it evolve whenever JUnit adds more supported types?

One more alternative could be something similar to canSupport(Class<?>, Class<?>) of the Spring ConversionService, e.g., supports(Class<?>). In this case, the default method would just return true.

[marcphilipp]

I'm wondering if we could check the file system of the returned Path and throw an exception when it's not the default file system and trying to inject a File. Can you imagine a case where that wouldn't be sufficient?

[scordio]

Can you imagine a case where that wouldn't be sufficient?

No, not really – this approach seems sensible to me! Plus, it's the easiest to adjust if new corner cases arise.

I can start with the implementation unless you see something else that needs to be defined.

[marcphilipp]

No, I think we're good to go! 👍