تشغيل الاختبارات باستخدام Maven

Written Explanation

The command and its summary

Run, from the folder that contains pom.xml:

mvn test

Maven compiles the main code and the tests, then runs the tests with a plugin called Surefire (lesson 4 showed it as surefire:test). The part of the output you care about, from the example project (real output):

[INFO]  T E S T S
[INFO] Running com.example.GreeterTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.095 s -- in com.example.GreeterTest
[INFO] Results:
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

Each test class gets one line; the final Tests run: line is the total. The line to look for is BUILD SUCCESS (all green) or BUILD FAILURE. Reports are also written to target/surefire-reports/, one text file and one XML file per test class.

Which classes are tests

You never list your test classes. Surefire scans the compiled test classes and runs those whose names follow a convention. By default these patterns are Test*, *Test, *Tests, and *TestCase (for example GreeterTest, TestGreeter). A test class with some other name is silently ignored. I checked this: a class named Checks containing a failing @Test method was not run, and mvn test ended with BUILD SUCCESS and Tests run: 2. After renaming it to ChecksTest, it ran:

[INFO] Running com.example.ChecksTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0 ... <<< FAILURE! -- in com.example.ChecksTest
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0
[INFO] BUILD FAILURE

Rule of thumb: end every test class name with Test.

Also, tests must be in src/test/java. Maven compiles and scans only that tree for tests. Surefire also needs the JUnit libraries: you gave them to Maven with the test-scoped junit-jupiter dependency from lesson 3. (The Surefire documentation says it selects the JUnit Jupiter engine when the JUnit Platform libraries are on the class path.)

Failure versus error

Maven reports two kinds of red:

• A failure means an assertion was false: the test ran, and the result was not the expected one.
• An error means something unexpected happened before the assertion could decide: an exception such as ArithmeticException escaped the test.

Real output of each, with the details trimmed:

[ERROR] ChecksTest.wouldFail:9 expected: <1> but was: <2>
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0

[ERROR] ChecksTest.crashes:9 Arithmetic / by zero
[ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0

In both cases the line after the dot names the test method and the number after the colon is the line in the test file. You learned to read this style in lesson BEG-045-L06; it is the same message with Maven's prefix.

The test reports

Besides the console, Surefire saves its results in target/surefire-reports/. For the example project that folder holds com.example.GreeterTest.txt and TEST-com.example.GreeterTest.xml. The text file is a small summary, for example (real content):

Test set: com.example.GreeterTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.095 s -- in com.example.GreeterTest

The XML file holds the same results in a format that tools understand, such as build servers that draw a test dashboard. For you, the text file is useful when the console output scrolled away: open it instead of running the build again. These files are part of target/, so they are deleted by mvn clean and never committed. A report from an earlier run can also linger if you do not clean; in my experiment, reports from a previous run were still in the folder after I moved the tests away, another reason to read the console total instead of trusting old files.

A failing test fails the build

Both a failure and an error end with BUILD FAILURE. Because tests run before packaging (lesson 4), no JAR is built after a red run. A teammate or a server that runs mvn test therefore learns the same thing you do, without anyone having to inspect the report.

Running only some tests

While fixing one test you do not want to wait for all of them. The -Dtest option selects tests (real output):

mvn -Dtest=GreeterTest test             # one class
mvn -Dtest=GreeterTest#greetsEmptyName test   # one method

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.114 s -- in com.example.GreeterTest

This is for your own speed while working. Before committing, always run the whole suite with plain mvn test.

The silent case: no tests ran

In an experiment I moved the test file out of src/test/java into a folder named src/test/mytests. mvn test finished with BUILD SUCCESS, and printed no Tests run: line at all. Nothing was wrong from Maven's point of view: there simply were no tests to run. That is the dangerous kind of success. Make it a habit to read the Tests run: total, and check that it matches the number of tests you expect.

Where the analogy stops

A cook knows when a dish tastes wrong. Surefire only knows what your tests check: a green build means "the checks you wrote passed", not "the program is correct". That is why BEG-045 taught you to choose tests carefully, with boundaries and exceptional cases.