Arquillian Core Suite/SubSuite: How to define the Suite

dev
, ,
#12

Both Suite Scanner and Child Reference are implemented in the latest published 1.1.8.Final-SNAPSHOT version.

:ike_success:

For Suites to work in Maven you need to force Surefire to use the JUnit 4.7 provider:

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<version>2.18.1</version>
			<dependencies>
				<dependency>
					<groupId>org.apache.maven.surefire</groupId>
					<artifactId>surefire-junit47</artifactId>
					<version>2.18.1</version>
				</dependency>
			</dependencies>
		</plugin>
	</plugins>
</build>
#13

4.4 seconds to run 238 integration tests… not too shabby

:ike_success:

#14

I am for child reference as well.

I do not know if “BelongsTo” annotation is the best one. Not saying it is chosen badly, just that the annotation alone does not quite say it has something to do with Arquillian suite. If I saw it for the first time, I would not know that “BelongsTo” has some relationship to suites at all …

#15

Agree. Not sure if we should describe that this deployment scenario is read from somewhere else (and since many read from this they can reuse) or if we should be more explicit and describe it as this is part of the larger suite definition x…

#16

Maybe just putting the word “suite” into that annotation in order to be more explicit could do the job.

@BelongsToSuite(MySuite.class)

@PartOfSuite(MySuite.class)

@SuiteAware(MySuite.class)

If the only intent of suite class is the deployment providing, that annotation could be maybe more deployment-centric. Something like @DeploymentProvider(MyDeployments.class) or anything like that, just an idea.

#17

I also like these as they better communicate what the annotation is provoking

@BelongsToSuite(MySuite.class)
@PartOfSuite(MySuite.class)

@SuiteAware is not a favorite of mine because it suggests that it would also run without.

@DeploymentProvider would also not really hit the whole point if a suite would also have callbacks @BeforeSuite and @AfterSuite in the future or if a suite could contain rules.

#18

Sure I meant Child Reference - it got mixed up. But I see it is already implemented - thanks.

#19

I vote also for child reference. What about the following for referencing more than one suite:

@BelongsToSuite({MySuite.class, SecondSuite.class})

The point from robert is for us very usefull:

@BeforeSuite and @AfterSuite

When this works in combination with persistence extension api:

@UsingDataSet and @DataSource

then we can inject data for all tests on different datasources. Very cool feature…
So for this to work well the

@BeforeSuite and @AfterSuite

Annotation should not be restricted to use only once in suite. If annotated on more than one method you can use same/different datasets on different datasources. Very useful in our case, as we have a multi schema application…

#20

Hello,

just for my interest. Are there some plans for merging the suite functionality to new release of core?

Thank you
Ondra

How do I get 1.2.0 Alpha1 release
#21

Yes, it will be see first in 1.2.0.Alpha1.

#22

Ok, I see. Thanks for info.

#23

Hi @aslak , 1.2.0.Alpha1 what? core? drone? what is dependency name?

#24

1.2.0.Alpha1 of Core :smile:

1 Like
#25

when? you have a date for publishing?
Thanks

#26

Has the work started on this @aslak? If not, when do you think something will be available for me to write about?

#27

The plan is to have 1.2.0.Alpha1 out by J1 :smile:

#28

Hi @aslak, is this the most updated work for suite support? I’m facing an issue with suite extension and chameleon and want see if it also happens with the new/official suite too.

1 Like
#29

all people needs suite

#30

Hi, @aslak Suite not available?

#31

Hi, @aslak, will Suite also be supported to run TestNG tests on arquillian.