Software Engineering
Should test resource files be stored inside the Java class source directories?
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?
Solution
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.