Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Restore package prefix in case the test is run with JUnit 4.x as pointed out by @marcphilipp

    • -3
    • +6
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
Fix failing more tests

    • -3
    • +3
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
Adopt tests to new behavior

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -26
    • +1
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Adopt tests to new behavior

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -26
    • +1
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Adopt tests to new behavior

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -26
    • +1
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Revert "Fix edge case for class display names"

This reverts commit e04ef3476cd3927bb972a60e7184332d6e29876c.

  1. … 2 more files in changeset.
Revert "Fix edge case for class display names"

This reverts commit e04ef3476cd3927bb972a60e7184332d6e29876c.

  1. … 2 more files in changeset.
Revert "Fix edge case for class display names"

This reverts commit e04ef3476cd3927bb972a60e7184332d6e29876c.

  1. … 2 more files in changeset.
Fix edge case for class display names

Simply using the class display name in test logging does not work,

because JUnit platform returns only the simple class name from

TestIdentifier.getDisplayName(). This results in the fully qualified

package name being cut off for top level classes.

This change adds some logic that tried to find out whether the display

name has been explicitly se tor not. If so then the class display name

will we use. If not the fully qualified class name will be used for top

level classes and the simple class name will be used for inner classes.

There is still one corner case that is not supported with this solution:

A user could set the simple class name as display name in order to remove

the package name from the output. Since there is no way to tell whether

this was explicitly configured by the user or not by looking at the

TestIdentifier, there does not seem to be a way to support this.

  1. … 2 more files in changeset.
Fix edge case for class display names

Simply using the class display name in test logging does not work,

because JUnit platform returns only the simple class name from

TestIdentifier.getDisplayName(). This results in the fully qualified

package name being cut off for top level classes.

This change adds some logic that tried to find out whether the display

name has been explicitly se tor not. If so then the class display name

will we use. If not the fully qualified class name will be used for top

level classes and the simple class name will be used for inner classes.

There is still one corner case that is not supported with this solution:

A user could set the simple class name as display name in order to remove

the package name from the output. Since there is no way to tell whether

this was explicitly configured by the user or not by looking at the

TestIdentifier, there does not seem to be a way to support this.

  1. … 2 more files in changeset.
Fix edge case for class display names

Simply using the class display name in test logging does not work,

because JUnit platform returns only the simple class name from

TestIdentifier.getDisplayName(). This results in the fully qualified

package name being cut off for top level classes.

This change adds some logic that tried to find out whether the display

name has been explicitly se tor not. If so then the class display name

will we use. If not the fully qualified class name will be used for top

level classes and the simple class name will be used for inner classes.

There is still one corner case that is not supported with this solution:

A user could set the simple class name as display name in order to remove

the package name from the output. Since there is no way to tell whether

this was explicitly configured by the user or not by looking at the

TestIdentifier, there does not seem to be a way to support this.

  1. … 2 more files in changeset.
Add more test cases

Some tests are still failing, this need discussion on how to handle

class display names.

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -8
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Add more test cases

Some tests are still failing, this need discussion on how to handle

class display names.

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -8
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Add more test cases

Some tests are still failing, this need discussion on how to handle

class display names.

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -8
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -3
    • +6
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
    • -0
    • +101
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 3 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -3
    • +6
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
    • -0
    • +101
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 4 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -0
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 3 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -0
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 2 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -3
    • +6
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
    • -0
    • +101
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 3 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available. Furthermore

getDisplayName() and getClassDisplayName() are moved from

TestDescriptorInternal to TestDescriptor making them available in

beforeTest and afterTest callbacks.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -0
    • +67
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 3 more files in changeset.
Use display name in test logging

Test logging now logs the display name if it is available.

Fixes: #10983

Co-authored-by: Mark Nordhoff <mark.nordhoff@freenet.de>

    • -1
    • +1
    ./testing/fixture/AbstractJvmFailFastIntegrationSpec.groovy
    • -3
    • +6
    ./testing/junit/JUnitConsoleLoggingIntegrationTest.groovy
    • -0
    • +101
    ./testing/junitplatform/JUnitPlatformLoggingIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix executing Specs tests via JUnit Platform and Vintage engine

Prior to this commit, the JUnitPlatformTestExecutionListener parsed the

unique ID to determine the class and method name for TestIdentifiers

without children but with a ClassSource. This occurs when a Spock test

class uses `@Unroll` on all its test methods. However, other testing

frameworks such as Specs2 don't provide a unique ID that is parseable

which lead to the methodName being null which cause a failure during

serialization. The effect was that tests hung because the build VM

was waiting for the worker to finish the tests it started.

The Spock-specific workaround in our listener is now replaced with a

more robust one that always uses the methodName provided by the JUnit

Platform instead of parsing it.

    • -0
    • +71
    ./testing/junit/Specs2IntegrationTest.groovy
  1. … 1 more file in changeset.
Fix executing Specs tests via JUnit Platform and Vintage engine

Prior to this commit, the JUnitPlatformTestExecutionListener parsed the

unique ID to determine the class and method name for TestIdentifiers

without children but with a ClassSource. This occurs when a Spock test

class uses `@Unroll` on all its test methods. However, other testing

frameworks such as Specs2 don't provide a unique ID that is parseable

which lead to the methodName being null which cause a failure during

serialization. The effect was that tests hung because the build VM

was waiting for the worker to finish the tests it started.

The Spock-specific workaround in our listener is now replaced with a

more robust one that always uses the methodName provided by the JUnit

Platform instead of parsing it.

    • -0
    • +72
    ./testing/junit/Specs2IntegrationTest.groovy
  1. … 1 more file in changeset.
Fix executing Specs tests via JUnit Platform and Vintage engine

Prior to this commit, the JUnitPlatformTestExecutionListener parsed the

unique ID to determine the class and method name for TestIdentifiers

without children but with a ClassSource. This occurs when a Spock test

class uses `@Unroll` on all its test methods. However, other testing

frameworks such as Specs2 don't provide a unique ID that is parseable

which lead to the methodName being null which cause a failure during

serialization. The effect was that tests hung because the build VM

was waiting for the worker to finish the tests it started.

The Spock-specific workaround in our listener is now replaced with a

more robust one that always uses the methodName provided by the JUnit

Platform instead of parsing it.

    • -0
    • +69
    ./testing/junit/Specs2IntegrationTest.groovy
  1. … 1 more file in changeset.
Fix executing Specs tests via JUnit Platform and Vintage engine

Prior to this commit, the JUnitPlatformTestExecutionListener parsed the

unique ID to determine the class and method name for TestIdentifiers

without children but with a ClassSource. This occurs when a Spock test

class uses `@Unroll` on all its test methods. However, other testing

frameworks such as Specs2 don't provide a unique ID that is parseable

which lead to the methodName being null which cause a failure during

serialization. The effect was that tests hung because the build VM

was waiting for the worker to finish the tests it started.

The Spock-specific workaround in our listener is now replaced with a

more robust one that always uses the methodName provided by the JUnit

Platform instead of parsing it.

    • -0
    • +69
    ./testing/junit/Specs2IntegrationTest.groovy
  1. … 1 more file in changeset.
Give JUnit 4 precedence over JUnit Platform and TestNG

For backwards compatibility, JUnit 4 takes precendence over TestNG and

JUnit Platform since groovy-all ships with dependencies on both. In the

latter case, JUnit Platform is used if both junit-vintage-engine and

JUnit 4 are on the classpath.

    • -27
    • +55
    ./testing/TestFrameworkAutoDetectionIntegrationTest.groovy
  1. … 1 more file in changeset.
Autodetect TestFramework if none is configure explicitly

When the TestFramework of a Test task is not configured explicitly it

used to default to `useJUnit()`. Now, the task's classpath is inspected

for a junit-platform-engine.jar or testng.jar. If one of them is found,

the task uses the JUnit Platform or TestNG to execute tests,

respectively.

Since we have internal dependencies on the JUnit Platform and TestNG,

all Test tasks in our own build are configured to `useJUnit()` and

explicitly.

    • -0
    • +108
    ./testing/TestFrameworkAutoDetectionIntegrationTest.groovy
    • -0
    • +18
    ./testing/TestTaskIntegrationTest.groovy
  1. … 11 more files in changeset.
Fix for change to int tests.

    • -5
    • +1
    ./testing/TestReportIntegrationTest.groovy
Fix for change to int tests.

    • -5
    • +1
    ./testing/TestReportIntegrationTest.groovy
Fix for change to int tests.

    • -8
    • +2
    ./testing/TestReportIntegrationTest.groovy