Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 4.x
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:Windows 7/Eclipse Kepler/Java 1.7.0_51
-
Number of attachments :
Description
The JBehave runner ignores the @Ignore annotation.
i.e. It actually runs TestCase(s) marked with @Ignore.
Activity
>> JBehave is not a unit-testing framework and does not aim to honour the JUnit annotations nor test cases.
So why does it even run them at all then?
Martin Spamer
added a comment - >> JBehave is not a unit-testing framework and does not aim to honour the JUnit annotations nor test cases.
So why does it even run them at all then? @Martin
I got curious. how are you using JBehave and why you need to use @Ignore ?
Junit is just ONE of the ways to start a JBehave execution. You can use TestNG, maven, java cli, OSGi service and others.
When using junit you are required to have only one junit tagged method (@Test) that bootstraps JBehave:
@Test
public void run()
So, doesn't make any sense to support @Ignore...
Even if you need to exclude Step methods from the execution (that has nothing to do with Junit) that is not the way to go...
Cristiano Gavião
added a comment - @Martin
I got curious. how are you using JBehave and why you need to use @Ignore ?
Junit is just ONE of the ways to start a JBehave execution. You can use TestNG, maven, java cli, OSGi service and others.
When using junit you are required to have only one junit tagged method (@Test) that bootstraps JBehave:
@Test
public void run()
{
embedder.runStoriesAsPaths(asList(storyPath));
}
So, doesn't make any sense to support @Ignore...
Even if you need to exclude Step methods from the execution (that has nothing to do with Junit) that is not the way to go... I work as an Automation tester (my background is Java Dev), so I'm implementing (predominatly) function test suites for a target system. We use SCRUM and endeavour to a take strongly TDD approach. We have seperate developers. Therefore 1) Test Suites materialise before any significant development has taken place on the SUT, and 2) Test suites are developed with JUnit tests first.
The code that forms the Test suite contains code that tests the functionality of the test suite itself. Previously we've been using Eclipse/Jenkins to drive Maven with JUnit, WebDriver, SOAPUI and Emma etc. We've had stories with Hoare logic acceptance criteria that fall into the BDD imperrative style implemented in Java. Recently been looking at strengthening this approach with BDD Tools. This involved a Technology spikes using JBehave and Cucumber. As part of that we've also been moving towards a more abstract declarative story style.
This means the Test Suite contains both pure JUnit tests and BDD tests. The more elaborate nature of the declarative style requires JUnit tests (or seems to) and we need a flexible means to be able to control these.
As it happens we've adopted CucumberJvm; and one reason is @Cucumber.Options() allows us to maintain this control via glue and features that doesn't seem possible with JBehave.
Martin Spamer
added a comment - - edited I work as an Automation tester (my background is Java Dev), so I'm implementing (predominatly) function test suites for a target system. We use SCRUM and endeavour to a take strongly TDD approach. We have seperate developers. Therefore 1) Test Suites materialise before any significant development has taken place on the SUT, and 2) Test suites are developed with JUnit tests first.
The code that forms the Test suite contains code that tests the functionality of the test suite itself. Previously we've been using Eclipse/Jenkins to drive Maven with JUnit, WebDriver, SOAPUI and Emma etc. We've had stories with Hoare logic acceptance criteria that fall into the BDD imperrative style implemented in Java. Recently been looking at strengthening this approach with BDD Tools. This involved a Technology spikes using JBehave and Cucumber. As part of that we've also been moving towards a more abstract declarative story style.
This means the Test Suite contains both pure JUnit tests and BDD tests. The more elaborate nature of the declarative style requires JUnit tests (or seems to) and we need a flexible means to be able to control these.
As it happens we've adopted CucumberJvm; and one reason is @Cucumber.Options() allows us to maintain this control via glue and features that doesn't seem possible with JBehave. 
JBehave is not a unit-testing framework and does not aim to honour the JUnit annotations nor test cases.