unbroken-dome / gradle-testsets-plugin Goto Github PK

View Code? Open in Web Editor NEW

231.0 231.0 49.0 605 KB

A plugin for the Gradle build system that allows specifying test sets (like integration or acceptance tests).

License: MIT License

Kotlin 100.00%

gradle gradle-plugin integrationtest test testsets-plugin

gradle-testsets-plugin's People

Contributors

Stargazers

Watchers

gradle-testsets-plugin's Issues

java.lang.NoSuchMethodError with version 2.0.3

I get a java.lang.NoSuchMethodError when I use version 2.0.3. With version 1.5.2 it works.
Using gradle 5.0 or 5.1

My test (in a testset 'functionalTest') uses a function in a package (i.e. not in a class; to create a common test object) like this:

@Test
fun `test insert into db`() {
    assertTimeout(Duration.ofSeconds(7L)) {
        insertObjectIntoDb(aTestObject())
        ...
    }
}

where aTestObject is defined in another kotlin file (also in the same testset):

package com.xyz.company.databasetest

import ...

internal fun aTestObject(version: Long = 1L): TestObject {
    return TestObject(
        id = "id",
        version = version
    )
}

when I run the functionalTests on command line the test fails with a NoSuchMethodError saying that aTestObject method cannot be found.
The error also occurs when I put the argument explicitly in the test (ignoring the default argument in aTestObject method)

    java.lang.NoSuchMethodError: com.xyz.company....TestObjectsKt.aTestObject(J)Lcom/xyz/company/.../TestObject;
        at com.....TestObjectTest$test insert into db$1.execute(TestObjectTest.kt:63)
        at org.junit.jupiter.api.AssertTimeout.lambda$assertTimeout$0(AssertTimeout.java:49)
        at org.junit.jupiter.api.AssertTimeout.assertTimeout(AssertTimeout.java:78)
        at org.junit.jupiter.api.AssertTimeout.assertTimeout(AssertTimeout.java:66)
        at org.junit.jupiter.api.AssertTimeout.assertTimeout(AssertTimeout.java:48)
        at org.junit.jupiter.api.AssertTimeout.assertTimeout(AssertTimeout.java:44)

Strangely the test runs in IntelliJ.

Maybe the error occurs, because the test uses Junit5 "assertTimeout"?

Have to compile whole project to run single integration test method in IntelliJ

There's an odd disconnect between the Gradle TestSets plugin and IntelliJ: I can execute the whole integration test suite in IntelliJ easily, but I can't right-click and run/debug an individual integration test method, unless I manually recompile the whole project in IntelliJ.

Artifact configuration should include the test's runtime dependencies

When creating an artifact for a test set, the artifact configuration should extend from the test set's runtime configuration. This way, other projects will get the testRuntime dependencies transitively by depending on the test artifact.

Example: in project A

testSets {
    myTest { createArtifact = true }
}

dependencies {
    myTestCompile 'junit:junit:4.12'
}

in project B

dependencies {
    // this should transitively include the 'junit:junit:4.12' dependency
    testCompile project(path: ':A', configuration: 'myTest')
}

TestLibrary and createLibrary not found

I'm trying the documented TestLibrary feature, and Gradle is not finding that class, nor is the createLibrary method found; the suggested import statement is rejected as well. Output from Gradle is:

> class org.unbrokendome.gradle.plugins.testsets.dsl.DefaultTestSet_Decorated cannot be cast to class org.unbrokendome.gradle.plugins.testsets.dsl.TestLibrary (org.unbrokendome.gradle.plugins.testsets.dsl.DefaultTestSet_Decorated and org.unbrokendome.gradle.plugins.testsets.dsl.TestLibrary are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @5c8fd451)

IntelliJ highlights "TestLibrary" in import org.unbrokendome.gradle.plugins.testsets.dsl.TestLibrary in red (not found).

I'm using Java 11, Gradle 5.1, and test-sets 2.0.3.

Gradle 5.1: Internal API constructor has been deprecated

After updating Gradle to 5.1, I see the following warning:

Internal API constructor DefaultPolymorphicDomainObjectContainer(Class<T>, Instantiator) has been deprecated. This is scheduled to be removed in Gradle 6.0.
	at build_ef15adx27mysqc8slxotplm0m$_run_closure5.doCall(C:\path\project\build.gradle:72)
	(Run with --stacktrace to get the full stack trace of this deprecation warning.)

Line 72 of "build.gradle" is: apply plugin: 'org.unbroken-dome.test-sets'

When I run with --stacktrace as instructed, I get the following:

Internal API constructor DefaultPolymorphicDomainObjectContainer(Class<T>, Instantiator) has been deprecated. This is scheduled to be removed in Gradle 6.0.
	at org.gradle.api.internal.DefaultPolymorphicDomainObjectContainer.<init>(DefaultPolymorphicDomainObjectContainer.java:42)
	at org.unbrokendome.gradle.plugins.testsets.dsl.DefaultTestSetContainer.<init>(TestSetContainer.kt:68)
	at org.unbrokendome.gradle.plugins.testsets.dsl.DefaultTestSetContainer_Decorated.<init>(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.gradle.api.internal.DependencyInjectingInstantiator.newInstance(DependencyInjectingInstantiator.java:63)
	at org.gradle.api.internal.model.DefaultObjectFactory.newInstance(DefaultObjectFactory.java:72)
	at org.unbrokendome.gradle.plugins.testsets.dsl.TestSetContainerKt.testSetContainer(TestSetContainer.kt:149)
	at org.unbrokendome.gradle.plugins.testsets.TestSetsPlugin.apply(TestSetsPlugin.kt:40)
	at org.unbrokendome.gradle.plugins.testsets.TestSetsPlugin.apply(TestSetsPlugin.kt:31)
	at org.gradle.api.internal.plugins.ImperativeOnlyPluginTarget.applyImperative(ImperativeOnlyPluginTarget.java:42)
	at org.gradle.api.internal.plugins.RuleBasedPluginTarget.applyImperative(RuleBasedPluginTarget.java:50)
	at org.gradle.api.internal.plugins.DefaultPluginManager.addPlugin(DefaultPluginManager.java:177)
	at org.gradle.api.internal.plugins.DefaultPluginManager.access$300(DefaultPluginManager.java:51)
	at org.gradle.api.internal.plugins.DefaultPluginManager$AddPluginBuildOperation.run(DefaultPluginManager.java:267)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.plugins.DefaultPluginManager$2.execute(DefaultPluginManager.java:155)
	at org.gradle.api.internal.plugins.DefaultPluginManager$2.execute(DefaultPluginManager.java:152)
	at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.apply(DefaultUserCodeApplicationContext.java:48)
	at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:152)
	at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:133)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:120)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:38)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:86)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:143)
	at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
	at build_ef15adx27mysqc8slxotplm0m$_run_closure5.doCall(C:\path\project\build.gradle:72)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
	at groovy.lang.Closure.call(Closure.java:411)
	at groovy.lang.Closure.call(Closure.java:427)
	at org.gradle.util.ClosureBackedAction.execute(ClosureBackedAction.java:70)
	at org.gradle.util.ConfigureUtil.configureTarget(ConfigureUtil.java:154)
	at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:105)
	at org.gradle.util.ConfigureUtil$WrappedConfigureAction.execute(ConfigureUtil.java:166)
	at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:41)
	at org.gradle.internal.Actions.with(Actions.java:245)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator$3.run(BuildOperationCrossProjectConfigurator.java:90)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.runProjectConfigureAction(BuildOperationCrossProjectConfigurator.java:87)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.access$500(BuildOperationCrossProjectConfigurator.java:32)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator$2.run(BuildOperationCrossProjectConfigurator.java:81)
	at org.gradle.internal.Factories$1.create(Factories.java:25)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:200)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:186)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.runProjectConfigureActionWithMutationLock(BuildOperationCrossProjectConfigurator.java:78)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.access$400(BuildOperationCrossProjectConfigurator.java:32)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator$1.doRunProjectConfigure(BuildOperationCrossProjectConfigurator.java:69)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator$BlockConfigureBuildOperation.run(BuildOperationCrossProjectConfigurator.java:130)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.runBlockConfigureAction(BuildOperationCrossProjectConfigurator.java:65)
	at org.gradle.api.internal.project.BuildOperationCrossProjectConfigurator.subprojects(BuildOperationCrossProjectConfigurator.java:49)
	at org.gradle.api.internal.project.DefaultProject.subprojects(DefaultProject.java:1145)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
	at org.gradle.groovy.scripts.BasicScript$ScriptDynamicObject.tryInvokeMethod(BasicScript.java:133)
	at org.gradle.groovy.scripts.BasicScript.invokeMethod(BasicScript.java:82)
	at build_ef15adx27mysqc8slxotplm0m.run(C:\path\project\build.gradle:52)
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:90)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl$2.run(DefaultScriptPluginFactory.java:206)
	at org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:77)
	at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:211)
	at org.gradle.configuration.BuildOperationScriptPlugin$1$1.run(BuildOperationScriptPlugin.java:69)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.configuration.BuildOperationScriptPlugin$1.execute(BuildOperationScriptPlugin.java:66)
	at org.gradle.configuration.BuildOperationScriptPlugin$1.execute(BuildOperationScriptPlugin.java:63)
	at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.apply(DefaultUserCodeApplicationContext.java:48)
	at org.gradle.configuration.BuildOperationScriptPlugin.apply(BuildOperationScriptPlugin.java:63)
	at org.gradle.configuration.project.BuildScriptProcessor$1.run(BuildScriptProcessor.java:44)
	at org.gradle.internal.Factories$1.create(Factories.java:25)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:200)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:186)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:41)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:26)
	at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject$1.run(LifecycleProjectEvaluator.java:106)
	at org.gradle.internal.Factories$1.create(Factories.java:25)
	at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:183)
	at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withProjectLock(DefaultProjectStateRegistry.java:226)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:220)
	at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.withMutableState(DefaultProjectStateRegistry.java:186)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$EvaluateProject.run(LifecycleProjectEvaluator.java:95)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:67)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:693)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:141)
	at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
	at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:60)
	at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:41)
	at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuild.run(DefaultGradleLauncher.java:302)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.initialization.DefaultGradleLauncher.configureBuild(DefaultGradleLauncher.java:210)
	at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:151)
	at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:134)
	at org.gradle.internal.invocation.GradleBuildController$1.execute(GradleBuildController.java:58)
	at org.gradle.internal.invocation.GradleBuildController$1.execute(GradleBuildController.java:55)
	at org.gradle.internal.invocation.GradleBuildController$3.create(GradleBuildController.java:82)
	at org.gradle.internal.invocation.GradleBuildController$3.create(GradleBuildController.java:75)
	at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:183)
	at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
	at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:75)
	at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:55)
	at org.gradle.tooling.internal.provider.runner.BuildModelActionRunner.run(BuildModelActionRunner.java:54)
	at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
	at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
	at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:58)
	at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
	at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:39)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:49)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:44)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:315)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:305)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:101)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
	at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:44)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:49)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:46)
	at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:78)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:46)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:31)
	at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:42)
	at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:28)
	at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:78)
	at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:52)
	at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:59)
	at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:36)
	at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:68)
	at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:38)
	at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:37)
	at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:26)
	at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:43)
	at org.gradle.tooling.internal.provider.ParallelismConfigurationBuildActionExecuter.execute(ParallelismConfigurationBuildActionExecuter.java:29)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:60)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:55)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:41)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:48)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:32)
	at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
	at org.gradle.util.Swapper.swap(Swapper.java:38)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:62)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:81)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
	at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:295)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
	at java.lang.Thread.run(Thread.java:748)

Line 52 of "build.gradle" is: subprojects { (the plugin is being applied to subprojects only).

Plugin version: 2.0.3.

Dependencies do not refreshed.

Hi, I like your gradle-testsets-plugin.
This is very useful for my work.

But there is a trouble. I wish it could be solved.

If I add dependencies in dependencies, They are not refreshed.
For example, I add my SNAPSHOT library in dependencies.

integrationTestCompile group: 'com.mygroup', name: 'my-library', version: '1.0.0-SNAPSHOT'

After I deploy new SNAPSHOT library in my local nexus repository,
New SNAPSHOT library is not downloaded from nexus.

'gradle --refresh-dependencies' options did not work.

configurations.all {
    resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}

'cacheChangingModulesFor' configuration did not work.

'changing=true' option also did not work.

To solve this problem,
I have to remove my gradle cache metadata descriptors.

/Users/myuser/.gradle/caches/modules-2/metadata-2.23/descriptors

or
I should put my library into testCompile

testCompile group: 'com.mygroup', name: 'my-library', version: '1.0.0-SNAPSHOT'

Thanks.

Java 7 compatibility

The documentation states I can use the plugin with Java 7.

I saw this issue where this caused problems:
#1

Is it possible that this problem is present again from versions > 1.0.2? I tried with 1.1.0 and 1.2.0 and got the same error.

Thanks for your response (and for the plugin)!

Main package not found

Hi,
I have migrate my build.gradle to Kotlin DSL in this way:

plugins {
    java
    idea

   id("org.unbroken-dome.test-sets") version "2.0.2"
}

testSets {
    create("integrationTest")
}

tasks.test {
    useJUnitPlatform()
}

tasks.named<Test>("integrationTest") {
    useJUnitPlatform()

}

under src/main/java i have my source code, under src/test/java my unit tests and under src/integrationTest/java my integration tests.

I execute my unit tests ./gradlew test and they work as expected but if I execute the integration tests ./gradlew integrationTest the build fail during the compileIntegrationTestJava task with this error:


[...]/src/integrationTest/java/com/example/server/repositories/QueueManagerRepositoryIntegrationTest.java:3: error: package com.example.server.entities does not exist
import com.example.server.entities.QueueManager;
                                     ^

I'm using gradle 5.0 and in groovy it work perfectly.

Am I doing something wrong?

IDEA support for custom source sets

Since the 2016 release IDEA supports custom source sets:
https://www.jetbrains.com/idea/whatsnew/#gradle

I am currently trying to setup a new project to see if and how that works, but as far as I understand it this might concern the following paragraph from the README?

Neither Eclipse nor IntelliJ IDEA support the notion of multiple test sets per project / module, so what the plugin does is only a "best fit" so you can at least run the tests from your IDE. These tests will never be executed in isolation, however, which may become an issue if you have files of the same name (e.g. log4j2-test.xml) in different source sets.

gradle 4.0+ test task not getting executed

Said you configure

testSets {
    itest
}

then when you execute gradle itest (in gradle 4.0+) task never get executed. gradle itest -info shows

Skipping task 'itest' as it has no source files and no previous output files.

Not supporting customized src files locations

Our project has its regression tests in test/regression folder with resources in testdata folder.

However with this plugin, by using dirName='regression' it only sets to src/regression/java and src/regression/resources

No way to specify sources and resources outside of src folder. (Or is there a workaround?)

Don't remove IDEA module configuration

This feature was removed in 2.0. While IDEA’s Gradle import may bypass the IdeaModel, creating the IDEA project using the IDEA plugin does not. When using the IDEA plugin to generate the project, this functionality is still valuable.

TestSets do not seem to modify Eclipse .classpath for ${testSet}Compile dependencies

Hey there,

Firstly, thank you for the wonderful plugin! It's looking really promising for some projects here, and is much appreciated. Many thanks!

I may be misunderstanding the plugin, but I believe I may have found a bug? In this Gist example, it seems that a gradle eclipse isn't producing .classpath entries for the integrationTest testSet.

I might well be misunderstanding things, but any help would be much appreciated.

Thanks again!

Jake

Publishing a JAR artifact for the unitTest set

It should be possible to publish the predefined unitTest set as a JAR artifact. This would be especially useful for migrating Maven projects, which (lacking the concept of a source set) often publish the unit tests as a separate JAR with the test classifier.

The artifact configuration name and classifier should both default to test but should be configurable.

Example:

testSets {
    unitTest { createArtifact = true }
}

should be equivalent to

configurations.create 'test'

task testJar (type: Jar) {
    from sourceSets.test.output
    classifier = 'test'
}

artifacts {
    test testJar
}

JDK 1.8 required

The Readme.md states:
"You will need to run Gradle with a JDK 1.7 or higher to use the plugin."

However, if you use JDK 1.7 with gradle-testsets-plugin 1.2.0 you will get the following error for the build.gradle line with apply plugin: 'org.unbroken-dome.test-sets'

FAILURE: Build failed with an exception.

Where:
Build file "xxxxxxx/build.gradle" line: 34

What went wrong:
A problem occurred evaluating root project "xxxxxxx".
java.lang.UnsupportedClassVersionError: org/unbrokendome/gradle/plugins/testsets/TestSetsPlugin : Unsupported major.minor version 52.0

Is the intention to support JDK 1.7, or JDK 1.8?

Make compatible with JDK 1.7 builds

Is there a reason setting sourceCompatiblity to 1.8? I tried to evaluate using gradle-testsets-plugin for my project, as soon as it's configured gradle fails with

org/unbrokendome/gradle/plugins/testsets/TestSetsPlugin : Unsupported major.minor version 52.0

Generated IDEA module contains library entries for 'build/classes/main' and 'build/resources/main'

This is similar to #7 for IDEA.
The idea plugin adds entries of type "module-library" for the main source set because the test set depends on them. This should be fixed by the plugin by manually removing these entries.

Problem with testSets in multi project build

It seems to me, that there is problem when defining testSet with same name under multiple projects which are part of a multi-project build.

Example build.gradle:

plugins {
	id 'java'
	id 'org.unbroken-dome.test-sets' version '2.0.1'
}

testSets { integrationTest }

project (":subproject") {
	apply plugin: 'java'
	apply plugin: 'org.unbroken-dome.test-sets'
	testSets { integrationTest }
}

Such configuration makes the integrationTestImplementation configuration for the root project, but not for subproject :subproject.
Also the integrationTest task is created only for the root project but not for the subproject.

When I choose different name for the subproject's integrationTest test-set (e.g. clientIntegrationTest), than all works as expected.

My two cents,
Tomáš Rohrbacher

Test set resources directory is marked as "test sources root" in IDEA

The "resources" directory of a test set should be marked as "test resources root".
Currently the plugin marks it as "test sources root".

Generated Eclipse .classpath contains lib entries for 'build/classes/main' and 'build/resources/main'

These 2 entries should not be added to the .classpath file of Eclipse:

How to use a build artifact as a test resource

Hi,

This might be a generic gradle question. How can I use a build artifact as one of the test resources?

I'm needed add "integration test" to my project and also wanted to keep them separate from unit test. This plugin seems to be just the tool for that purpose. So far it's working great. I have a separate sourceset called integrationTest and I have following directories in my project

src/integrationTest/groovy/
src/integrationTest/resource/

Now I need to enhance the existing integration test cases to use one of the artifacts produced after building the project (gradlew build). The artifacts are stored in build directory as per gradle convention.

Is there any way I can configure my gradle build script so that integrationTest sourcesets recognizes build artifacts?

How to set common configuration for multiple sourcesets

Hello,

I've used this plugin to create 2 sourcesets named integrationTest and functionalTest. The 2nd sourceset is extended from the 1st one.

There are some common configurations for both of them. For example:

integrationTest {
  outputs.upToDateWhen { false }
  testLogging { ... }
}

How can I get functionalTest to inherit those same configurations?

Do I need to use task graph to handle this or does this plugin already provide a feature for this that I'm not using?

integrationTest mistakenly run during gradle check

I've added an integrationTest set, which works as expected with gradle test (just the unit tests) and gradle integrationTests (unit + integration tests).

However, when I run gradle check, Gradle executes integration tests, which I don't want to happen.

build.gradle:

  testSets {
    integrationTest { dirName = 'integration-test' }
  }
  integrationTest.dependsOn test

What is some configuration I can use to work around this? Is there a way to disconnect the integrationTest task from the check task?

Custom resolution strategies are not working for integrationTest task

It seems like version resolution strategies are ignored by the plugin's integrationTest task.
Example:

configurations {
  provided
  all*.resolutionStrategy {
    force 'org.jboss.logging:jboss-logging:3.2.0.Final'
  }
}

Works for compile, test, and ear tasks, but for integrationTest, it does not work (meaning gradle pulls some other version than the one I specified)
This is both with the STS eclipse plugin and also when calling gradle from the command line.
Gradle is version 3.5

Reports, binary and xml test output all mixed up with 1.2.0

With the default settings of the testsets plugin for the stardard test set and custom integrationTest, the results (binary and junit xml), and the reports are all mixed up. For the project available here (master): https://github.com/wujek-srujek/testsets, here is what it looks like after invoking the build:

$ cd build/
$ find test-results -type f
test-results/binary/integrationTest/results.bin
test-results/binary/integrationTest/output.bin
test-results/binary/integrationTest/output.bin.idx
test-results/binary/test/results.bin
test-results/binary/test/output.bin
test-results/binary/test/output.bin.idx
test-results/TEST-com.test.UnitTestSpecification.xml

As you can see, the test-results contains the xml files for unit tests, but binary files for both test types.

$ find integrationTest-results -type f
integrationTest-results/TEST-com.integrationTest.IntegrationTestSpecification.xml

$ find integrationTest -type f
integrationTest/classes/com.integrationTest.IntegrationTestSpecification.html
integrationTest/js/report.js
integrationTest/css/style.css
integrationTest/css/base-style.css
integrationTest/packages/com.integrationTest.html
integrationTest/index.html

The reports for integrationTest are directly in the build folder.

$ find reports/tests -type f
reports/tests/classes/com.test.UnitTestSpecification.html
reports/tests/js/report.js
reports/tests/css/style.css
reports/tests/css/base-style.css
reports/tests/packages/com.test.html
reports/tests/index.html

Whereas the reports for the default tests are in the build/reports folder.

When using the following settings (see testsets-separate-folders branch):
tasks.withType(Test) {
reports.html.destination = new File(project.reportsDir, name)
reports.junitXml.destination = new File(project.buildDir, "${name}-results")
binResultsDir = new File(reports.junitXml.destination, 'binary')
}

the results are now:

$ cd build/
$ find test-results -type f
test-results/binary/results.bin
test-results/binary/output.bin
test-results/binary/output.bin.idx
test-results/TEST-com.test.UnitTestSpecification.xml

$ find integrationTest-results -type f
integrationTest-results/TEST-com.integrationTest.IntegrationTestSpecification.xml
integrationTest-results/binary/results.bin
integrationTest-results/binary/output.bin
integrationTest-results/binary/output.bin.idx

So, the binary and xml results are nicely separated and exist in their dedicated folders.

$ find reports/test -type f
reports/test/classes/com.test.UnitTestSpecification.html
reports/test/js/report.js
reports/test/css/style.css
reports/test/css/base-style.css
reports/test/packages/com.test.html
reports/test/index.html

$ find reports/integrationTest -type f
reports/integrationTest/classes/com.integrationTest.IntegrationTestSpecification.html
reports/integrationTest/js/report.js
reports/integrationTest/css/style.css
reports/integrationTest/css/base-style.css
reports/integrationTest/packages/com.integrationTest.html
reports/integrationTest/index.html

Similarly, all reports are under build/reports, and in correct folders. This is also consistent with the default layout/structure for the default test task without the testsets plugin applied.

I guess it would be really nice if the plugin provided such nice separation and segregation by default, i.e. add similar configuration in TestTaskListener.groovy.

When using Intellij's "separate module for each source set" resources aren't part of build

When I check "separate module for each source set", I notice that in the generated build dir anything in the integrationTest/resources directory isn't getting copied to build and is thus not on the classpath. When I uncheck this settings, then everything is fine.

How can I output to console information about failed test

Hello,

I'm trying to log to console information about failed integration test. The motivation is easy - to see information from console output without need to go html report in ci/cd.

with test task I can achieve it as:

test {
  testLogging {
    exceptionFormat = 'full'
  }
}

Thanks in advance.

Custom test set dependencies not available in IDEA TEST scope

I'm defining an 'integrationTest' test set and according to the documentation, this should add all the dependencies to the TEST scope in IDEA. However, this doesn't happen, and I can only make it work using the following:

idea {
    module {
        scopes.TEST.plus += [configurations.integrationTestRuntime]
    }
}

I have a multimodule project.

Make Eclipse support more resilient

It seem that the Eclipse plugin needs to be applied before the testset plugin. It would be helpful if that check whether Eclipse is applied could be deferred to a later stage in the execution and accept any order.

In our project we apply quite a number of plugins and it starts to become tricky to set them up in the proper order for everything to work.

interaction with Android Studio and org.springframework.boot.test.context.SpringBootTest?

I started with all of my tests under test/java/com/corp/package some of these are org.springframework.boot.test.context.SpringBootTest
After adding this plugin, and moving a single test into integrationTest/java/com/corp/package, I can no longer launch the tests from within Android Studio.

They still work from the command line, but Android Studio can't build the tests and run them.

main/java and main/resources do not appear in classpath of integrationTest for version 2.0.0

Using version 2.0.0 of the plugin, when running a test set (e.g. integrationTest) the runtime classpath does not contain the output of main/java and main/resources.

Using gradle 4.10.2 and jdk1.8.0_181, using the following source files, when running integrationTest the class Foobar cannot be found in the runtime classpath.

The example below works correctly with plugin version 1.5.1 but not with plugin version 2.0.0

build.gradle:

plugins {
//    id "org.unbroken-dome.test-sets" version "1.5.1" // works with 1.5.1
    id "org.unbroken-dome.test-sets" version "2.0.0" // does not work with 2.0.0
}

group 'dje1990'
version 'HEAD-SNAPSHOT'

apply plugin: "java"
apply plugin: "idea"

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: "org.junit.jupiter", name:"junit-jupiter-engine", version:"5.3.1"
}

test {
    useJUnitPlatform()
}

testSets {
    integrationTest
}

integrationTest {
    useJUnitPlatform()
}

sourceSets {
    integrationTest {
        java {
            srcDir "src/integrationTest/java"
        }
        resources {
            srcDir "src/integrationTest/resources"
        }
        compileClasspath += sourceSets.main.runtimeClasspath
    }
}

idea {
    module {
        testSourceDirs += project.sourceSets.integrationTest.java.srcDirs
        testSourceDirs += project.sourceSets.integrationTest.resources.srcDirs
    }
}

check.dependsOn integrationTest
integrationTest.mustRunAfter test

main/java/.../Foobar.java

package dje1990.testTestSets;

public class Foobar {
}

test/java/.../FoobarTest.java

package dje1990.testTestSets;

import org.junit.jupiter.api.Test;

public class FoobarTest {

    @Test
    public void test() {
        new Foobar();
    }
}

integrationTest/java/.../FoobarIntegrationTest.java

package dje1990.testTestSets;

import org.junit.jupiter.api.Test;

public class FoobarIntegrationTest {

    @Test
    public void test() {
        new Foobar();
    }
}

gradle output:

Testing started at 20:24 ...
20:24:47: Executing task 'integrationTest'...

> Task :compileJava UP-TO-DATE
> Task :processResources NO-SOURCE
> Task :classes UP-TO-DATE
> Task :compileIntegrationTestJava UP-TO-DATE
> Task :processIntegrationTestResources NO-SOURCE
> Task :integrationTestClasses UP-TO-DATE
> Task :integrationTest FAILED
dje1990.testTestSets.FoobarIntegrationTest > test() FAILED
    java.lang.NoClassDefFoundError at FoobarIntegrationTest.java:9
        Caused by: java.lang.ClassNotFoundException at FoobarIntegrationTest.java:9
1 test completed, 1 failed
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':integrationTest'.
> There were failing tests. See the report at: file:///C:/Users/david/IdeaProjects/testTestSets/build/reports/tests/integrationTest/index.html
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
3 actionable tasks: 1 executed, 2 up-to-date

dje1990/testTestSets/Foobar
java.lang.NoClassDefFoundError: dje1990/testTestSets/Foobar
	at dje1990.testTestSets.FoobarIntegrationTest.test(FoobarIntegrationTest.java:9)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:515)
	at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:115)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:171)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:167)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:114)
	at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:59)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:105)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:71)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:110)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:71)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:110)
	at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:72)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:95)
	at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:71)
	at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
	at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:170)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:154)
	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:90)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:92)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$100(JUnitPlatformTestClassProcessor.java:77)
	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:73)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
	at com.sun.proxy.$Proxy2.stop(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:131)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassNotFoundException: dje1990.testTestSets.Foobar
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 63 more

There were failing tests. See the report at: file:///C:/Users/david/IdeaProjects/testTestSets/build/reports/tests/integrationTest/index.html
20:24:48: Task execution finished 'integrationTest'.

Unit tests run during other test-set phases when using Spek

Hi,

When wirting tests with Spek, given the following configuration:

testSets {
  val integrationTest by creating
}

tasks.withType(Test::class).all {
  useJUnitPlatform {
    includeEngines("spek2")
  }
}

Running gradlew integrationTest executes the specifications present in both test and integrationTest directories. And running gradlew test integrationTest run twice specifications present in the test directory.

Any idea on how I could solve this issue?

Adding a testset source-set to the compile path of another testset

I have a scenario where I want to re-use code from a testset in another testset. The setup is as follows

plugins {
    id 'groovy'
    id 'idea'
    id 'org.unbroken-dome.test-sets' version '1.5.1'
}

group 'testset'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

testSets {
    sharedTest
    integrationTest
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.3.11'
    testCompile group: 'junit', name: 'junit', version: '4.12'

    integrationTestCompile 'org.spockframework:spock-core:1.1-groovy-2.4'

    integrationTestCompile sourceSets.sharedTest.output
}

This compiles and runs fine when running the gradle CLI to build and test. However the IDEA integration seems to fail as the code does not compile in the IDE. Running this with JDK 8 + IDEA 2018.2.4.
See https://github.com/MartinAhrer/gradle-testset-plugin-ideabug.

It looks like this has worked with earlier versions of IDEA + the testset plugin.

Option to insert test fixture code before test

I often have the situation where I want to write a test fixture / support library to make writing tests easier for me and for people using the main code.

For this, the build order has to be main -> testFixture -> test.

Can you add an option to your plugin which allows to insert new test sets before the normal tests?

Version 1.5.1 not found in jcenter()

Could not find org.unbroken-dome.gradle-plugins:gradle-testsets-plugin:1.5.1.
Searched in the following locations:
https://jcenter.bintray.com/org/unbroken-dome/gradle-plugins/gradle-testsets-plugin/1.5.1/gradle-testsets-plugin-1.5.1.pom
https://jcenter.bintray.com/org/unbroken-dome/gradle-plugins/gradle-testsets-plugin/1.5.1/gradle-testsets-plugin-1.5.1.jar

integrationTest task not added but integrationTestJar and integrationTestClasses

I'm trying to follow the README.md instructions, but gradle does not recognize the integrationTest task. I do get an integrationTestJar and an integrationTestClasses task.

gradle -v

Gradle 3.3

Build time: 2017-01-03 15:31:04 UTC
Revision: 075893a3d0798c0c1f322899b41ceca82e4e134b

Groovy: 2.4.7
Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_111 (Oracle Corporation 25.111-b14)
OS: Mac OS X 10.11.6 x86_64

I tried using the example from https://github.com/pkainulainen/gradle-examples.

I've also tried using gradle 3.0, 2.14 and 2.9

Which version of gradle is this known to work with?

Creating test set name dynamically

This is a question on how I can name the testSet dynamically - and maybe more of a groovy question. I am new to groovy and gradle so any help is much appreciated.

What I am trying to is create multiple test sets (in a loop). I have a set of names so I am trying to do as follows in my own plugin:

names.each { name ->
            def testSetName = "testName"+name
            project.configure(project) {
                apply plugin: 'org.unbroken-dome.test-sets'
                testSets {
                    testSetName {
                        ...
                    }
                }
...

The testSetName is what I want dynamically added to my project. The above does not work and it fails saying a String cannot be applied to a method expecting a closure. What would be the way to do this?

Thanks

Using Unit Test (Base) Class in Integration Test

First of all, I'm not sure if it's a bug or intended behavior.

I have this test set in my build file:

testSets {
  integrationTest
}

Furthermore, I defined a base class in the unit test source set and another base class in the integration test source set that derives from the unit test base class. When trying to compile the integration tests, I get a compiler error saying 'unable to resolve class'.

Compilation works as soon as I add this:

sourceSets {
  integrationTest {
    compileClasspath += sourceSets.test.output
    runtimeClasspath += sourceSets.test.output
  }
}

As said, I'm not sure if the plugin should behave like that. If yes, it might be helpful to extend the documentation, just in case someone has a similar scenario.

Plugin does not get automatically applied to subprojects

Minor nit: I had to

subprojects {
     apply plugin: 'org.unbroken-dome.test-sets'
}

in order to get the 'integrationTest' task for my subprojects also (it was already available for the root project).

Expected output for gradle tasks

Can you help me understand why if I have something like this in my build.gradle:

testSets {
    integrationTest { dirName = 'integration-test' }
}

And I run

 > gradle tasks

I don't see "integrationTest" listed in the output?

Yet when I run

> gradle build

I see the task "integrationTest" does exist and is run?

Prepend the classpath instead of appending it

In #55, there was a fix to concatenate the classpath of the test set to the existing test classpath, but this was done by appending to the test classpath (using +=).

I believe the correct behavior (as was present in 1.5.x) is to prepend the test set classpath to the test classpath, so that there can be overrides in the test set (files with the same path, for example).

Classpath is set incorrectly when using `tasks.withType(Test)` configuration

I'm applying a classpath to all tests in a multi-project build using tasks.withType. This causes the testClassesDirs to not be on the classpath of the test task configured by the plugin. Here is a test case to reproduce. Save the file as build.gradle and run with gradle clean -q -PadditionalClasspath and then with ./gradlew clean -q. You'll see the following outputs:

As you'll see integrationTest dir is nowhere on the classpath in one of the cases. I'll and work on a fix in the plugin, but in the meanwhile, if there's a workaround — I'd appreciate any pointers :)

$./gradlew clean -q
[/private/tmp/foo/build/classes/java/integrationTest, /private/tmp/foo/build/resources/integrationTest, /private/tmp/foo/build/classes/java/main, /private/tmp/foo/build/resources/main]
$./gradlew clean -q -PadditionalClasspath
[/private/tmp/foo/build/classes/java/test, /private/tmp/foo/build/resources/test, /private/tmp/foo/build/classes/java/main, /private/tmp/foo/build/resources/main, /private/tmp/foo/foo]

plugins {
    id 'org.unbroken-dome.test-sets' version '1.4.2'
}

apply plugin: 'java'

tasks.withType(Test) {
  if (project.hasProperty('additionalClasspath')) {
    classpath += files('foo')
  }
}

testSets {
    integrationTest
}

println integrationTest.classpath.files

Version 1.3.0 not available

Version 1.3.0 is not available neither from jcenter nor from plugins.gradle.org.

Maybe, if it has not been released yet, it would be better to add a few lines to the README.

Add support for IntelliJ IDEA

As an IntelliJ IDEA user, I would like to be able to run my tests from additional test sets from inside the IDE so I don't have to switch to a command line or an external build configuration.

The following steps are necessary to integrate extra test sets in the IDEA module:

mark test source set root directory as "test sources root" (folder shows as green icon in IDEA)
add dependencies from test set to module in TEST scope

Build failure: Can't find plugin in private Nexus

We have a private Nexus and we are getting everything except for this gradle plugin.

    plugins {
        id 'org.unbroken-dome.test-sets' version '1.5.0'
    }

setting.gradle

pluginManagement {
    resolutionStrategy {
        eachPlugin {
           if (requested.id.namespace == 'org.unbroken-dome.gradle-plugins') {
            useModule('org.unbroken-dome.gradle-plugins:gradle-testsets-plugin:1.5.0')
          }
        }
    }
    repositories {
  		maven {
  			url 'http://someurl.com/repository/MavenRepoGroup/'
  			credentials {
  				username 'username'
  				password 'password'
  			}
  		}
  	}
  }

Whenever, I try to build I get following error:


    * What went wrong:
    Plugin [id: 'org.unbroken-dome.test-sets', version: '1.5.0', apply: false] was not found in any of the following sources:
    
    - Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
    - maven(http://someurl.com/repository/MavenRepoGroup/) (Could not resolve plugin artifact 'org.unbroken-dome.test-sets:org.unbroken-dome.test-sets.gradle.plugin:1.5.0')

java-library compat / gradle 4

In gradle 4 there is a java-library plugin which creates two configurations "api","implementation"
These then get put into the configurations compileClasspath/testCompileClasspath and runtimeClasspath/testRuntimeClasspath respectively
But they don't get added to runtime/testRuntime compile/compileRuntime as these seem to be deprecated. This in turn means the testset config don't get the libs added to the classpath.

I think the bug is that testsets extends testRuntime and testCompile instead of testRuntimeClasspath and testCompileClasspath

Create separated reports

Hello,
First, thank you for your plugin, it's a very good idea.

It would be nice if each test task could generate a separated report at the end.
Right now, the reports are all generated in the default dir, build/reports/tests.
If you run multiple test tasks, they will overwrite each other's reports.

It can be fixed with very little config but it would be nice if the plugin could take care of that:

tasks.withType(Test) {
    reports.html.destination = file("${reporting.baseDir}/${name}")
}

What do you think?

How to add dependencies from integrationTest of another gradle module.

Hello,
I have a case where I have a common module (ex : C) for the dao and two applications modules.
I need to write integration tests for the two different applications modules (A and B), but I want to have the injector used to initialize the database, in the common module.

How can I make the classes in C accessible from A and B ?

Regards.

gradle repository problem for version 1.4.3

Hello,
There was a problem with the gradle repository.

gradle build error

Could not find gradle.plugin.org.unbroken-dome.gradle-plugins:gradle-testsets-
plugin:1.4.3.

and link error
https://plugins-artifacts.gradle.org/gradle.plugin.org.unbroken-dome.gradle-plugins/gradle-testsets-plugin/1.4.3/e1dbaadf8068147ef7f312fc722ec971f52465b502f430a995ef0d8ba093576f/gradle-testsets-plugin-1.4.3.pom

<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>gradle.plugin.org.unbroken-dome.gradle-plugins/gradle-testsets-plugin/1.4.3/e1dbaadf8068147ef7f312fc722ec971f52465b502f430a995ef0d8ba093576f/gradle-testsets-plugin-1.4.3.pom</Key><RequestId>48D2CF5BE03DD308</RequestId><HostId>FPsIZBIHlePZQORZoBNrYGOAKfPboeMu0a5eB8lMPf2RPYPqAjcpeX88FdOvn/6WWJUIoWpeq7k=</HostId></Error>

Regards.

Handling of 'resources' folder

I have added an integrationTest source to an IDEA project with the 'idea' plugin applied (java and groovy too)

testSets {
    integrationTest
}

IDEA marks the src/integrationTest/groovy (and resources) as directories containing sources and resources in the source tree view. The filesystem layout is as follows

├── integrationTest
│   ├── groovy
│   │   └── at
│   │       └── martinahrer
│   │           └── service
│   │               └── integrationtest
│   │                   └── HomeIntegrationSpecification.groovy
│   └── resources
│       ├── application.properties
│       └── application.yml
└── main
    ├── java
    │   └── at
    │       └── martinahrer
    │           └── service
    │               └── ServiceApplication.java
    └── resources
        └── bootstrap.ml

When running the integration test from IDEA it looks like src/integrationTest/resources is not included in the execution class path. The file application.properties should be loaded (the application is based on Spring Boot) but is not and fails. Running the same setup from command line (gradle integrationTest) the test is going green.

Renaming the integrationTest to test (as supported by the Gradle groovy source set) the application works. The same applies when just moving application.properties into src/main/resources.

So the question is if there is any special setup required for the resources folder or is this an IDEA issue. I know that IDEA is not able to isolate various source sets from each other. But I guess this is not the root cause here?

unbroken-dome / gradle-testsets-plugin Goto Github PK

gradle-testsets-plugin's People

Contributors

Stargazers

Watchers

Forkers

gradle-testsets-plugin's Issues

gradle -v

Gradle 3.3

Recommend Projects

Recommend Topics

Recommend Org