Group features in for instance traits and run from one or more "testrunner-classes"

[Peter Nicolai Motzfeldt]

Hi, we har enjoying Spock very much, it is a great test framework.

We are using it for all sorts of tests now

In our module/integration tests, we start an embedded tomcat before running the specs. And the tomcat startup time is long, around 20 seconds. And when we do this for each testclass, and we have about 20, and we currently run 4 in parallel with gradle, this startup time is considerable.

So tried to maybe use traits and group the features in 20 different traits, and then have one testrunner implementing all the traits, making the tomcat startup only once. But met difficulties doing this, due to Spock not considering features in a trait as a feature.

Does anyone have any idea have I can make this work, in any way?

We have tried fixing tomcats startup, but did not get anywhere.

Thanks in advance!

- Peter

[Kostis Kapelonis]

Hello

It is not clear to me if you start/stop Tomcat in your unit tests or
in Gradle. It should be the latter.

>"And when we do this for each testclass"

Is this really needed? Is there a business or technical need for that?

You should set it up so that tomcat starts only once before _any_ of
the tests run and closes down after _all_ tests have finished. Whether
the tests are JUnit, Spock, JMeter scripts or anything else, it
shouldn't matter to Gradle. When Spock runs, everything should be
already setup. Spock itself should not be responsible for controlling
tomcat.


Kostis

> --
> You received this message because you are subscribed to the Google Groups
> "Spock Framework - User" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to spockframewor...@googlegroups.com.
> To post to this group, send email to spockfr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/spockframework.
> For more options, visit https://groups.google.com/d/optout.

[Peter Nicolai Motzfeldt]

Thank you for the response.

Sorry for not being more clear.

I agree that Spock should not start tomcat, and the reason why we are doing this, is running the tests easy from Intellij.

And we are also using ClientDriver to mock the api module, making it difficult to start the tomcat and ClientDriver (as the mock of the api) as a pretask (from either gradle, or in Intellij), since we need a reference to clientdriver to add expectations from the tests.

Maybe we need to rethink this setup as you mention, but are there a way to use traits, or any other way. But are open to change setup if any good ideas :-)

[Kostis Kapelonis]

Hello

If by ClientDriver you mean
https://github.com/rest-driver/rest-driver/wiki/Client-driver, then
why do you need tomcat in the first place?
Why does tomcat need to be up, if the REST endpoint is mocked?

>I agree that Spock should not start tomcat, and the reason why we are doing this, is running the tests easy from Intellij.

I think you have a non-standard setup. In general your IDE should
conform to the build system, not the other way around. Your setup
should run fine from the command line/build server regardless of the
presence of an IDE (Intellij in your case).

>But are open to change setup if any good ideas :-)

Split your tests in two. Those that need the actual Tomcat, should run
as integration tests, where the application is deployed once and all
tests find everything ready.
Then you need a separate category of tests that use the mocked rest
endpoint and those should run as normal tests (i.e. without tomcat).

Kostis

[Peter Nicolai Motzfeldt]

Hi again, I think I am not describing it good enough. Sorry for that, bare with me :-)

>If by ClientDriver you mean

https://github.com/rest-driver/rest-driver/wiki/Client-driver, then
why do you need tomcat in the first place?
Why does tomcat need to be up, if the REST endpoint is mocked?

Yes, correct ClientDriver. But the client driver is just used as a service the module under test. Will try to describe better.

Little background:

We have multiple modules, and in each module we have tests that test the units inside the module, and then we have something we call module tests, that tests the module as a black box (these are the tests that I am talking about), and then we have cucumber tests that tests the entire application running all the modules.

But with the moduleTests (black box testing) of one component, we run the component in a tomcat, and then mock the services that it tries to interact with, thats why ClientDriver as well with the tomcat. I am not saying it is the perfect setup, but is working well, if we look a side of the time.

We can easily start the tomcat before tests, but the clientdriver mocking the api service that the module interacts with is more difficult. This we need a reference to during the tests to add expectations.

>I think you have a non-standard setup. In general your IDE should

conform to the build system, not the other way around. Your setup
should run fine from the command line/build server regardless of the
presence of an IDE (Intellij in your case).

I both agree and disagree, both should be supported well, since during development many developers wnat to just run the tests in the IDE not running the build. But that is a side topic, cause we will make it work with the IDE if we find a good solution.

Thanks again.

You received this message because you are subscribed to a topic in the Google Groups "Spock Framework - User" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spockframework/F9ZkJeWrTMo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to spockframewor...@googlegroups.com.

[Kostis Kapelonis]

Ok I see what you mean.

Ideally you would need a way to start tomcat once for before all tests
(when running from the command line) and also once when a developer
runs a single test from the IDE.

Unfortunately this does not seem to be supported in vanilla Spock. My
guess is that a custom extension would be needed

Kostis



On Wed, Sep 9, 2015 at 8:52 PM, Peter Nicolai Motzfeldt