Unit or integration test resource file directory layout

What are common approaches to unit or integration test resource directory's nested layout? For example, if code, tests, resources are strucured like in a Java project

main/
  java/
    com/
      example/
        Class.java
test/
  java/
    com/
      example/
        ClassTest.java
  resources/

What are approachs to storing resource files for this test?

In an extremely simple case you could just store a file into e.g. test/resources/a.xml, but when you have multiple tests where each test has source and expected output files, this doesn't work. An example of a solution could be

test/
  resources/
    com/
      example/
        ClassTest/
          s开发者_开发百科rc/
            a.xml
            b.xml
          exp/
            a.xml
            b.xml

Are there any common approaches to structuring multiple resource files for multiple tests.

Honestly there are almost as many ways of doing things as there are developers. But realistically, think abou the next developer - yourself or someone else six months or two years from now. Will they be able to easily understand the relationships between the files and code. Will they be able to easily add new tests, maintain the old, etc. What conventions are likely to help?

Whichever layout you choose should reflect this consideration because even if the next developer is you, it's likely that you will have off loaded what you know now to do something else. So when you come back you don't want to be going - "WTF was I thinking?" :-) You just want to start working on it again.