Currently, instrumentation does not have a way to filter out or select the classes of interest to be instrumented. As such, a undesired class might be loaded by the class loader twice, once during instrumentation and a second time during test execution.

Adding a way to select the test classes will prevent such cases.

Resource loading requires the usage of a unix like path separator.

Prefix properties file names with 'cola-tests-'.

Introduce filter to prepare Report information from parsed comments.

Add instrumentation mechanism for cola-tests.

With the introduction of the IdeEnabler annotation, the need for a default class and method name is no longer required.

• Remove default from cola-tests
• Remove default from cola-maven-plugin
• Remove default from cola-gradle-plugin
• Remove default from cola-idea-plugin

Sometimes is useful to call pre and/or post steps without having to explicitly include them in the scenario. This complements "scenario backgrounds" and allows for extra flexibility. E.g.:

@PreSteps({ 
  "Given the details of multiple accounts",
  "When the accounts are created" }
@Given("a user")
public fun findAvailableUser() {
    user = db.loadFirstUser()
}

Add license header to source classes

Currently users have to use the IDE error log (e.g. Eclipse Error Log view) in order to visualize the compile time error.

It would be much nicer to have the compile time errors reported to the console when the junit test is executed.

Consider injecting a test method that will always fail but used to simply report the compile time issues.

Prepare poms for release 0.2.0

No error or notification is provided when there's a malformed Examples:

Feature: Malformed examples example
  Scenario Outline: Malformed examples
    Given A
    When B is <foo>
    Then C

  Examples:
  | foo
  baa
  boo

A correct version would be:

Feature: Examples example
  Scenario Outline: Examples
    Given A
    When B is <foo>
    Then C

  Examples:
  | foo |
  | baa |
  | boo |

Please provide the option to specify the a directory where feature files are located.

@Features(dir="classpath:features/", features={"feature1", "feature2"})

Add @Depends annotation

Ensure that tags and comments are parsed from gherkin file.

When a "child" test defined in @dependsOn fails then the parent test must also fail.

Introduce a filtering API to process filters with a common interface to both Tags and Reports.

The implementation must take into consideration the @Skip and @ignore tag and prevent further filtering when present.

Steps should allows for multiple aliases. E.g.:

@Given({"an alcoholic drink", "a beer", "a wine"})

@dependsOn should allow the execution of a single test method as opposed to just the full test class.

Update poms to snapshot 0.2.1-SNAPSHOT

Scenario: Should allow specialized JUnit constructors
Given a JUnit test with a specialized constructor
And a @Feature annotated field
When the test is COLA Tests compiled
Then test methods should be injected

This error can occur when using JUnit Runners like Parameterized that use a specialized constructor to inject parameter values.

Two possible solutions:

1. Keep using reflection and provide basic values to constructor (improve current solution)
2. Extract value from bytecode (might not work due to current bug in ASM)

Workarounds for current issue:

1. Use @Features class annotation
2. Use default stories field

Hi,

I know this is a big one, and you probably want to focus more on the core functionalities first. But I think it would be very nice to have a better IDE integration (I personally use eclipse). Something basic, like right-clicking on a step in the feature file and being able to jump to the implementation.

I saw there are some plugins in eclipse for other BDD frameworks, maybe it's possible to extend them to add support for Cola annotations?

Anyway I thought i'd open a feature request. I understand if you don't tackle it in the near future.

Cheers

Add config for Travis CI and Appveyor.

The current name is confusing and the new one is not that much clear either...

Hi,

I'm starting a new project at work which requires ant to build. So I'm using instrumentation to run the JUnit tests, both in ant and in eclipse, which works fine.

However I was surprised to see that the following test did pass given that I don't have the feature file in the project. I wanted to see it fail to make sure the instrumentation was working correctly.

@Features("blabla")
public class BlablaTest extends AbstractBaseColaTest {

    @Test
    public void something() {

    }

    @Given("a <beverage>")
    public void chooseBeverage(@Projection("beverage") final String beverage) {
    }

    @When("a google search is performed")
    public void performGoogleSearch() {
    }

    @Then("the <beverage> wikipedia entry will be present")
    public void verifyBeverageIsPresentInWikipedia(@Projection("beverage") final String beverage) {
        fail("Failed!");
    }
}

In a strict BDD test class, I suppose there would not be @test annotations, so it would fail with a message: java.lang.Exception: No runnable methods

But given a test class with a Features annotation, I think the tests should fail if any of the feature file(s) listed cannot be loaded.

On a side-note, this is the first time I'll use it at work, it's a small project where I am the only developer so the context is perfect. I'll do a presentation later this year on BDD to my colleagues and I hope I'll convince more people to use it.

Thanks

In order to keep state between tests it is required to have a way to easily share selected instances.

Extract cola-tests out of cola-maven-plugin and into its own project.

All minor issues regarding 0.1.0 release