Should test resource files be stored inside the Java class source directories?

Question

In a TDD (Test-Driven Development)-based Java project built by maven, lots of classes needs to be tested with text-based input files such as .csv. At the beginning, I put them into the src/test/resources directory. But along with the increase of the amount of test input .csv files, to know which input files used for which classes has become more and more difficult and messy.

A senior Javascript developer suggested to put the test files directly into the corresponding Java package probably on base of the unit test practice in Javascript. For instance, there is a class in src/main/java/com/AutoRobot.java, correspondingly there is a test class in src/test/java/com/AutoRobotTest.java and the test input csv file is also in the src/test/java/com directory.

Question: are there disadvantages to put the text-based files into the Java package, esp. when many text files are stored in the Java class package? Is it a good practice to do so? If not are there any similar alternative solutions?

• Stack Exchange Broke The Law: tangent: I hate how certain build systems force you to put source files and resource files in different folders from each other.
• Stack Exchange Broke The Law: What do you think is the advantage of not putting them in the package?
• Rui: advantage of not putting them in the package: resource files are different from source files after all, so store them differenty woud make the project structure clean. This is what comes into my mind
• Stack Exchange Broke The Law: What does "make the project structure clean" mean?
• Rui: source files are in source directory, resource files are in resource directory. But isn't it weird that you come to ask me? I write questions here to ask people

Answer 1

Disadvantages are disadvantages only if you consider them as such. That said, I can think of some.

• You will be ignoring Maven's Project folder structure, which has become (after many years) a defacto standard. That can be controversial among developers. Old school and dogmatic ones overall, because they will expect things to be where "they should be".

• It can be problematic if you have automatisms relying on Maven's project structures.

• Some Maven plugins might become useless if they look for resources only in those folders configured by Maven. I know Maven and plugins are usually very configurable but, why would you make an overcomplicated Pom file?

In my opinion, not knowing what file is used in what test means a lack of consistency. You are not being methodical enough.

Maybe, you could simply agree (with your coworkers) on some guidelines or rules of thumb when tests involve resources. These rules will give a certain sense of order. Much better than leaving things happens in the wild.

Resource file arrangement can be done the same way we arrange the source code.

• Directory hierarchy. For example, src/test/resources/a/b/c/file.csv. Folders and subfolders can mimic source code packages of the testing code, which eases access to the file since once in runtime both converge in the same folders (see /target folder after the build).

• In the same folder, but with meaningful names

src/test/resources/file.csv
vs
src/test/resources/inputs/uc01-useCaseName.csv

• Both

src/test/resources/a/b/c/uc01-useCaseName.csv

I don't recommend naming resources as test classes or methods (conventions over names), because classes and methods change over time but nobody cares about maintaining the CSV files. I find that naming the file with what makes it different gives more valuable information to the developer. Given that you can have many, you will want to know the difference between each other quickly without inspecting the content of each file. The name could highlight that.

Answer 2

There are no disadvantages other than a little bit more configuration in maven maybe.

If a test file is specifically for a given test, then yes, just put it right beside it. It makes sense.

I actually put production resource files that are specific to a class or package into the src/main/java structure directly too.

This sense of "cleanliness" that sort-of forces us to separate things that otherwise clearly belong together are misguided.

• Rui: how many resource files have you put into src/main/java? If so what is the sense to have the src/resources directory?
• Robert Bräutigam: Lots of times you have global resources. Images, default settings, i18n files, etc. I don't mind keeping those in the global src/main/resources/ hierarchy. I've put lots of things in src/main/java too though. I remember a wicket-based project, where I put the html, js, even images with the java source where the component / page was actually located. Was much easier that way.

Answer 3

Question: are there disadvantages to put the text-based files into the Java package, esp. when many text files are stored in the Java class package?

It's trade offs all the way down.

The motivation for accepting the constraints of the standard layout is that general-purpose plugins just work.

Here, src/main/resources is the default value of the project.build.resources property, which in turn means that the they will be filtered and copied to project.build.outputDirectory during the process-resources lifecycle phase. See, for example, Mincong Huang's description of the resources:resources goal.

In other words, the "out-of-the-box" behavior of the copy from src/main/resources is a little bit different from the copy from src/main/java.

---

My litmus test is this: are you willing to do the work to justify and document your deviation from orthodoxy? I would reject a PR that had resource files under the "wrong" directory, but I would accept that same PR if it also included a record of research done into the trade offs that were considered.

Answer 4

There is no reason to put test files in the /src/main/Java/hierarchy. They can go into ../src/test/resources/com/mycompany/myproject/myclass directory. That way they will be available to your tests but will not be built into your output artifacts.