[jbehave-dev] [jira] Commented: (JBEHAVE-230) Add Narrative elements to Story parsing
[ http://jira.codehaus.org/browse/JBEHAVE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210942#action_210942 ] Mauro Talevi commented on JBEHAVE-230: -- Added keyword-driven optional narrative elements to story. Keywords are (i18n-able as all keywords): Narrative: In order to [the story value] As a [the actor(s)] I want to [the story objective] Reports have been updated to be narrative-aware. HTML reports are CSS-styleable. Trader example scenarios updated to use narratives - not all scenarios to show its optional nature. Add Narrative elements to Story parsing --- Key: JBEHAVE-230 URL: http://jira.codehaus.org/browse/JBEHAVE-230 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5 The current domain model captures everything before the first Scenario as unstructured text (hence the name Blurb in the domain module). Hence not an issue in a plain text report (newlines are maintained) but becomes less readable in, say, HTML. We should add an optional Narrative element with appropriate keywords, so as to be able to distinguish between the various elements of the narrative (In order to, As a, I want to). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-230) Add Narrative elements to Story parsing
[ http://jira.codehaus.org/browse/JBEHAVE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-230. -- Resolution: Fixed Add Narrative elements to Story parsing --- Key: JBEHAVE-230 URL: http://jira.codehaus.org/browse/JBEHAVE-230 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5 The current domain model captures everything before the first Scenario as unstructured text (hence the name Blurb in the domain module). Hence not an issue in a plain text report (newlines are maintained) but becomes less readable in, say, HTML. We should add an optional Narrative element with appropriate keywords, so as to be able to distinguish between the various elements of the narrative (In order to, As a, I want to). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-162) Need to be able to set order of steps for matching
[ http://jira.codehaus.org/browse/JBEHAVE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-162: Assignee: Mauro Talevi Need to be able to set order of steps for matching -- Key: JBEHAVE-162 URL: http://jira.codehaus.org/browse/JBEHAVE-162 Project: JBehave Issue Type: Improvement Affects Versions: 2.2 Reporter: Douglas Padian Assignee: Mauro Talevi Fix For: 2.5 We have run into some difficulty declaring steps that have similar wording such that the matching was incorrect for some of our scenarios. For example: We have a line from one of scenarios that looks like this: And the table.testtable with test_1_id of foo has exactly one test_2_id of bar We want this line to match on the following step: @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) But instead the match is always occuring on this step: @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) where $selectColumnName gets interpreted as exactly one test_2_id Can we have an annotation that indicates the order by which the matching occurs? That way, the first step in our example would always get compared first to our example input line instead of step two. For example something like this: @Order(1) @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) @Order(2) @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-162) Need to be able to set order of steps for matching
[ http://jira.codehaus.org/browse/JBEHAVE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-162. -- Resolution: Fixed Need to be able to set order of steps for matching -- Key: JBEHAVE-162 URL: http://jira.codehaus.org/browse/JBEHAVE-162 Project: JBehave Issue Type: Improvement Affects Versions: 2.2 Reporter: Douglas Padian Assignee: Mauro Talevi Fix For: 2.5 We have run into some difficulty declaring steps that have similar wording such that the matching was incorrect for some of our scenarios. For example: We have a line from one of scenarios that looks like this: And the table.testtable with test_1_id of foo has exactly one test_2_id of bar We want this line to match on the following step: @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) But instead the match is always occuring on this step: @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) where $selectColumnName gets interpreted as exactly one test_2_id Can we have an annotation that indicates the order by which the matching occurs? That way, the first step in our example would always get compared first to our example input line instead of step two. For example something like this: @Order(1) @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) @Order(2) @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-162) Need to be able to set order of steps for matching
[ http://jira.codehaus.org/browse/JBEHAVE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210982#action_210982 ] Mauro Talevi commented on JBEHAVE-162: -- Added optional priority attribute to step method annotations (@Given, @When, @Then), to allow ordering or priotisation of methods whose regex patterns both match the same text step. To prioritise the less-greedy pattern, simply give it a higher priority (which by default is zero): @Given(value = the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue, priority=1) will take precendence over @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) Need to be able to set order of steps for matching -- Key: JBEHAVE-162 URL: http://jira.codehaus.org/browse/JBEHAVE-162 Project: JBehave Issue Type: Improvement Affects Versions: 2.2 Reporter: Douglas Padian Assignee: Mauro Talevi Fix For: 2.5 We have run into some difficulty declaring steps that have similar wording such that the matching was incorrect for some of our scenarios. For example: We have a line from one of scenarios that looks like this: And the table.testtable with test_1_id of foo has exactly one test_2_id of bar We want this line to match on the following step: @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) But instead the match is always occuring on this step: @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) where $selectColumnName gets interpreted as exactly one test_2_id Can we have an annotation that indicates the order by which the matching occurs? That way, the first step in our example would always get compared first to our example input line instead of step two. For example something like this: @Order(1) @Given(the $tableName with $whereColumnName of $whereColumnValue has exactly one $selectColumnName of $selectColumnValue) @Order(2) @Given(the $tableName with $whereColumnName of $whereColumnValue has $selectColumnName of $selectColumnValue) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-216) Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods.
[ http://jira.codehaus.org/browse/JBEHAVE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=210983#action_210983 ] Mauro Talevi commented on JBEHAVE-216: -- A solution is now provided by the ability to prioritise step methods (see JBEHAVE-162). All candidate steps, coming from all Steps classes, are collected and prioritised. Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods. -- Key: JBEHAVE-216 URL: http://jira.codehaus.org/browse/JBEHAVE-216 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.4 Reporter: Cristiano Gavião Fix For: 2.5 With the addition of the GivenScenarios feature, almost often will be necessary to inform more than one StepsCandidate class for one Scenario class. The problem is that those StepsCandidates could have same methods, or could be extending the same parent class and sharing same method. Jbehave will get the first occurrence of method that match textual sentence, which not necessarily will be the desired one. So I would like that jbehave had some way to stablish a weight, or an order, or maybe indicate a default steps class (or anything like that) where I could indicate which is the best path it should be taken. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Reopened: (JBEHAVE-239) Add @BeforeStory and @AfterStory annotations in candidate steps
[ http://jira.codehaus.org/browse/JBEHAVE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-239: -- Add @BeforeStory and @AfterStory annotations in candidate steps --- Key: JBEHAVE-239 URL: http://jira.codehaus.org/browse/JBEHAVE-239 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5 As requested on user list, there are usecases when setup/tear down steps are required at story level (i.e. for multiple scenarios) and not at single scenario level (dealt by @BeforeScenario/@AfterScenario annotations). Equivalent story-level annotations @BeforeStory/@AfterStory would address these usecases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-239) Add @BeforeStory and @AfterStory annotations in candidate steps
[ http://jira.codehaus.org/browse/JBEHAVE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=211581#action_211581 ] Mauro Talevi commented on JBEHAVE-239: -- Added uponEmbedded=[true|false] attribute to @Before/@AfterStory annotations. Add @BeforeStory and @AfterStory annotations in candidate steps --- Key: JBEHAVE-239 URL: http://jira.codehaus.org/browse/JBEHAVE-239 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5 As requested on user list, there are usecases when setup/tear down steps are required at story level (i.e. for multiple scenarios) and not at single scenario level (dealt by @BeforeScenario/@AfterScenario annotations). Equivalent story-level annotations @BeforeStory/@AfterStory would address these usecases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-239) Add @BeforeStory and @AfterStory annotations in candidate steps
[ http://jira.codehaus.org/browse/JBEHAVE-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-239. -- Resolution: Fixed Add @BeforeStory and @AfterStory annotations in candidate steps --- Key: JBEHAVE-239 URL: http://jira.codehaus.org/browse/JBEHAVE-239 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5 As requested on user list, there are usecases when setup/tear down steps are required at story level (i.e. for multiple scenarios) and not at single scenario level (dealt by @BeforeScenario/@AfterScenario annotations). Equivalent story-level annotations @BeforeStory/@AfterStory would address these usecases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Reopened: (JBEHAVE-216) Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods.
[ http://jira.codehaus.org/browse/JBEHAVE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-216: -- Rather than resolving it as Won't Fix, re-opening and descoping this features in case it does turn out to be needed. Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods. -- Key: JBEHAVE-216 URL: http://jira.codehaus.org/browse/JBEHAVE-216 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.4 Reporter: Cristiano Gavião With the addition of the GivenScenarios feature, almost often will be necessary to inform more than one StepsCandidate class for one Scenario class. The problem is that those StepsCandidates could have same methods, or could be extending the same parent class and sharing same method. Jbehave will get the first occurrence of method that match textual sentence, which not necessarily will be the desired one. So I would like that jbehave had some way to stablish a weight, or an order, or maybe indicate a default steps class (or anything like that) where I could indicate which is the best path it should be taken. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-216) Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods.
[ http://jira.codehaus.org/browse/JBEHAVE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-216: - Fix Version/s: (was: 2.5) Allow to indicate which is the weight of each StepsCandidate class used by a Scenario class to resolve duplicated methods. -- Key: JBEHAVE-216 URL: http://jira.codehaus.org/browse/JBEHAVE-216 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.4 Reporter: Cristiano Gavião With the addition of the GivenScenarios feature, almost often will be necessary to inform more than one StepsCandidate class for one Scenario class. The problem is that those StepsCandidates could have same methods, or could be extending the same parent class and sharing same method. Jbehave will get the first occurrence of method that match textual sentence, which not necessarily will be the desired one. So I would like that jbehave had some way to stablish a weight, or an order, or maybe indicate a default steps class (or anything like that) where I could indicate which is the best path it should be taken. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-245) Abstract scenarios should not be executed
Abstract scenarios should not be executed - Key: JBEHAVE-245 URL: http://jira.codehaus.org/browse/JBEHAVE-245 Project: JBehave Issue Type: Improvement Components: Ant extension, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.1 Automatically exclude scenario classes that are abstract. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-245) Abstract scenarios should not be executed
[ http://jira.codehaus.org/browse/JBEHAVE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-245. -- Resolution: Fixed Abstract scenarios should not be executed - Key: JBEHAVE-245 URL: http://jira.codehaus.org/browse/JBEHAVE-245 Project: JBehave Issue Type: Improvement Components: Ant extension, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.1 Automatically exclude scenario classes that are abstract. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Reopened: (JBEHAVE-250) onfiguration/ if missing for Maven/Ant needs better exception handling and console output
[ http://jira.codehaus.org/browse/JBEHAVE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-250: -- onfiguration/ if missing for Maven/Ant needs better exception handling and console output --- Key: JBEHAVE-250 URL: http://jira.codehaus.org/browse/JBEHAVE-250 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 2.5 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 2.5.1 fixed in CL 1602 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-250) Provide better exception handling when Maven/Ant fails with classloader injected
[ http://jira.codehaus.org/browse/JBEHAVE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-250: - Description: When Maven/Ant execution of a scenario with injected classloader, provide better communication of what is happening. (was: fixed in CL 1602) Summary: Provide better exception handling when Maven/Ant fails with classloader injected (was: onfiguration/ if missing for Maven/Ant needs better exception handling and console output) Fixed in CL 1602. Provide better exception handling when Maven/Ant fails with classloader injected Key: JBEHAVE-250 URL: http://jira.codehaus.org/browse/JBEHAVE-250 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 2.5 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 2.5.1 When Maven/Ant execution of a scenario with injected classloader, provide better communication of what is happening. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-250) Provide better exception handling when Maven/Ant fails with classloader injected
[ http://jira.codehaus.org/browse/JBEHAVE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-250. -- Resolution: Fixed Provide better exception handling when Maven/Ant fails with classloader injected Key: JBEHAVE-250 URL: http://jira.codehaus.org/browse/JBEHAVE-250 Project: JBehave Issue Type: Improvement Components: Core Affects Versions: 2.5 Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor Fix For: 2.5.1 When Maven/Ant execution of a scenario with injected classloader, provide better communication of what is happening. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Deleted: (JBEHAVE-249) Abstract scenario classes need should never be added to list of ones to instantiate regardless of include/exclude settings in Maven or Ant
[ http://jira.codehaus.org/browse/JBEHAVE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi deleted JBEHAVE-249: - Abstract scenario classes need should never be added to list of ones to instantiate regardless of include/exclude settings in Maven or Ant -- Key: JBEHAVE-249 URL: http://jira.codehaus.org/browse/JBEHAVE-249 Project: JBehave Issue Type: Bug Reporter: Paul Hammant Assignee: Paul Hammant Priority: Minor fixed in r1597 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-208) Ability to have comments in scenarios
[ http://jira.codehaus.org/browse/JBEHAVE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-208. -- Resolution: Duplicate Duplicate of JBEHAVE-163 Ability to have comments in scenarios - Key: JBEHAVE-208 URL: http://jira.codehaus.org/browse/JBEHAVE-208 Project: JBehave Issue Type: Improvement Reporter: Nino Martinez Ability to have comments in scenarios, not before. Between sceneario steps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-156) Allow resolution of multiple textual scenarios from a single Java scenario
[ http://jira.codehaus.org/browse/JBEHAVE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-156: - Fix Version/s: 3.0 Issue Type: New Feature (was: Improvement) Allow resolution of multiple textual scenarios from a single Java scenario -- Key: JBEHAVE-156 URL: http://jira.codehaus.org/browse/JBEHAVE-156 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.0 Reporter: Mauro Talevi Fix For: 3.0 As a scenario runner, I want to be able to run multiple textual scenarios from the same Java Scenario class, using a single Steps class instance that contains all my steps. The main refactor (backward-compatible) would be to add a method to ScenarioNameResolver ListString resolveAll(Class? extends Scenario scenarioClass); which as a special case returns a single path. In the implementation we'd also need to provide some way to configure which textual scenarios are to run. This would be useful as a start of a web or wiki-based scenario runner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-247) jBehave should be more intelligent/flexible with regards to priortisation of steps
[
http://jira.codehaus.org/browse/JBEHAVE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-247:
-
Fix Version/s: 3.0
Issue Type: New Feature (was: Improvement)
jBehave should be more intelligent/flexible with regards to priortisation of
steps
--
Key: JBEHAVE-247
URL: http://jira.codehaus.org/browse/JBEHAVE-247
Project: JBehave
Issue Type: New Feature
Reporter: Stephen Cresswell
Priority: Minor
Fix For: 3.0
Attachments: LevenshteinDistance.java,
PrioritizableUnmatchedToPendingStepCreator.java
BDD's strength relies on being able to write fluent scenarios. jBehave's
support for this is very good, but there is still room for improvement. For
example a typical scenario might read...
{quote}
Scenario: Schedule Patient Discharge
Given a medical patient called Bob Holness who is not medically fit
When I change Bob's state to medically fit
And select a discharge time of tomorrow morning
And select a discharge complexity of 3
{color:red}Then Bob's discharge schedule should be displayed on the ward
board{color}
{quote}
Now in a related scenario let's say I want to cancel while rescheduling a
discharge...
Scenario: Cancel Rescheduling Patient Discharge
{quote}
Given a medical patient called Bob Holness who already has a discharge
schedule
When I reiterate that Bob's state is medically fit
And select a discharge time of tomorrow morning
And cancel the discharge schedule
{color:red}Then Bob's *old* discharge schedule should be displayed on the
ward board{color}
{quote}
The underlying implementation of assserting Bob's actual discharge schedule
is the same, but I want to emphasise *the expression of intent* through use
of words such as old, new, still, etc.
jBehave partially supports this through aliases
{code:title=MySteps.java|borderStyle=solid}
@Then('''$patient discharge schedule should be displayed on the ward board''')
@Aliases(values=['''$patient old discharge schedule should be displayed on
the ward board'''])
public void assertDischargeScheduleOnWardPage(Patient patient) {
wardBoardPage.assertDischargeSchedule(patient)
}
{code}
The trouble is that the above fails because of the way in which jBehave
matches and prioritises steps. Both Then and Alias steps will match the
sentence
Bob's old discharge schedule should be displayed on the ward board, but
Then will be prioritised based on it's declaration order, causing the value
Bob's old to be passed to the PatientParameterConverter. Since no patient
exists with the name Bob's old, the parameter converter will return null
and the test fails.
Currently the workaround is to reword the steps slightly to prevent both of
them matching...
{quote}Then {color:red}{color}Bob's{color:red}{color} discharge schedule
should be displayed on the ward board
Then {color:red}{color}Bob's{color:red}{color} old discharge schedule
should be displayed on the ward board{quote}
or
{quote}Then Bob's discharge schedule should be displayed on the ward board
Then Bob's old discharge schedule should {color:red}now{color} be displayed
on the ward board{quote}
but both are inferior to the original. A nicer (and fairly easy) solution
would be to base this priortisation on similarity with the string step, using
something like the Levenshtein distance. Harder, but better yet would be to
make the prioritsation configurable.
I've attached the first solution (with lots of printlns so you can see how
well the prioriisation works).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-246) Improve terminology, the distinction between a story and a scenario
[
http://jira.codehaus.org/browse/JBEHAVE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214659#action_214659
]
Mauro Talevi commented on JBEHAVE-246:
--
A story is made of multiple scenarios, not the other way around. A scenario
may depend on other scenarios as a precondition, hence the GivenScenarios
keyword.
That said, yours is a fair issue being raised as in JBehave 2.x the scenario is
the central element, while upon retrospective placing it at story level might
serve the purpose better. Most like this cannot be done without breaking
backward compat, so we'll address it as part of 3.x.
We still need to ensure that the the ability to execute a single scenario, i.e.
a sequence of steps, without lots of unnecessary scaffolding around it, is
satisfied.
Improve terminology, the distinction between a story and a scenario
---
Key: JBEHAVE-246
URL: http://jira.codehaus.org/browse/JBEHAVE-246
Project: JBehave
Issue Type: Improvement
Reporter: James Ravn
Fix For: 3.0
I think it's unfortunate that a scenario file contains several other
scenarios. This leads to some ambiguities in the system, such as the meaning
of a {{GivenScenario}}, and also in communication (is a scenario a collection
or a scenario?).
It also is somewhat a violation of the literal meaning of scenario - which by
definition contains other stories or scenes, not scenarios.
I think while the framework is still relatively young it would be worth
addressing this design choice. Perhaps a scenario should contain stories, or
something like that.
The main concern is removing the ambiguity about what a scenario is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-246) Improve terminology, the distinction between a story and a scenario
[
http://jira.codehaus.org/browse/JBEHAVE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-246:
-
Fix Version/s: 3.0
Improve terminology, the distinction between a story and a scenario
---
Key: JBEHAVE-246
URL: http://jira.codehaus.org/browse/JBEHAVE-246
Project: JBehave
Issue Type: Improvement
Reporter: James Ravn
Fix For: 3.0
I think it's unfortunate that a scenario file contains several other
scenarios. This leads to some ambiguities in the system, such as the meaning
of a {{GivenScenario}}, and also in communication (is a scenario a collection
or a scenario?).
It also is somewhat a violation of the literal meaning of scenario - which by
definition contains other stories or scenes, not scenarios.
I think while the framework is still relatively young it would be worth
addressing this design choice. Perhaps a scenario should contain stories, or
something like that.
The main concern is removing the ambiguity about what a scenario is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-234) Improve JUnit integration
[ http://jira.codehaus.org/browse/JBEHAVE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-234: - Fix Version/s: 3.0 Improve JUnit integration - Key: JBEHAVE-234 URL: http://jira.codehaus.org/browse/JBEHAVE-234 Project: JBehave Issue Type: Improvement Reporter: Jonathan Ross Fix For: 3.0 As a developer using jBehave running in JUnit in Eclipse, I would like to easily determine 1. how many individual scenarios have passed or failed, and 2. which steps failures occur in What springs to mind, is to wire each scenario up as separate JUnit TestCase (rather than the single 'testScenario()' method). Doing so, I would easily be able to drill down to the individually failing scenarios more easily. Regarding finding out which step failed, short of writing a fully-fledged plug-in, this would be a simple matter of retaining the actual failure exception and setting this in JUnit's test result - the failed step should be in the stack trace reported by JUnit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-252) Improve documentation on scenario and step configuration
Improve documentation on scenario and step configuration Key: JBEHAVE-252 URL: http://jira.codehaus.org/browse/JBEHAVE-252 Project: JBehave Issue Type: Improvement Components: Documentation Reporter: Mauro Talevi Priority: Minor Fix For: 2.5.1 Provide snippets of configuration code to show how to change only selected elements from the defaults, e.g. how to configure the use of a specific StepsMonitor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-253) ClassLoader-aware Spring ApplicationContext factory
ClassLoader-aware Spring ApplicationContext factory --- Key: JBEHAVE-253 URL: http://jira.codehaus.org/browse/JBEHAVE-253 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Priority: Minor Fix For: 2.5.1 Spring's ClasspathXmlApplicationContext does not allow the specification of a ClassLoader. To specify the ClassLoader, one can use a GenericApplicationContext with a ResourceLoader that is ClassLoader-aware. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-253) ClassLoader-aware Spring ApplicationContext factory
[ http://jira.codehaus.org/browse/JBEHAVE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-253. -- Resolution: Fixed ClassLoader-aware Spring ApplicationContext factory --- Key: JBEHAVE-253 URL: http://jira.codehaus.org/browse/JBEHAVE-253 Project: JBehave Issue Type: Improvement Reporter: Mauro Talevi Priority: Minor Fix For: 2.5.1 Spring's ClasspathXmlApplicationContext does not allow the specification of a ClassLoader. To specify the ClassLoader, one can use a GenericApplicationContext with a ResourceLoader that is ClassLoader-aware. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-252) Improve documentation on scenario and step configuration
[ http://jira.codehaus.org/browse/JBEHAVE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-252. -- Resolution: Fixed Improve documentation on scenario and step configuration Key: JBEHAVE-252 URL: http://jira.codehaus.org/browse/JBEHAVE-252 Project: JBehave Issue Type: Improvement Components: Documentation Reporter: Mauro Talevi Priority: Minor Fix For: 2.5.1 Provide snippets of configuration code to show how to change only selected elements from the defaults, e.g. how to configure the use of a specific StepsMonitor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-244) Step parameters should be converted just before the step executes (not when the scenario is parsed)
[
http://jira.codehaus.org/browse/JBEHAVE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-244:
-
Fix Version/s: (was: 2.6)
3.0
Step parameters should be converted just before the step executes (not when
the scenario is parsed)
---
Key: JBEHAVE-244
URL: http://jira.codehaus.org/browse/JBEHAVE-244
Project: JBehave
Issue Type: Improvement
Components: Core
Affects Versions: 2.5
Reporter: Stephen Cresswell
Fix For: 3.0
Attachments: Added_support_for_deferred_parameter_conversion.patch,
BaseSteps.groovy, LazyCandidateStep.groovy
I should be able to use a ParamaterConverter to retrieve an entity from the
database, e.g.
Given an employee called Bob
When I give Bob a pay rise of 10,000 pounds
Then Bob forgets about his embarrassing law suit
{code:title=EmployeeSteps.java|borderStyle=solid}
@Given(an employee called $name)
public void createEmployee(String name) {
new EmployeeBuilder().name(name).buildAndSave();
}
@When(I give $employee a pay rise of $amount pounds)
public void givePayRise(Employee employee, Integer amount) {
employee.increaseSalary(amount);
}
{code}
{code:title=EmployeeConverter.java|borderStyle=solid}
public class EmployeeConverter implements ParamterConverter {
EmployeeRepository repo;
public Object convertValue(String value, Type type) {
return repo.findByFirstName(value)
}
}{code}
The parameter converter would be simple to implement, but currently won't
work without shenanigans because the step arguments are converted when the
step is created, and all the steps in a scenario are created up front,
before any of them are executed. This means that at the time the parameter
converter attempts to retrieve the entity from the database it hasn't been
created.
To get around the problem I've created a LazyCandidateStep class, which only
creates the Step in the perform or doNotPerform methods. This isn't ideals
however because I also have to override Steps.createCandidateStep. I've
attached my workaround as an example.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-254) Review story/steps configuration
[ http://jira.codehaus.org/browse/JBEHAVE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-254: - Description: Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Changes: - Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. - Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. - Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. was: Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. Review story/steps configuration - Key: JBEHAVE-254 URL: http://jira.codehaus.org/browse/JBEHAVE-254 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Fix For: 3.0 Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Changes: - Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. - Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. - Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-156) Allow running of multiple textual stories using a single Java RunnableStory
[ http://jira.codehaus.org/browse/JBEHAVE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-156: - Comment: was deleted (was: Bumping out of 2.2 release until consensus is reached on how to approach problem.) Allow running of multiple textual stories using a single Java RunnableStory Key: JBEHAVE-156 URL: http://jira.codehaus.org/browse/JBEHAVE-156 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.0 Reporter: Mauro Talevi Fix For: 3.0 I want to be able to run multiple textual stories from the same Java RunnableStory, provided they use the same StoryConfiguration and the same CandidateSteps instances. This would avoid the need to define a Java RunnableStory class for each textual story. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-255) Make column separator configurable in ExamplesTable
Make column separator configurable in ExamplesTable --- Key: JBEHAVE-255 URL: http://jira.codehaus.org/browse/JBEHAVE-255 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Priority: Minor Fix For: 3.0 When trying to read from external sources, like a wiki, some characters like | may be reserved and we need to allow for use of others. The parser should allow configuration of other column separators when parsing tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-256) Stories should be retrievable from remote sources
Stories should be retrievable from remote sources - Key: JBEHAVE-256 URL: http://jira.codehaus.org/browse/JBEHAVE-256 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Fix For: 3.0 I want to be able to specify my stories in an external/remote source, e.g. a wiki. The stories resources should then be identifiable via a URL or some such, of which local class path resources are a special case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-257) Migration path from JBehave 2.x to JBehave 3.x
Migration path from JBehave 2.x to JBehave 3.x -- Key: JBEHAVE-257 URL: http://jira.codehaus.org/browse/JBEHAVE-257 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Fix For: 3.0 Document migration path from 2.x to 3.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-156) Allow running of multiple textual stories using a single Java RunnableStory
[ http://jira.codehaus.org/browse/JBEHAVE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-156: - Comment: was deleted (was: This feature may or may not be relevant any more - e.g. the JBehave Web Runner by-passes the Scenario and uses the Configuration and Steps directly. Still useful to discuss if this one-to-one mapping for IDE integration - simple and effective - may not be overcome while still preserving the same simplicity and effectiveness for scenarios that use the same Steps instance. ) Allow running of multiple textual stories using a single Java RunnableStory Key: JBEHAVE-156 URL: http://jira.codehaus.org/browse/JBEHAVE-156 Project: JBehave Issue Type: New Feature Components: Core Affects Versions: 2.0 Reporter: Mauro Talevi Fix For: 3.0 I want to be able to run multiple textual stories from the same Java RunnableStory, provided they use the same StoryConfiguration and the same CandidateSteps instances. This would avoid the need to define a Java RunnableStory class for each textual story. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-256) Stories should be retrievable from external or remote sources
[ http://jira.codehaus.org/browse/JBEHAVE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-256: Assignee: Mauro Talevi Stories should be retrievable from external or remote sources - Key: JBEHAVE-256 URL: http://jira.codehaus.org/browse/JBEHAVE-256 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 I want to be able to specify my stories in an external or remote source, e.g. a file directory or a wiki. The stories resources should then be identifiable via a URL or some such, of which local class path resources are a special case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-256) Stories should be retrievable from external or remote sources
[ http://jira.codehaus.org/browse/JBEHAVE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-256 started by Mauro Talevi. Stories should be retrievable from external or remote sources - Key: JBEHAVE-256 URL: http://jira.codehaus.org/browse/JBEHAVE-256 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 I want to be able to specify my stories in an external or remote source, e.g. a file directory or a wiki. The stories resources should then be identifiable via a URL or some such, of which local class path resources are a special case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-248) Should be able to use JBehave without inheriting from a base class
[ http://jira.codehaus.org/browse/JBEHAVE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216573#action_216573 ] Mauro Talevi commented on JBEHAVE-248: -- There is now a RunnableStoryDelegator (which JUnitStory extends) that can be used to compose the instance of RunnableStory without inheritance. Should be able to use JBehave without inheriting from a base class -- Key: JBEHAVE-248 URL: http://jira.codehaus.org/browse/JBEHAVE-248 Project: JBehave Issue Type: New Feature Components: Core Environment: Any Reporter: David Ron Assignee: Mauro Talevi Fix For: 3.0 Currently, a JBehave test scenario require inheriting from the base Scenario class. Certain other test frameworks may also require inheritance, but multiple inheritance is not allowed in Java. For this reason, configuration of a delegate Scenario may be preferred. I created a blog entry with the necessary code to accomplish this: http://blog.davidron.com/2009/12/breaking-jbehave-inheritance-hierarchy.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-254) Review story/steps configuration
[ http://jira.codehaus.org/browse/JBEHAVE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-254: Assignee: Mauro Talevi Review story/steps configuration - Key: JBEHAVE-254 URL: http://jira.codehaus.org/browse/JBEHAVE-254 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Changes: - Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. - Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. - Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-255) Make column separator configurable in ExamplesTable
[ http://jira.codehaus.org/browse/JBEHAVE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-255. -- Resolution: Fixed Made table column separator configurable. Parser retrieves configuration via keywords, like any other configurable element used in parsing. Updated i18n trader example to show it in action. Make column separator configurable in ExamplesTable --- Key: JBEHAVE-255 URL: http://jira.codehaus.org/browse/JBEHAVE-255 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 When trying to read from external sources, like a wiki, some characters like | may be reserved and we need to allow for use of others. The parser should allow configuration of other column separators when parsing tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-259) ClassLoader not injected by default when running stories via CLI
ClassLoader not injected by default when running stories via CLI Key: JBEHAVE-259 URL: http://jira.codehaus.org/browse/JBEHAVE-259 Project: JBehave Issue Type: Improvement Components: Ant extension, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 In Ant and Maven plugin, set default value of classLoaderInjected=false by default. The refactors in the story configuration have made class loader injection redundant for most use cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-259) ClassLoader not injected by default when running stories via CLI
[ http://jira.codehaus.org/browse/JBEHAVE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-259. -- Resolution: Fixed ClassLoader not injected by default when running stories via CLI Key: JBEHAVE-259 URL: http://jira.codehaus.org/browse/JBEHAVE-259 Project: JBehave Issue Type: Improvement Components: Ant extension, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 In Ant and Maven plugin, set default value of classLoaderInjected=false by default. The refactors in the story configuration have made class loader injection redundant for most use cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-261) New syntax for Given with many parameters
[
http://jira.codehaus.org/browse/JBEHAVE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-261:
-
Fix Version/s: (was: 2.5.1)
New syntax for Given with many parameters
-
Key: JBEHAVE-261
URL: http://jira.codehaus.org/browse/JBEHAVE-261
Project: JBehave
Issue Type: Improvement
Components: Core
Reporter: Bruno Bieth
A given step might look like :
{code}Given a person (first name) Bruno (last name) Bieth born 2010-01-01 in
Tombouctou living in Canada driving 10,000 miles per year{code}
It can be hard to read. Passed a certain amount of parameters I suggest the
following syntax :
{code}
Given a person
- First Name : Bruno
- Last Name : Bieth
- Birth date : 2010-01-01
- Birth country : Tombouctou
- Country of residency : Canada
- Miles driven per year : 10,000
{code}
The java code would look like :
{code}
@GivenDetail( a person )
public void aPerson(
@Named(First Name) String firstName,
@Named(Last Name) String lastName,
@Named(Birth date) DateTime birthDate,
@Named(Birth country) String birthCountry,
@Named(Country of residency) String countryOfResidency,
@Named(Miles driven per year) Integer milesPerYear
) {
person = new
Person(firstName,lastName,birthDate,birthCountry,countryOfResidency,milesPerYear);
}
{code}
The factory could use another CandidateSteps instance, say :
{code}
public class DetailedSteps implements CandidateSteps {
private CandidateSteps delegate;
private StepsConfiguration configuration;
private Object instance;
public DetailedSteps(StepsConfiguration configuration, CandidateSteps
delegate, Object instance) {
this.configuration = configuration;
this.delegate = delegate;
this.instance = instance;
}
@Override
public CandidateStep[] getSteps() {
return getSteps( instance.getClass() );
}
@Override
public CandidateStep[] getSteps(Class? stepsClass) {
ListCandidateStep steps = new ArrayListCandidateStep(
Arrays.asList( delegate.getSteps(stepsClass)));
for( Method method : stepsClass.getMethods() ) {
GivenDetail annotation =
method.getAnnotation(GivenDetail.class);
if( annotation != null ) {
steps.add( createGivenDetail( method,
annotation ) );
}
}
return steps.toArray(new CandidateStep[steps.size()]);
}
private CandidateStep createGivenDetail(final Method method,
GivenDetail annotation) {
return new CandidateStep(annotation.value(),
annotation.priority(), StepType.GIVEN, method, instance, new
StepPatternBuilder() {
@Override
public String[] extractGroupNames(String string) {
ListString names = new ArrayListString();
for( Annotation[] annotations :
method.getParameterAnnotations() ) {
for( Annotation annotation :
annotations ) {
if( annotation instanceof Named
) {
names.add(
((Named)annotation).value() );
}
}
}
return names.toArray(new String[names.size()]);
}
@Override
public Pattern buildPattern(String matchThis) {
String[] groups = extractGroupNames();
String pattern = matchThis.replaceAll( ,
s+ );
for( String group : groups ) {
pattern += \\s+-\\s+ +
group.replaceAll( , s+ ) + \\s*:\\s+(.*);
}
return Pattern.compile( pattern );
}
},configuration.getParameterConverters(),configuration.getStartingWordsByType());
}
@Override
public ListStep runAfterScenario() {
return delegate.runAfterScenario();
}
@Override
public ListStep runAfterStory(boolean embeddedStory) {
return delegate.runAfterStory(embeddedStory);
}
@Override
public ListStep runBeforeScenario() {
[jbehave-dev] [jira] Commented: (JBEHAVE-258) Annotation for ParameterConverter
[
http://jira.codehaus.org/browse/JBEHAVE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216595#action_216595
]
Mauro Talevi commented on JBEHAVE-258:
--
Interesting stuff, Bruno. My only comment is that the annotation route might
work nicely with converters that have default constructors, but how do we
handle those that take parameters upon instantiation. It might get pretty
messy.
Annotation for ParameterConverter
-
Key: JBEHAVE-258
URL: http://jira.codehaus.org/browse/JBEHAVE-258
Project: JBehave
Issue Type: Improvement
Reporter: Bruno Bieth
Simplifying adding ParameterConverter to Steps. Here's an example :
{code}
public class DateTimeConverter implements ParameterConverter {
@Override
public boolean accept(Type type) {
return type.equals( DateTime.class );
}
@Override
public Object convertValue(String value, Type type) {
return new DateTime( value );
}
}
{code}
{code}
@ParameterConverters(DateTimeConverter.class)
public class PersonSteps {
private Person person;
private DateTime currentDate;
// ... steps
}
{code}
The ParameterConverters annotation takes an array of TypeConverter :
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ParameterConverters {
Class? extends ParameterConverter[] value();
}
{code}
Here is a steps factory :
{code}
public class ParameterConverterStepsFactory {
public CandidateSteps[] createCandidateSteps(Object... stepsInstances)
throws InstantiationException, IllegalAccessException {
CandidateSteps[] candidateSteps = new
CandidateSteps[stepsInstances.length];
for (int i = 0; i stepsInstances.length; i++) {
Object stepsInstance = stepsInstances[i];
StepsConfiguration configuration;
ParameterConverters parameterConverters =
stepsInstance.getClass().getAnnotation(
ParameterConverters.class );
if( parameterConverters != null ) {
configuration = createConfiguration(
parameterConverters );
} else {
configuration = new StepsConfiguration();
}
candidateSteps[i] = new Steps(configuration, stepsInstance);
}
return candidateSteps;
}
private StepsConfiguration createConfiguration(
ParameterConverters annotation) throws
InstantiationException, IllegalAccessException {
ParameterConverter[] converters = new ParameterConverter[
annotation.value().length ];
for( int i = 0; i converters.length; i ++ ) {
converters[ i ] = annotation.value()[ i ].newInstance();
}
org.jbehave.scenario.steps.ParameterConverters
converterAggregate =
new org.jbehave.scenario.steps.ParameterConverters(
converters );
return new StepsConfiguration( converterAggregate );
}
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-262) Migrate to Git for version control
Migrate to Git for version control --- Key: JBEHAVE-262 URL: http://jira.codehaus.org/browse/JBEHAVE-262 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Task to track migration to Git for source control for JBehave 3.x. JBehave 2.x remains in svn. Git repo is cloned from svn and can be rebased if any changes in 2.x need to merged to 3.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-258) Annotation for ParameterConverter
[
http://jira.codehaus.org/browse/JBEHAVE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216603#action_216603
]
Mauro Talevi commented on JBEHAVE-258:
--
In some cases you do need to provide parameters to the converters, if you want
to make the converters reasonably re-usable.
But I take your point that for those converters that don't need parameters the
annotation strategy is terser and more compact.
BTW, the Steps classes don't need to extend Steps anymore and the converters
configuration can be done
outside of the Steps instance.
Annotation for ParameterConverter
-
Key: JBEHAVE-258
URL: http://jira.codehaus.org/browse/JBEHAVE-258
Project: JBehave
Issue Type: Improvement
Reporter: Bruno Bieth
Simplifying adding ParameterConverter to Steps. Here's an example :
{code}
public class DateTimeConverter implements ParameterConverter {
@Override
public boolean accept(Type type) {
return type.equals( DateTime.class );
}
@Override
public Object convertValue(String value, Type type) {
return new DateTime( value );
}
}
{code}
{code}
@ParameterConverters(DateTimeConverter.class)
public class PersonSteps {
private Person person;
private DateTime currentDate;
// ... steps
}
{code}
The ParameterConverters annotation takes an array of TypeConverter :
{code}
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ParameterConverters {
Class? extends ParameterConverter[] value();
}
{code}
Here is a steps factory :
{code}
public class ParameterConverterStepsFactory {
public CandidateSteps[] createCandidateSteps(Object... stepsInstances)
throws InstantiationException, IllegalAccessException {
CandidateSteps[] candidateSteps = new
CandidateSteps[stepsInstances.length];
for (int i = 0; i stepsInstances.length; i++) {
Object stepsInstance = stepsInstances[i];
StepsConfiguration configuration;
ParameterConverters parameterConverters =
stepsInstance.getClass().getAnnotation(
ParameterConverters.class );
if( parameterConverters != null ) {
configuration = createConfiguration(
parameterConverters );
} else {
configuration = new StepsConfiguration();
}
candidateSteps[i] = new Steps(configuration, stepsInstance);
}
return candidateSteps;
}
private StepsConfiguration createConfiguration(
ParameterConverters annotation) throws
InstantiationException, IllegalAccessException {
ParameterConverter[] converters = new ParameterConverter[
annotation.value().length ];
for( int i = 0; i converters.length; i ++ ) {
converters[ i ] = annotation.value()[ i ].newInstance();
}
org.jbehave.scenario.steps.ParameterConverters
converterAggregate =
new org.jbehave.scenario.steps.ParameterConverters(
converters );
return new StepsConfiguration( converterAggregate );
}
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-261) New syntax for Given with many parameters
[
http://jira.codehaus.org/browse/JBEHAVE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216604#action_216604
]
Mauro Talevi commented on JBEHAVE-261:
--
There is also the question of parsing to consider: having a tabular structure
for table-like input is
much easier to parse. So we could have an ExamplesMap, similar in concept to
ExamplesTable, but
one that only maps key to values and could be expressed as text:
|Name|Series 0110|
|Management Fee|2%|
|Close date|2010-01-01|
New syntax for Given with many parameters
-
Key: JBEHAVE-261
URL: http://jira.codehaus.org/browse/JBEHAVE-261
Project: JBehave
Issue Type: Improvement
Components: Core
Reporter: Bruno Bieth
A given step might look like :
{code}Given a person (first name) Bruno (last name) Bieth born 2010-01-01 in
Tombouctou living in Canada driving 10,000 miles per year{code}
It can be hard to read. Passed a certain amount of parameters I suggest the
following syntax :
{code}
Given a person
- First Name : Bruno
- Last Name : Bieth
- Birth date : 2010-01-01
- Birth country : Tombouctou
- Country of residency : Canada
- Miles driven per year : 10,000
{code}
The java code would look like :
{code}
@GivenDetail( a person )
public void aPerson(
@Named(First Name) String firstName,
@Named(Last Name) String lastName,
@Named(Birth date) DateTime birthDate,
@Named(Birth country) String birthCountry,
@Named(Country of residency) String countryOfResidency,
@Named(Miles driven per year) Integer milesPerYear
) {
person = new
Person(firstName,lastName,birthDate,birthCountry,countryOfResidency,milesPerYear);
}
{code}
The factory could use another CandidateSteps instance, say :
{code}
public class DetailedSteps implements CandidateSteps {
private CandidateSteps delegate;
private StepsConfiguration configuration;
private Object instance;
public DetailedSteps(StepsConfiguration configuration, CandidateSteps
delegate, Object instance) {
this.configuration = configuration;
this.delegate = delegate;
this.instance = instance;
}
@Override
public CandidateStep[] getSteps() {
return getSteps( instance.getClass() );
}
@Override
public CandidateStep[] getSteps(Class? stepsClass) {
ListCandidateStep steps = new ArrayListCandidateStep(
Arrays.asList( delegate.getSteps(stepsClass)));
for( Method method : stepsClass.getMethods() ) {
GivenDetail annotation =
method.getAnnotation(GivenDetail.class);
if( annotation != null ) {
steps.add( createGivenDetail( method,
annotation ) );
}
}
return steps.toArray(new CandidateStep[steps.size()]);
}
private CandidateStep createGivenDetail(final Method method,
GivenDetail annotation) {
return new CandidateStep(annotation.value(),
annotation.priority(), StepType.GIVEN, method, instance, new
StepPatternBuilder() {
@Override
public String[] extractGroupNames(String string) {
ListString names = new ArrayListString();
for( Annotation[] annotations :
method.getParameterAnnotations() ) {
for( Annotation annotation :
annotations ) {
if( annotation instanceof Named
) {
names.add(
((Named)annotation).value() );
}
}
}
return names.toArray(new String[names.size()]);
}
@Override
public Pattern buildPattern(String matchThis) {
String[] groups = extractGroupNames();
String pattern = matchThis.replaceAll( ,
s+ );
for( String group : groups ) {
pattern += \\s+-\\s+ +
group.replaceAll( , s+ ) + \\s*:\\s+(.*);
}
return Pattern.compile( pattern );
}
[jbehave-dev] [jira] Reopened: (JBEHAVE-255) Make column separator configurable in ExamplesTable
[ http://jira.codehaus.org/browse/JBEHAVE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reopened JBEHAVE-255: -- Need to distinguish between header and column separators. Make column separator configurable in ExamplesTable --- Key: JBEHAVE-255 URL: http://jira.codehaus.org/browse/JBEHAVE-255 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 When trying to read from external sources, like a wiki, some characters like | may be reserved and we need to allow for use of others. The parser should allow configuration of other column separators when parsing tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Issue Comment Edited: (JBEHAVE-255) Make column separator configurable in ExamplesTable
[ http://jira.codehaus.org/browse/JBEHAVE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216660#action_216660 ] Mauro Talevi edited comment on JBEHAVE-255 at 4/4/10 4:47 PM: -- Need to distinguish between header and value separators. was (Author: maurotalevi): Need to distinguish between header and column separators. Make column separator configurable in ExamplesTable --- Key: JBEHAVE-255 URL: http://jira.codehaus.org/browse/JBEHAVE-255 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 When trying to read from external sources, like a wiki, some characters like | may be reserved and we need to allow for use of others. The parser should allow configuration of other column separators when parsing tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Issue Comment Edited: (JBEHAVE-254) Review story/steps configuration
[ http://jira.codehaus.org/browse/JBEHAVE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216575#action_216575 ] Mauro Talevi edited comment on JBEHAVE-254 at 4/5/10 2:45 AM: -- Renamed Configuration to StoryConfiguration and converted interface to abstract class. JUnitStory always starts with MostUsefulStoryConfiguration and allows overriding configuration only via useConfiguration(StoryConfiguration) method. Added MostUsefulStepsConfiguration and Unmodifiable[Story|Steps]Configuration decorators. was (Author: maurotalevi): Renamed Configuration to StoryConfiguration and converted interface to abstract class. JUnitStory always starts with MostUsefulStoryConfiguration and allows overriding configuration only via useConfiguration(StoryConfiguration) method. Added MostUsefulStepsConfiguration and Immutable[Story|Steps]Configuration decorators. Review story/steps configuration - Key: JBEHAVE-254 URL: http://jira.codehaus.org/browse/JBEHAVE-254 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Changes: - Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. - Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. - Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-265) Allow annotation-based configuration
Allow annotation-based configuration Key: JBEHAVE-265 URL: http://jira.codehaus.org/browse/JBEHAVE-265 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Fix For: 3.0 Annotations-based configuration can be preferable to some users. Investigate and implement annotation-based alternatives to programmatic configuration, which should always be possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-254) Review story/steps configuration
[ http://jira.codehaus.org/browse/JBEHAVE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216678#action_216678 ] Mauro Talevi commented on JBEHAVE-254: -- Created separate issue JBEHAVE-265 to track annotation-based configuration. Review story/steps configuration - Key: JBEHAVE-254 URL: http://jira.codehaus.org/browse/JBEHAVE-254 Project: JBehave Issue Type: New Feature Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Story and steps configuration should be reviewed to maintain what worked well and remove what did not. Criterias for refactor: - Adopt similar paradigm for story and steps configuration - Elements of the configuration should always have default values and should be overridable singularly, after instantiation - Immutability of configuration can be obtained by decorating a configuration and disabling the use* methods. - Default configurations should always be available to runners and should not be required as parameters in super() invocations. Changes: - Have a base abstract class [Story|Steps]Configuration that holds the elements of the configuration, injectable both via constructor and after instantiation via use* methods. - Have a MostUseful[Story|Steps]Configuration that holds the default configuration that can be used as base for overriding individual elements. - Have an Immutable[Story|Steps]Configuration throwing an exception when use* methods invoked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-255) Make column separator configurable in ExamplesTable
[ http://jira.codehaus.org/browse/JBEHAVE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-255. -- Resolution: Fixed ExamplesTable now accepts as distinct parameters the header and value separators, which both default to |. The separators are also configurable via keywords. Make column separator configurable in ExamplesTable --- Key: JBEHAVE-255 URL: http://jira.codehaus.org/browse/JBEHAVE-255 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 When trying to read from external sources, like a wiki, some characters like | may be reserved and we need to allow for use of others. The parser should allow configuration of other column separators when parsing tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-246) Improve terminology, the distinction between a story and a scenario
[
http://jira.codehaus.org/browse/JBEHAVE-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-246:
-
Component/s: Maven Plugin
Documentation
Core
Ant extension
Improve terminology, the distinction between a story and a scenario
---
Key: JBEHAVE-246
URL: http://jira.codehaus.org/browse/JBEHAVE-246
Project: JBehave
Issue Type: Improvement
Components: Ant extension, Core, Documentation, Maven Plugin
Reporter: James Ravn
Assignee: Mauro Talevi
Fix For: 3.0
I think it's unfortunate that a scenario file contains several other
scenarios. This leads to some ambiguities in the system, such as the meaning
of a {{GivenScenario}}, and also in communication (is a scenario a collection
or a scenario?).
It also is somewhat a violation of the literal meaning of scenario - which by
definition contains other stories or scenes, not scenarios.
I think while the framework is still relatively young it would be worth
addressing this design choice. Perhaps a scenario should contain stories, or
something like that.
The main concern is removing the ambiguity about what a scenario is.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-266) Remove deprecated method and classes from 2.x
Remove deprecated method and classes from 2.x - Key: JBEHAVE-266 URL: http://jira.codehaus.org/browse/JBEHAVE-266 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-266) Remove deprecated method and classes from 2.x
[ http://jira.codehaus.org/browse/JBEHAVE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-266 started by Mauro Talevi. Remove deprecated method and classes from 2.x - Key: JBEHAVE-266 URL: http://jira.codehaus.org/browse/JBEHAVE-266 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-262) Migrate to Git for version control
[ http://jira.codehaus.org/browse/JBEHAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-262 started by Mauro Talevi. Migrate to Git for version control --- Key: JBEHAVE-262 URL: http://jira.codehaus.org/browse/JBEHAVE-262 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Task to track migration to Git for source control for JBehave 3.x. JBehave 2.x remains in svn. Git repo is cloned from svn and can be rebased if any changes in 2.x need to merged to 3.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-262) Migrate to Git for version control
[ http://jira.codehaus.org/browse/JBEHAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216714#action_216714 ] Mauro Talevi commented on JBEHAVE-262: -- Configured POMs for core and web to use git. Maven release prepare works fine and creates tag. The perform stage currently fails because the tag needs to be checked out for the deploy to occur. Workaround is to: git clone url git checkout tag-name mvn deploy -Preporting,distribution Migrate to Git for version control --- Key: JBEHAVE-262 URL: http://jira.codehaus.org/browse/JBEHAVE-262 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Task to track migration to Git for source control for JBehave 3.x. JBehave 2.x remains in svn. Git repo is cloned from svn and can be rebased if any changes in 2.x need to merged to 3.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-262) Migrate to Git for version control
[ http://jira.codehaus.org/browse/JBEHAVE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216716#action_216716 ] Mauro Talevi commented on JBEHAVE-262: -- Also to be considered whether it makes sense to maintain the whole svn directory structure. Could be easier to create git tags/branches from svn ones (to maintain history) but remove file structure. Migrate to Git for version control --- Key: JBEHAVE-262 URL: http://jira.codehaus.org/browse/JBEHAVE-262 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 Task to track migration to Git for source control for JBehave 3.x. JBehave 2.x remains in svn. Git repo is cloned from svn and can be rebased if any changes in 2.x need to merged to 3.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-267) Embeddable StoryRunner should be responsible for all configurable aspects for story running
Embeddable StoryRunner should be responsible for all configurable aspects for story running --- Key: JBEHAVE-267 URL: http://jira.codehaus.org/browse/JBEHAVE-267 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Reporter: Mauro Talevi Fix For: 3.0 In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to a configurable story runner that is the same as is used when running in other embedded environments, e.g. IDE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-267) Embeddable StoryRunner should be responsible for all configurable aspects for story running
[ http://jira.codehaus.org/browse/JBEHAVE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-267 started by Mauro Talevi. Embeddable StoryRunner should be responsible for all configurable aspects for story running --- Key: JBEHAVE-267 URL: http://jira.codehaus.org/browse/JBEHAVE-267 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to a configurable story runner that is the same as is used when running in other embedded environments, e.g. IDE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-267) Embeddable StoryRunner should be responsible for all configurable aspects for story running
[ http://jira.codehaus.org/browse/JBEHAVE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-267: Assignee: Mauro Talevi Embeddable StoryRunner should be responsible for all configurable aspects for story running --- Key: JBEHAVE-267 URL: http://jira.codehaus.org/browse/JBEHAVE-267 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to a configurable story runner that is the same as is used when running in other embedded environments, e.g. IDE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-248) Should be able to use JBehave without inheriting from a base class
[ http://jira.codehaus.org/browse/JBEHAVE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-248: - Comment: was deleted (was: There is now a RunnableStoryDelegator (which JUnitStory extends) that can be used to compose the instance of RunnableStory without inheritance. ) Should be able to use JBehave without inheriting from a base class -- Key: JBEHAVE-248 URL: http://jira.codehaus.org/browse/JBEHAVE-248 Project: JBehave Issue Type: New Feature Components: Core Environment: Any Reporter: David Ron Assignee: Mauro Talevi Fix For: 3.0 Currently, a JBehave test scenario require inheriting from the base Scenario class. Certain other test frameworks may also require inheritance, but multiple inheritance is not allowed in Java. For this reason, configuration of a delegate Scenario may be preferred. I created a blog entry with the necessary code to accomplish this: http://blog.davidron.com/2009/12/breaking-jbehave-inheritance-hierarchy.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-248) Should be able to use JBehave without inheriting from a base class
[ http://jira.codehaus.org/browse/JBEHAVE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=217578#action_217578 ] Mauro Talevi commented on JBEHAVE-248: -- Look at org.jbehave.examples.trader.spring.SpringTraderRunner in the trader example. It shows how with new embeddable architecture (JBEHAVE-267), users can leverage any framework to run stories. In particular, the example above uses Spring JUnit4 Class Runner. Should be able to use JBehave without inheriting from a base class -- Key: JBEHAVE-248 URL: http://jira.codehaus.org/browse/JBEHAVE-248 Project: JBehave Issue Type: New Feature Components: Core Environment: Any Reporter: David Ron Assignee: Mauro Talevi Fix For: 3.0 Currently, a JBehave test scenario require inheriting from the base Scenario class. Certain other test frameworks may also require inheritance, but multiple inheritance is not allowed in Java. For this reason, configuration of a delegate Scenario may be preferred. I created a blog entry with the necessary code to accomplish this: http://blog.davidron.com/2009/12/breaking-jbehave-inheritance-hierarchy.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-267) StoryEmbedder should be responsible for all configurable aspects of story running
[ http://jira.codehaus.org/browse/JBEHAVE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-267: - Description: In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. A StoryEmbedder should instead be responsible for running stories in the same way, whatever environment it is embedded in, IDE, CLI, web. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to the story embedder. was: In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to a configurable story runner that is the same as is used when running in other embedded environments, e.g. IDE. Summary: StoryEmbedder should be responsible for all configurable aspects of story running (was: Embeddable StoryRunner should be responsible for all configurable aspects for story running) StoryEmbedder should be responsible for all configurable aspects of story running - Key: JBEHAVE-267 URL: http://jira.codehaus.org/browse/JBEHAVE-267 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. A StoryEmbedder should instead be responsible for running stories in the same way, whatever environment it is embedded in, IDE, CLI, web. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to the story embedder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-273) Ensure jbehave-core dependencies are excluded or shaded
Ensure jbehave-core dependencies are excluded or shaded --- Key: JBEHAVE-273 URL: http://jira.codehaus.org/browse/JBEHAVE-273 Project: JBehave Issue Type: Task Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5.2 The shading configuration that builds jbehave-core does not explicitly handle the new 2.5 dependencies, resulting in them being bundled unshaded in jbehave-core.jar. Review which should be excluded from core jar but those that are not should be properly shaded, so not to produce conflicts in classpaths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-273) Ensure jbehave-core dependencies are excluded or shaded
[ http://jira.codehaus.org/browse/JBEHAVE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-273. -- Resolution: Fixed Excluded all dependencies except paranamer, which is shaded. Ensure jbehave-core dependencies are excluded or shaded --- Key: JBEHAVE-273 URL: http://jira.codehaus.org/browse/JBEHAVE-273 Project: JBehave Issue Type: Task Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5.2 The shading configuration that builds jbehave-core does not explicitly handle the new 2.5 dependencies, resulting in them being bundled unshaded in jbehave-core.jar. Review which should be excluded from core jar but those that are not should be properly shaded, so not to produce conflicts in classpaths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-275) Ensure UTF-8 charset encoding is used consistently
Ensure UTF-8 charset encoding is used consistently -- Key: JBEHAVE-275 URL: http://jira.codehaus.org/browse/JBEHAVE-275 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Fix For: 3.0 In order to allow reliable and consistent support for non-English languages, a consistent encoding need to used. The core needs to become stricter about the expected encoding and fails (or at least flag a warning) if a different encoding is used by any character-based content, be it story content, i18n bundles or Steps patterns. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-275) Ensure UTF-8 charset encoding is used consistently
[ http://jira.codehaus.org/browse/JBEHAVE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-275: - Description: In order to allow reliable and consistent support for non-English languages, a consistent encoding needs to be used. The core needs to become stricter about the expected encoding and fails (or at least flag a warning, behaviour to be configurable) if a different encoding is used by any character-based content, be it story content, i18n bundles or Steps patterns. was: In order to allow reliable and consistent support for non-English languages, a consistent encoding need to used. The core needs to become stricter about the expected encoding and fails (or at least flag a warning) if a different encoding is used by any character-based content, be it story content, i18n bundles or Steps patterns. Ensure UTF-8 charset encoding is used consistently -- Key: JBEHAVE-275 URL: http://jira.codehaus.org/browse/JBEHAVE-275 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Fix For: 3.0 In order to allow reliable and consistent support for non-English languages, a consistent encoding needs to be used. The core needs to become stricter about the expected encoding and fails (or at least flag a warning, behaviour to be configurable) if a different encoding is used by any character-based content, be it story content, i18n bundles or Steps patterns. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-276) Clarify the Scenario Reporters example and API
[ http://jira.codehaus.org/browse/JBEHAVE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-276: - Summary: Clarify the Scenario Reporters example and API (was: Clearify the Scenario Reporters example and API) Clarify the Scenario Reporters example and API -- Key: JBEHAVE-276 URL: http://jira.codehaus.org/browse/JBEHAVE-276 Project: JBehave Issue Type: Improvement Components: Documentation Affects Versions: 2.5.2 Environment: Maven and Selenium Reporter: Ricardo S.A. Silva The example for configuration of 'Scenario Reporters' on http://jbehave.org/reference/stable/reports.html is not clear. The code appear to be outdated and I am not able to use it. One other point: Is it really necessary use 9 different classes just to save my reports to a TXT file ? It's a common task and it will help a lot if it was more simple. (The classes on examples are: ScenarioNameResolver, UnderscoredCamelCaseResolver, PropertyBasedConfiguration, ScenarioDefiner, ClasspathScenarioDefiner, PatternScenarioParser, ScenarioReporter, ScenarioReporterBuilder, FilePrintStreamFactory) I really want to use JBehave, but the Factory/Definer/Builder hell is really boring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-274) Add example showing use of SpringJUnit4ClassRunner
[ http://jira.codehaus.org/browse/JBEHAVE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-274. -- Resolution: Fixed Add example showing use of SpringJUnit4ClassRunner --- Key: JBEHAVE-274 URL: http://jira.codehaus.org/browse/JBEHAVE-274 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.2 A SpringJUnit4ScenarioRunner example to show how the ScenarioRunner can be embbedded into a Spring JUnit support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-277) Reports are outputted to $ANT_HOME/lib instead of target dir
[ http://jira.codehaus.org/browse/JBEHAVE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=218834#action_218834 ] Mauro Talevi commented on JBEHAVE-277: -- Allowed configuration of output directory in builder to be absolute, so it can bypass the class source code location. Updated the TraderScenario configuration to use the absolute directory. The Ant build.xml in the trader example has been used to verify the ability to run scenario reports and render them. Reports are outputted to $ANT_HOME/lib instead of target dir - Key: JBEHAVE-277 URL: http://jira.codehaus.org/browse/JBEHAVE-277 Project: JBehave Issue Type: Bug Components: Ant extension Affects Versions: 2.5, 2.5.1 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Critical Fix For: 2.5.2 As reported by Ben Sullivan, when running scenarios via Ant CLI, the reports are being outputted to $ANT_HOME/lib instead of target dir. Problem stems from the fact that the FilePrintStreamFactory uses the scenarioClass.getProtectionDomain().getCodeSource().getLocation().getFile(); to identify the output dir. The classloading of Ant by default must be setting the code source location to $ANT_HOME/lib. Need to find a way to configure Ant classloading or allow explicit setting of the output directory (currently only the entire output file of the print stream is configurable, which makes it pretty useless for running with multiple scenarios). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-279) GivenScenarios runs called scenario as PENDING not the implemented version
[ http://jira.codehaus.org/browse/JBEHAVE-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219602#action_219602 ] Mauro Talevi commented on JBEHAVE-279: -- Warren, you need to add *all* the Steps instances that your Scenario will need to match the steps. So, e.g., in UserPlacesAnOrder (which requires both login and order steps) you need addSteps(new LoginSteps(), new PlaceOrderSteps()); and not just addSteps(new PlaceOrderSteps()); else the scenario won't know how to match the login steps, as you are experiencing. GivenScenarios runs called scenario as PENDING not the implemented version -- Key: JBEHAVE-279 URL: http://jira.codehaus.org/browse/JBEHAVE-279 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 2.5.1 Environment: Eclipse, JDK1.5, MacOS Reporter: Warren Muller Priority: Minor Attachments: bdd1.jar We are trying to use GivenScenarios but when the scenario containing it runs it generate the PENDING steps not the actual steps. When the called scenario is run independently it runs fine. My step implementation are simply printlns. This is just running in Eclipse with jbehave-core-2.5.1. Any idea what we could be missing here. As a workaround I can embed the steps method for the first scenario before the steps method of the second then it works as expected. Please see attached source in bdd1.jar tx Warren 1. user_logs_in_successfully Given I am not logged in When I log in as Liz with a password abc Then I should see a message, Welcome, Liz! output: runBeforeScenario logged out login for user: csm with password: abc checkMessage: Welcome, Liz! runThisAfterScenarioAny runThisAfterScenarioSuccess 2. user_places_an_order Scenario: User logs in and places an order GivenScenarios: com/test/examples/scenarios/user_logs_in_successfully.scenario When I place an order Then I should see a message, Order placed output: (com/test/examples/scenarios/user_logs_in_successfully.scenario) Scenario: Given I am not logged in (PENDING) When I log in as service with a password service (PENDING) Then I should see a message, Welcome, CSM! (NOT PERFORMED) placing Order checkMessage: Order placed 3. Run user_places_an_order with workaround (embedded steps method). Interesting is that the before and after steps of the first steps class is run in the second as well. output: runBeforeScenario logged out login for user: Liz with password: abc checkMessage: Welcome, Liz! runThisAfterScenarioAny runThisAfterScenarioSuccess runBeforeScenario placing Order checkMessage: Order placed runThisAfterScenarioAny runThisAfterScenarioSuccess -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-278) 'And' Step (AndStep) ignores CandidateStep step
[
http://jira.codehaus.org/browse/JBEHAVE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi resolved JBEHAVE-278.
--
Resolution: Fixed
'And' Step (AndStep) ignores CandidateStep step
type
--
Key: JBEHAVE-278
URL: http://jira.codehaus.org/browse/JBEHAVE-278
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 2.5.1
Reporter: Tim Moore
Assignee: Mauro Talevi
Fix For: 2.5.2
On http://jbehave.org/reference/latest/concepts.html it states:
A step starting with And assumes the same meaning of the previous step
but this clearly isn't the case in practise, nor does it even require any
preceeding step type to be defined. For example with:
public class Steps extends org.jbehave.scenario.steps.Steps {
@When(the wind blows)
public void theWindBlows() { System.err.println(when it blows then boom);
}
@Given(the wind blows)
public void theWindBlows2() { System.err.println(given it blows then
boom); }
}
Scenario: Test
And the wind blows
Given the wind blows
And the wind blows
When the wind blows
And the wind blows
Outputs:
when it blows then boom
given it blows then boom
when it blows then boom
when it blows then boom
when it blows then boom
Obviously you wouldn't intend to start your scenario with an AndStep, but
it's easy enough to get there (or produce one of the other problems) if you
are copying/editing scenarios. I think it would be better if AndSteps assume
the meaning of the previous step, as intended(?) according to the web
documentation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-277) Reports are outputted to $ANT_HOME/lib instead of target dir
[ http://jira.codehaus.org/browse/JBEHAVE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-277. -- Resolution: Fixed Reports are outputted to $ANT_HOME/lib instead of target dir - Key: JBEHAVE-277 URL: http://jira.codehaus.org/browse/JBEHAVE-277 Project: JBehave Issue Type: Bug Components: Ant extension Affects Versions: 2.5, 2.5.1 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Critical Fix For: 2.5.2 As reported by Ben Sullivan, when running scenarios via Ant CLI, the reports are being outputted to $ANT_HOME/lib instead of target dir. Problem stems from the fact that the FilePrintStreamFactory uses the scenarioClass.getProtectionDomain().getCodeSource().getLocation().getFile(); to identify the output dir. The classloading of Ant by default must be setting the code source location to $ANT_HOME/lib. Need to find a way to configure Ant classloading or allow explicit setting of the output directory (currently only the entire output file of the print stream is configurable, which makes it pretty useless for running with multiple scenarios). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-277) Reports are outputted to $ANT_HOME/lib instead of target dir
[ http://jira.codehaus.org/browse/JBEHAVE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=219610#action_219610 ] Mauro Talevi commented on JBEHAVE-277: -- The ScenarioReporterBuilder now requires explicit invocation of withDefaultFormats() after the setting of the output*() methods to pick up the overridden output specification. Reports are outputted to $ANT_HOME/lib instead of target dir - Key: JBEHAVE-277 URL: http://jira.codehaus.org/browse/JBEHAVE-277 Project: JBehave Issue Type: Bug Components: Ant extension Affects Versions: 2.5, 2.5.1 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Critical Fix For: 2.5.2 As reported by Ben Sullivan, when running scenarios via Ant CLI, the reports are being outputted to $ANT_HOME/lib instead of target dir. Problem stems from the fact that the FilePrintStreamFactory uses the scenarioClass.getProtectionDomain().getCodeSource().getLocation().getFile(); to identify the output dir. The classloading of Ant by default must be setting the code source location to $ANT_HOME/lib. Need to find a way to configure Ant classloading or allow explicit setting of the output directory (currently only the entire output file of the print stream is configurable, which makes it pretty useless for running with multiple scenarios). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-278) 'And' Step (AndStep) ignores CandidateStep step
[
http://jira.codehaus.org/browse/JBEHAVE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-278:
-
Fix Version/s: 3.0
'And' Step (AndStep) ignores CandidateStep step
type
--
Key: JBEHAVE-278
URL: http://jira.codehaus.org/browse/JBEHAVE-278
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 2.5.1
Reporter: Tim Moore
Assignee: Mauro Talevi
Fix For: 2.5.2, 3.0
On http://jbehave.org/reference/latest/concepts.html it states:
A step starting with And assumes the same meaning of the previous step
but this clearly isn't the case in practise, nor does it even require any
preceeding step type to be defined. For example with:
public class Steps extends org.jbehave.scenario.steps.Steps {
@When(the wind blows)
public void theWindBlows() { System.err.println(when it blows then boom);
}
@Given(the wind blows)
public void theWindBlows2() { System.err.println(given it blows then
boom); }
}
Scenario: Test
And the wind blows
Given the wind blows
And the wind blows
When the wind blows
And the wind blows
Outputs:
when it blows then boom
given it blows then boom
when it blows then boom
when it blows then boom
when it blows then boom
Obviously you wouldn't intend to start your scenario with an AndStep, but
it's easy enough to get there (or produce one of the other problems) if you
are copying/editing scenarios. I think it would be better if AndSteps assume
the meaning of the previous step, as intended(?) according to the web
documentation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-280) Review MostUsefulStoryConfiguration defaults
Review MostUsefulStoryConfiguration defaults Key: JBEHAVE-280 URL: http://jira.codehaus.org/browse/JBEHAVE-280 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new PrintStreamOutput() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-281) Multiple And steps are not matched
Multiple And steps are not matched -- Key: JBEHAVE-281 URL: http://jira.codehaus.org/browse/JBEHAVE-281 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 2.5.2 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Blocker Fix For: 2.5.3 Regression introduced by JBEHAVE-278, whereby when multiple And steps are encountered only the first is matched, while from the second is it marked as Pending. Cause lies in the fact that JBEHAVE-278 introduced concept of previous step for matching purposes, but this should be the latest non And step. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-281) Multiple And steps are not matched
[ http://jira.codehaus.org/browse/JBEHAVE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-281. -- Resolution: Fixed Multiple And steps are not matched -- Key: JBEHAVE-281 URL: http://jira.codehaus.org/browse/JBEHAVE-281 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 2.5.2 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Blocker Fix For: 2.5.3 Regression introduced by JBEHAVE-278, whereby when multiple And steps are encountered only the first is matched, while from the second is it marked as Pending. Cause lies in the fact that JBEHAVE-278 introduced concept of previous step for matching purposes, but this should be the latest non And step. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-281) Multiple And steps are not matched
[ http://jira.codehaus.org/browse/JBEHAVE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-281: - Fix Version/s: 3.0 Multiple And steps are not matched -- Key: JBEHAVE-281 URL: http://jira.codehaus.org/browse/JBEHAVE-281 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 2.5.2 Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Blocker Fix For: 2.5.3, 3.0 Regression introduced by JBEHAVE-278, whereby when multiple And steps are encountered only the first is matched, while from the second is it marked as Pending. Cause lies in the fact that JBEHAVE-278 introduced concept of previous step for matching purposes, but this should be the latest non And step. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-282) Using GivenScenarios causes failed tests to be forgotten
[ http://jira.codehaus.org/browse/JBEHAVE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-282: - Fix Version/s: 3.0 Using GivenScenarios causes failed tests to be forgotten Key: JBEHAVE-282 URL: http://jira.codehaus.org/browse/JBEHAVE-282 Project: JBehave Issue Type: Bug Components: Core Affects Versions: 2.5.3 Reporter: Martin Hutchinson Assignee: Mauro Talevi Fix For: 2.5.4, 3.0 Attachments: JBehave-GivenScenarios.zip We have multiple related scenarios within the same JBehave script. This seems to be supported functionality but a major issue came to light earlier: using GivenScenarios at the start of a later scenario will cause any failed scenarios thus far to be forgotten. For example: Story: Test showing that using a given scenario skews the overall result Scenario: Fail GivenScenarios: com/example/sandpit/jbehave/noop Given I do nothing Then I fail Scenario: Succeed GivenScenarios: com/example/sandpit/jbehave/noop Given I do nothing Then I pass The JUnit result for running a scenario with the above script is a pass, even though the I fail step threw an exception. If you remove the GivenScenarios line from the Succeed case then the JUnit result is a fail. Attached is an Eclipse project that demonstrates this. This is a major issue for us: we run the JBehave tests from our build farm in an automated process. This bug would give us the green light for the whole build despite tests failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-283) Report Renderer should be failure aware
Report Renderer should be failure aware --- Key: JBEHAVE-283 URL: http://jira.codehaus.org/browse/JBEHAVE-283 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Affects Versions: 2.5, 2.4 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5.5 If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-284) Allow story embedder to render reports
Allow story embedder to render reports -- Key: JBEHAVE-284 URL: http://jira.codehaus.org/browse/JBEHAVE-284 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Fix For: 3.0 If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration use to generate the reports, so it also reduces need/risk of configuration mismatch between generation and rendering. The rendering should probably be on by default, but with configurable to switch off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-285) Add stepdocs documentation page
Add stepdocs documentation page --- Key: JBEHAVE-285 URL: http://jira.codehaus.org/browse/JBEHAVE-285 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-283) Report Renderer should be failure aware
[ http://jira.codehaus.org/browse/JBEHAVE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-283: - Description: If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. The Ant and Maven entry points should also allow to skip the rendering via a configurable flag. was: If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. Report Renderer should be failure aware --- Key: JBEHAVE-283 URL: http://jira.codehaus.org/browse/JBEHAVE-283 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Affects Versions: 2.4, 2.5 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5.5 If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. The Ant and Maven entry points should also allow to skip the rendering via a configurable flag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-285) Add stepdocs documentation page
[ http://jira.codehaus.org/browse/JBEHAVE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-285. -- Resolution: Fixed Add stepdocs documentation page --- Key: JBEHAVE-285 URL: http://jira.codehaus.org/browse/JBEHAVE-285 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-283) Report Renderer should be failure aware
[ http://jira.codehaus.org/browse/JBEHAVE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-283. -- Resolution: Fixed Report Renderer should be failure aware --- Key: JBEHAVE-283 URL: http://jira.codehaus.org/browse/JBEHAVE-283 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Affects Versions: 2.4, 2.5 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 2.5.5 If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. The Ant and Maven entry points should also allow to skip the rendering via a configurable flag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-283) Report Renderer should be failure aware
[ http://jira.codehaus.org/browse/JBEHAVE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-283: - Fix Version/s: (was: 2.5.5) 3.0 Report Renderer should be failure aware --- Key: JBEHAVE-283 URL: http://jira.codehaus.org/browse/JBEHAVE-283 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Affects Versions: 2.4, 2.5 Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 If a user wants to run through all scenarios/stories and generate a collective view of failure/pending/success the runner needs to be configured to ignore failure. The report rendering should be failure aware so that after rendering the build can fail if any failures occurred. The Ant and Maven entry points should also allow to skip the rendering via a configurable flag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-285) Add stepdocs documentation page
[ http://jira.codehaus.org/browse/JBEHAVE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-285: - Fix Version/s: (was: 2.5.5) 3.0 Add stepdocs documentation page --- Key: JBEHAVE-285 URL: http://jira.codehaus.org/browse/JBEHAVE-285 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-285) Add stepdocs documentation page
[ http://jira.codehaus.org/browse/JBEHAVE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-285: - Fix Version/s: 2.5.5 Add stepdocs documentation page --- Key: JBEHAVE-285 URL: http://jira.codehaus.org/browse/JBEHAVE-285 Project: JBehave Issue Type: Task Components: Documentation Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 2.5.5, 3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-284) Allow story embedder to render reports
[ http://jira.codehaus.org/browse/JBEHAVE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-284 started by Mauro Talevi. Allow story embedder to render reports -- Key: JBEHAVE-284 URL: http://jira.codehaus.org/browse/JBEHAVE-284 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration use to generate the reports, so it also reduces need/risk of configuration mismatch between generation and rendering. The rendering should probably be on by default, but with configurable to switch off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-280) Review MostUsefulStoryConfiguration defaults
[ http://jira.codehaus.org/browse/JBEHAVE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-280: - Description: Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new ConsoleOutput() was: Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new PrintStreamOutput() Review MostUsefulStoryConfiguration defaults Key: JBEHAVE-280 URL: http://jira.codehaus.org/browse/JBEHAVE-280 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new ConsoleOutput() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Work started: (JBEHAVE-280) Review MostUsefulStoryConfiguration defaults
[ http://jira.codehaus.org/browse/JBEHAVE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBEHAVE-280 started by Mauro Talevi. Review MostUsefulStoryConfiguration defaults Key: JBEHAVE-280 URL: http://jira.codehaus.org/browse/JBEHAVE-280 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new PrintStreamOutput() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-284) Allow story embedder to render reports
[ http://jira.codehaus.org/browse/JBEHAVE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-284: Assignee: Mauro Talevi Allow story embedder to render reports -- Key: JBEHAVE-284 URL: http://jira.codehaus.org/browse/JBEHAVE-284 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration use to generate the reports, so it also reduces need/risk of configuration mismatch between generation and rendering. The rendering should probably be on by default, but with configurable to switch off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Created: (JBEHAVE-286) Adopt builder syntax for Story/StepsConfiguration
Adopt builder syntax for Story/StepsConfiguration -- Key: JBEHAVE-286 URL: http://jira.codehaus.org/browse/JBEHAVE-286 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Fix For: 3.0 As proposed by Paul, a builder-style syntax for configuration objects make for much easier reading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Assigned: (JBEHAVE-286) Adopt builder syntax for Story/StepsConfiguration
[ http://jira.codehaus.org/browse/JBEHAVE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi reassigned JBEHAVE-286: Assignee: Mauro Talevi Adopt builder syntax for Story/StepsConfiguration -- Key: JBEHAVE-286 URL: http://jira.codehaus.org/browse/JBEHAVE-286 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 As proposed by Paul, a builder-style syntax for configuration objects make for much easier reading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-284) Allow story embedder to render reports
[ http://jira.codehaus.org/browse/JBEHAVE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-284: - Description: If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration used to generate the reports, so we can reduce need/risk of configuration mismatch between report generation and rendering. The rendering should be on by default, but with ability to disable via a runtime flag. was: If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration use to generate the reports, so it also reduces need/risk of configuration mismatch between generation and rendering. The rendering should probably be on by default, but with configurable to switch off. Allow story embedder to render reports -- Key: JBEHAVE-284 URL: http://jira.codehaus.org/browse/JBEHAVE-284 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 If report rendering were the concern of the story embedder, it would allow the rendering to be performed after the story running (and their raw report generation).We can then avoid the two-phase process currently in 2.x and have it all performed in a single execution via Maven or Ant. The embedder is aware of the configuration used to generate the reports, so we can reduce need/risk of configuration mismatch between report generation and rendering. The rendering should be on by default, but with ability to disable via a runtime flag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-267) StoryEmbedder should be responsible for all configurable aspects of story running
[ http://jira.codehaus.org/browse/JBEHAVE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-267. -- Resolution: Fixed StoryEmbedder should be responsible for all configurable aspects of story running - Key: JBEHAVE-267 URL: http://jira.codehaus.org/browse/JBEHAVE-267 Project: JBehave Issue Type: Improvement Components: Ant extension, Core, Maven Plugin Reporter: Mauro Talevi Assignee: Mauro Talevi Fix For: 3.0 In 2.x, responsibilities are split between the StoryRunner and the Ant task/Maven plugin. E.g. the ability to skip some stories or ignore failure is configured at Ant/Maven level. A StoryEmbedder should instead be responsible for running stories in the same way, whatever environment it is embedded in, IDE, CLI, web. The Ant/Maven layer should become wafer-thin, only responsible for collecting the stories to be run, delegating to the story embedder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-266) Remove deprecated method and classes from 2.x
[ http://jira.codehaus.org/browse/JBEHAVE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-266. -- Resolution: Fixed Remove deprecated method and classes from 2.x - Key: JBEHAVE-266 URL: http://jira.codehaus.org/browse/JBEHAVE-266 Project: JBehave Issue Type: Task Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Resolved: (JBEHAVE-280) Review MostUsefulStoryConfiguration defaults
[ http://jira.codehaus.org/browse/JBEHAVE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi resolved JBEHAVE-280. -- Resolution: Fixed Review MostUsefulStoryConfiguration defaults Key: JBEHAVE-280 URL: http://jira.codehaus.org/browse/JBEHAVE-280 Project: JBehave Issue Type: Improvement Components: Core Reporter: Mauro Talevi Assignee: Mauro Talevi Priority: Minor Fix For: 3.0 Review and update defaults so as to minimise configuration. Following defaults have been shown to be more useful: StoryPathResolver: new UnderscoredCamelCaseResolver(.story) StoryReporter: new ConsoleOutput() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
