Clone
 

marc philipp <marc@gradle.com> in Gradle

Remove workarounds for Vintage engine

The workaround was unnecessary since `vintageDynamicMethodName` always

returned `null` and we can then simply check the class name from the

ClassSource.

Remove workarounds for Vintage engine

The workaround was unnecessary since `vintageDynamicMethodName` always

returned `null` and we can then simply check the class name from the

ClassSource.

Remove workarounds for Vintage engine

The workaround was unnecessary since `vintageDynamicMethodName` always

returned `null` and we can then simply check the class name from the

ClassSource.

Remove workarounds for Vintage engine

The workaround was unnecessary since `vintageDynamicMethodName` always

returned `null` and we can then simply check the class name from the

ClassSource.

Remove workarounds for Vintage engine

The workaround was unnecessary since `vintageDynamicMethodName` always

returned `null` and we can then simply check the class name from the

ClassSource.

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.

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.

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.

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.

Update subprojects/docs/src/docs/userguide/java_testing.adoc

Co-Authored-By: Sterling Greene <big-guy@users.noreply.github.com>

Make Checkstyle happy

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.

Fix tests

Check only files on the classpath

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.

Fixes for lastest 2.0 snapshot

Upgrade to build-scan-plugin 2.4-rc-1

Upgrade to build-scans plugin 2.4-rc-1

Add spock-junit4

Add spock-junit4

Temporarily disable test

Temporarily disable test

Run tests on the JUnit Platform using Spock 2.0

Run tests on the JUnit Platform using Spock 2.0

Use HTTPS for links to Apache license in wrapper scripts

Using HTTP when HTTPS is available is generally discouraged. Moreover,

builds of projects using the io.spring.nohttp plugin in its default

configuration now fail.

Fix JUnit Jupiter related typos

- Fix broken links to junit.org and use HTTPS

- Use `java-library` type in corresponding section

Attempt to fix test on Windows

Remove exemplar config

so it isn’t automatically discovered by UserGuideSamplesIntegrationTest

Fix CodeNarc violations

Add test for keys without passwords