CODEWITHSUNDEEP
javamaven
Matt Davis
Matt Davis

Reputation: 470

Point of maven test directory

Learning Java EE at uni and they aren't uploading the lectures so i'm stuck learning from the textbook (doing distance ed.)

I'm struggling to understand the point of the Maven Test directory. I understand that you have to have the same files as in your main directory (a test class, a persistence.xml file etc). But i can't seem to find any information as to the point of the directory. Does it relate directly to the code in the /src/main/ directory? Or does it run seperately? Does it permanently persist to the derby database or is it just meant to test code runs?

This doesn't relate to a uni assignment i'm just having trouble understanding.

Thanks!

Upvotes: 0

Views: 171

Answers (2)

Pokechu22
Pokechu22

Reputation: 5046

Code in the /src/test/ directory can interact with code in /src/main/ (However code in /src/main/ cannot access code in /src/test/). The purpose of the /src/test/ directory is to contain code related to Unit Testing. Maven runs any unit tests in this directory automatically. It is not included in the actual jar.

Upvotes: 2

michael
michael

Reputation: 9759

All the code in a medium-to-large sized development project has to be organized in such a way that you can use existing tools that "just work", without a lot of manual configuration -- tools like maven, gradle, netbeans (and all their plugins). This is true for small projects, too, if you're already familiar with the process & already using the tools (almost all small projects eventually become medium-sized projects, and all medium-sized projects become...) This is called "convention over configuration". It saves time in the long run, but requires more up-front time to set up your project (and may seem useless at first).

For maven (and gradle), we put code in src/main for the application, and tests in src/test. Dependencies are important to understand: there can only be one-way dependencies between module A and module B, and likewise for the tests & application code. So, src/main does not use or depend on or use code in src/test. But of course src/test uses (and validates) the code in src/main. Likewise for submodules (if your project uses them): if code in {module_b}/src/main can see {module_a}/src/main, then the reverse can't be true. But test code is different: {module_b}/src/test won't typically see or use code in {module_a}/src/test (not without effort): so, put all re-usable code -- even test code -- in its own module (e.g., {module_test_a}/src/main, and declare the dependencies explicitly.

Then, with a project properly organized, you can run automated unit tests, define test suites for integration tests, create "packaging" logic to assemble your application, etc., etc. Also when someone new to your project, starts looking at the code, they will know where to go to start looking at the tests vs. the "real" code. (And likely use the tests as an example of how to actually use the code.)

Upvotes: 3

Related Questions