jqassistant/jqa-junit-plugin

jQAssistant Java Plugin

This is the JUnit Plugin of jQAssistant. It enables jQAssistant to scan and to analyze JUnit related artifacts like:

• JUnit 5 test cases

• JUnit 4 test cases

• JUnit 3 test cases

For more information on jQAssistant see https://jqassistant.org.

jqa-junit-plugin's Issues

Create label for inner test classes

Feature Description

For a particular project we have a rule in place which disallows direct dependencies on certain types, except from tests.

This works nicely, except where there are inner classes inside Test classes, in which case a false positive warning of an illegal dependency is reported.

A minimal example is this class:

public class ExampleTest {
    @Test
    public void testBasics() {
        new InnerExample();
    }

    class InnerExample {
        public InnerExample() {
            new DontDependOnMeOutsideOfTests();
        }
    }

    class DontDependOnMeOutsideOfTests { }
}

With the corresponding constraint

<constraint id="example:nodep-on-sometype">
    <cypher><![CDATA[
        MATCH (source:Type)-[r:DEPENDS_ON]->(target:Type {name:"ExampleTest$DontDependOnMeOutsideOfTests"})
        WHERE NOT source:Test
        RETURN source as OffendingType, target as DependsOnType
    ]]></cypher>
</constraint>

This reports a constraint violation, even though it's called clearly from within a test. I will open a PR in a minute.

Definition of Done for the Implementers

Remove this hint: these checkboxes can be checked like this: [x]

• We got a final feedback from the reporting user (if applicable)
• Unittests have been written (if applicable)
• Integration tests have been written (if applicable)
• Test coverage is the same or even better then before (if applicable)
• Documentation has been written (if applicable)
• Added a note on the new feature to the release notes (if applicable)

Label Classes Annotated with "RunWith" as Test

Feature Description

We have some test cases that use the Enclosed test runner. These classes are not labeled with Test. It might be helpful to have a concept to label all classes that use the @RunWith annotation as Test.

I will open a PR in a minute to illustrate the issue.

Definition of Done for the Implementers

• Unittests have been written
• Integration tests have been written
• Documentation has been written
• Added a note on the new feature to the release notes

metric groups

According to the XSD and the files junit4.xml and metric.xml there is also a metricGroup and metric element available. What are these for and what is the difference to the metric concepts available in the metric.xml? The documentation doesn't describe these elements.

Add support for the Open Test Report format

Feature Description

I, as user of jQAssistant, who is using a JUnit version sincee 5.9,
would like to be able to query also test reports written in the Open Test Report format,
to that I can also test report information written in the new format.

How to Test

To test this feature, it should be enough to import some example reports in the Open Test Report format.

Definition of Done for the Implementers

• Unittests have been written
• Integration tests have been written
• Test coverage is the same or even better then before
• Documentation has been written
• Added a note on the new feature to the release notes

Complete the support of repeated and parameterized tests for scanned XML test reports

We introduce support of Junit 5 via #2. During the implementation of the Junit 5 support it turned out that we are unable to create the relations DEFINED_BY and IMPLEMENTED_BY between the test cases reported in the XML report and the Java methods for repeated and annotated test. The cause is a bug in Junit 5, already reported as junit-team/junit5#1182.

If junit-team/junit5#1182 will be fixed we should update or adapt the Junit plugin of jQAssistant.

Related issues: junit-team/junit5#1182 and #2.

Unify the Asciidoctor markup

Go over all documents of the documentation and unify the Asciidoctor markup.

Assertions should be migrated to an abstract concept

Assertions usually come with a test framework like JUnit4 or 5 but others may provide their own assertions, e.g. AssertJ, Hamcrest or Mockito. Therefore any constraints depending on assertions (e.g. junit:TestMethodWithoutAssertion) should require an abstract concept which can be provided by plugins for different frameworks.

junit:AssertionMustProvideMessage is jUnit4-specific

Currently, the constraint junit:AssertionMustProvideMessage is part of the junit:Default although, it's implementation is jUnit4-specific. This is due to following two facts:

• requires only the concept junit4:AssertMethod
• matches only assert methods whose first parameter is a string

When using jUnit4 and jUnit5 at the same time (not saying that this is okay), jUnit 5 Assert methods will be always reported by this constraint becuase the message will be the last parameter.

There are three options:

1. move the constraint to the jUni4 group and add a spearate assertions to jUnit 5
2. update the constraint so that it filters for :JUni4:Assert
3. extend the constraint so that it supports both version.

My preference would be option 1. Any opinions?

jUnit 5 - Not all assert-Methods supported

The junit5:AssertMethod concept does not support all assert methods from jUnit 5, thus leading to false positives in the constraint junit:TestMethodWithoutAssertion constraint. This is due to the fact that assert methods are considered as such if the have the following signature void assert.*

Following methods will not be matched:

• java.lang.Throwable assertThrows
• T assertTimeout*

Drop support of Junit 3

JUnit 3 is quite old and after adding support for Junit 5 we should drop the support of Junit 3.

fail() not recognized as assertion

The fail()-Method of JUnit 4/5 is currently not being recognized as assertion, therefore false-positives are reported. For implementation #23 should be considered as a pre-requisite.

Use Github Actions to provide a simple CI/CD Buildchain

As core developer of jQAssistant, I want this project to be build on various plattforms with different JDK versions on each commit, so that I know if the change done my the commit does not break the build and the software is fully functional.

The following acceptance criterias must be met:

• mvn -DskipTests -Djqassistant.skip clean install must pass
• mvn -Djqassistant.skip clean install must pass
• mvn -P IT clean install must pass
• mvn -DskipTests -Djqassistant.skip=false clean install must pass

Migrate the Plugin Documentation of the JUnit Plugin to the new Reference Manual

Task Description

Migrate the existing documentation of the JUnit Plugin to the new reference manul.

Definition of Done for the Implementers

• The reference manual contains the same information as the old user manual
• The section on the JUnit Plugin in the old user manual points to the section for the plugin in the reference manual

Support JUnit 5

Hi,
are there any plans for supporting JUnit 5 in the next Version?