Run tests from a JAR file

[Alexander Miro]

Hi, this is my first post. I did some research about this issue without success.

What I want is something like this:

       JUnitCore.runClasses(OutOfStockTest.class)


Where OutOfStockTest.java is:

@RunWith(Cucumber.class)
@CucumberOptions(
    features = {"classpath:/home/alexandermiro/work/atest-bf/bdd/out_of_stock.feature"}
    , glue = {"br.com.softbox.atest.features"}
)
public class OutOfStockTest {
}

Context:
I am building a automation tests framework that should load a JAR file which contains the step definitions and the runner classes
(i.e OutOfStockTest). The feature files would be located in another place as shown above. The idea is to build an application that
will load all tests (from the JAR) in memory and after that, the user could choose (via GUI) a specific test to run.

As shown in screen02.png, an attempt to run (via IDE) the OutOfStockTest shows the output message "No features found at[...]".
I've tried 'classpath' without "out_of_stock.feature". It's clear that the second stage (JUnitCore.runClasses()) will not work having
that issue unsolved.

This project structure is like this way in order to have the Cucumber classes inside the JAR. There is another approach
where I could keep my test files bellow the 'test' directory (see screen01.png), however I would have to do extra work to manage
Maven to generate a parallel JAR to package the tests class.

So,

1) Is there any chances that this "infrastructure" will work as I've mentioned?

2) What am I doing wrong in trying to execute a Cumcumber test using the IDE like I did?

Thanks
Miro

[aslak hellesoy]

On Tue, Sep 22, 2015 at 4:36 PM, Alexander Miro <alexand...@gmail.com> wrote:

Hi, this is my first post.

Welcome!

Cucumber is a tool for BDD. BDD is a special flavour of TDD (where tests are written collaboratively with the business).

It's still intended to be used following the TDD cycle, using failing tests to guide the design and implementation of unwritten software.

1: Fred writes a failing test and watches it fail

2: Fred writes just enough code to make the failing test pass

3: Fred cleans up his mess (refactor)

4: GOTO 1

You can replace Fred with "Pair" in step 1-3, but if you replace Fred with say, Alexander, in step 1 only, then this is something very different from TDD.

Cucumber wants the people who write the tests (gherkin+stepdef) to be the same as the people who write the application code.

Cucumber wants test code and application code to be written at the same time (altering back and forth several times per hour)

Cucumber also wants all those artifacts to be stored in the same source control system.

Using Cucumber outside of its intended environment isn't going to be easy - it's not designed for that.

In particular - writing a test automation framework, packaging it up for the benefit of other people isn't what Cucumber is designed to do.

Cheers,

Aslak

 

Thanks
Miro

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roberto Lo Giacco]

Il giorno mercoledì 23 settembre 2015 11:13:55 UTC+2, Aslak Hellesøy ha scritto:

On Tue, Sep 22, 2015 at 4:36 PM, Alexander Miro <alexand...@gmail.com> wrote:

Hi, this is my first post.

Welcome!

 

Cucumber is a tool for BDD. BDD is a special flavour of TDD (where tests are written collaboratively with the business).

It's still intended to be used following the TDD cycle, using failing tests to guide the design and implementation of unwritten software.

1: Fred writes a failing test and watches it fail

2: Fred writes just enough code to make the failing test pass

3: Fred cleans up his mess (refactor)

4: GOTO 1

You can replace Fred with "Pair" in step 1-3, but if you replace Fred with say, Alexander, in step 1 only, then this is something very different from TDD.

Cucumber wants the people who write the tests (gherkin+stepdef) to be the same as the people who write the application code.

Cucumber wants test code and application code to be written at the same time (altering back and forth several times per hour)

Cucumber also wants all those artifacts to be stored in the same source control system.

Using Cucumber outside of its intended environment isn't going to be easy - it's not designed for that.

In particular - writing a test automation framework, packaging it up for the benefit of other people isn't what Cucumber is designed to do.

I haven't interpreted his request in the same way as you did Aslak, I actually thought he was trying to provide a GUI to run just a slice of the available features.

Let's see what Miro has to say with regards to this, because if my understanding is correct I don't see this as breaking the intended purpose (otherwise I'm breaking the intended purpose as well).

And, just as a side note, we have the Gherkin written by a pair made by a developer and the product owner (somebody from the business) while the StepDefs are implemented by the developer on his own... The code exercised by the StepDef is written by possibly a different developer, but all of them are part of the same (scrum) team... ;D

[Alexander Miro]

Thanks you Aslak and Roberto,

My intermediary english prevents me to express me as expected. So let me try to clarify my point.

In my project, we are doing BDD (+ Cucumber) as it was designed. We follow the whole cycle, and
basically the stakeholder writes the features and I am responsible for implement the step definitions.

The automation tests framework that I've mentioned before is just to run the already implemented and
evaluated tests, in other words, all those tests that passed by the BDD lifecycle will be available to be
executed via GUI.

That said, what I am trying to do is to package these "finished" tests in a JAR in a such way that
would be easy to execute them from other application. That is the issue that I am facing right now.

Miro

[Roberto Lo Giacco]

On Wed, Sep 23, 2015 at 6:28 PM, Alexander Miro <alexand...@gmail.com> wrote:

Thanks you Aslak and Roberto,

My intermediary english prevents me to express me as expected. So let me try to clarify my point.

In my project, we are doing BDD (+ Cucumber) as it was designed. We follow the whole cycle, and
basically the stakeholder writes the features and I am responsible for implement the step definitions.

The automation tests framework that I've mentioned before is just to run the already implemented and
evaluated tests, in other words, all those tests that passed by the BDD lifecycle will be available to be
executed via GUI.

That said, what I am trying to do is to package these "finished" tests in a JAR in a such way that
would be easy to execute them from other application. That is the issue that I am facing right now.

Since I don't need a GUI my solution was to just use Maven via command line:

mvn integration-test -P cucumber -Dfeature=customer.feature

I do understand that's not your goal and you want a GUI, but you might consider to just create a wrapper around that.

The way I pass the provided feature system property to @CucumberOptions is by... system properties!

Here follows my Failsafe Maven plugin 

          <plugin>

            <artifactId>maven-failsafe-plugin</artifactId>

            <executions>

              <execution>

                <goals>

                  <goal>integration-test</goal>

                </goals>

              </execution>

            </executions>

            <configuration>

              <includes>

                <include>**/JUnitWrapper.java</include>

              </includes>

              <systemPropertyVariables>

                <webapp.base.url>${cargo.url.prefix}</webapp.base.url>

                <cucumber.options>

                  <![CDATA[--tags ${tags} ${cucumber.features.dir}/${feature}]]>

                </cucumber.options>

              </systemPropertyVariables>

            </configuration>

          </plugin>

This config permits to specify tags or feature.

I understand your problem is having the feature files in a JAR, but I don't believe the Cucumber JUnit runner is capable to read the files from classpath, but you can create a custom extension which interprets the "classpath:" prefix and behaves accordingly....

Regards,

   Roberto

[James Nord]

You dont need to use the junit runner.
I had pretty much the described situation bar the gui. All the code, cucumber, dependencies, tests and features where in an uber jar that was invoked with the feature(s) or tags to run. I no longer have accessto this cod and dont remeber the apis i used.