headers
Mauro Talevi (JIRA | 3 Sep 2010 12:12

[jira] Reopened: (JBEHAVE-251) Selenium (under JBehave control) needs to be able to be instansiable at Story as well as Scenario level


     [
http://jira.codehaus.org/browse/JBEHAVE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi reopened JBEHAVE-251:
----------------------------------

      Assignee: Mauro Talevi  (was: Paul Hammant)

Issues should not be closed, but resolved.

> Selenium (under JBehave control) needs to be able to be instansiable at Story as well as Scenario level
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBEHAVE-251
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-251
>             Project: JBehave
>          Issue Type: Improvement
>    Affects Versions: web-2.1.6
>            Reporter: Paul Hammant
>            Assignee: Mauro Talevi
>             Fix For: web-3.0
>
>
> Fixed in CL 1599 - SeleniumSteps is deprecated SeleniumStorySteps and SeleniumScenarioSteps are new

--

-- 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 3 Sep 2010 12:12

[jira] Resolved: (JBEHAVE-251) Selenium (under JBehave control) needs to be able to be instansiable at Story as well as Scenario level


     [
http://jira.codehaus.org/browse/JBEHAVE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi resolved JBEHAVE-251.
----------------------------------

    Resolution: Fixed

> Selenium (under JBehave control) needs to be able to be instansiable at Story as well as Scenario level
> -------------------------------------------------------------------------------------------------------
>
>                 Key: JBEHAVE-251
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-251
>             Project: JBehave
>          Issue Type: Improvement
>    Affects Versions: web-2.1.6
>            Reporter: Paul Hammant
>            Assignee: Mauro Talevi
>             Fix For: web-3.0
>
>
> Fixed in CL 1599 - SeleniumSteps is deprecated SeleniumStorySteps and SeleniumScenarioSteps are new

--

-- 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 4 Sep 2010 15:54

[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:
---------------------------------

    Component/s: Core

> Improve JUnit integration
> -------------------------
>
>                 Key: JBEHAVE-234
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-234
>             Project: JBehave
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ross
>             Fix For: 3.1
>
>
> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 4 Sep 2010 15:54

[jira] Updated: (JBEHAVE-220) Allow per-story and per-scenario meta-information


     [
http://jira.codehaus.org/browse/JBEHAVE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi updated JBEHAVE-220:
---------------------------------

      Priority: Major  (was: Minor)
      Assignee: Mauro Talevi
    Issue Type: New Feature  (was: Improvement)
       Summary: Allow per-story and per-scenario meta-information  (was: Allow per-scenario meta-information)

> Allow per-story and per-scenario meta-information
> -------------------------------------------------
>
>                 Key: JBEHAVE-220
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-220
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Chris Jensen
>            Assignee: Mauro Talevi
>             Fix For: 3.1
>
>
> From a development management perspective, BDD could be extremely useful in helping to track and
understand who is creating specifications and when they are being injected.
> Since requirements like this will vary between users, it would be a good idea to implement as generically
as possible and then provide an example or reference.
> My thoughts on what would be useful in my own situation:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 6 Sep 2010 10:18

[jira] Created: (JBEHAVE-335) Migrate to Wicket as web application framework

Migrate to Wicket as web application framework
----------------------------------------------

                 Key: JBEHAVE-335
                 URL: http://jira.codehaus.org/browse/JBEHAVE-335
             Project: JBehave
          Issue Type: New Feature
          Components: Web Runner
            Reporter: Mauro Talevi
            Assignee: Mauro Talevi
             Fix For: web-3.0

Wicket shares the same philosophy as Waffle (embeddable, pure Java, no XML) and has a wide community
support. 

Users would extend a Wicket Application class to specify configuration and steps instances, similarly to
what done with Waffle Registrar.

--

-- 
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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mauro Talevi (JIRA | 12 Sep 2010 17:00

[jira] Work started: (JBEHAVE-335) Refactor Web Runner to use Wicket as web application framework


     [
http://jira.codehaus.org/browse/JBEHAVE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBEHAVE-335 started by Mauro Talevi.

> Refactor Web Runner to use Wicket as web application framework
> --------------------------------------------------------------
>
>                 Key: JBEHAVE-335
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-335
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Web Runner
>            Reporter: Mauro Talevi
>            Assignee: Mauro Talevi
>             Fix For: web-3.0
>
>
> Wicket shares the same philosophy as Waffle (embeddable, pure Java, no XML) and has a wide community
support. 
> From users' point of view the only change would be extend a Wicket Application class to specify
configuration and steps instances, instead of a Waffle Registrar.
> A doc page should help in migrating from Registrar to Application class.

--

-- 
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
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 12 Sep 2010 17:00

[jira] Updated: (JBEHAVE-335) Refactor Web Runner to use Wicket as web application framework


     [
http://jira.codehaus.org/browse/JBEHAVE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi updated JBEHAVE-335:
---------------------------------

    Description: 
Wicket shares the same philosophy as Waffle (embeddable, pure Java, no XML) and has a wide community
support. 

From users' point of view the only change would be extend a Wicket Application class to specify
configuration and steps instances, instead of a Waffle Registrar.

A doc page should help in migrating from Registrar to Application class.

  was:
Wicket shares the same philosophy as Waffle (embeddable, pure Java, no XML) and has a wide community
support. 

Users would extend a Wicket Application class to specify configuration and steps instances, similarly to
what done with Waffle Registrar.

        Summary: Refactor Web Runner to use Wicket as web application framework  (was: Migrate to Wicket as web
application framework)

> Refactor Web Runner to use Wicket as web application framework
> --------------------------------------------------------------
>
>                 Key: JBEHAVE-335
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Repko (JIRA | 13 Sep 2010 19:32

[jira] Commented: (JBEHAVE-335) Refactor Web Runner to use Wicket as web application framework


    [
http://jira.codehaus.org/browse/JBEHAVE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235096#action_235096
] 

Brian Repko commented on JBEHAVE-335:
-------------------------------------

I have no preference one way or another (Wicket vs Waffle).  If you are looking for same features in an
action-based framework, then I would suggest Stripes or Play.  Component-framework vs
Action-framework doesn't really matter to me.

> Refactor Web Runner to use Wicket as web application framework
> --------------------------------------------------------------
>
>                 Key: JBEHAVE-335
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-335
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Web Runner
>            Reporter: Mauro Talevi
>            Assignee: Mauro Talevi
>             Fix For: web-3.0
>
>
> Wicket shares the same philosophy as Waffle (embeddable, pure Java, no XML) and has a wide community
support. 
> From users' point of view the only change would be extend a Wicket Application class to specify
configuration and steps instances, instead of a Waffle Registrar.
> A doc page should help in migrating from Registrar to Application class.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 14 Sep 2010 15:34

[jira] Updated: (JBEHAVE-192) Allow both relative and full path views for file contents


     [
http://jira.codehaus.org/browse/JBEHAVE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi updated JBEHAVE-192:
---------------------------------

    Fix Version/s:     (was: web-3.0)

> Allow both relative and full path views for file contents
> ---------------------------------------------------------
>
>                 Key: JBEHAVE-192
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-192
>             Project: JBehave
>          Issue Type: Improvement
>    Affects Versions: web-2.1.2
>            Reporter: Mauro Talevi
>            Assignee: Mauro Talevi
>             Fix For: web-2.1.3
>
>
> Useful when the relative path view may fail for some reason.

--

-- 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Talevi (JIRA | 14 Sep 2010 15:34

[jira] Updated: (JBEHAVE-213) Scenario runner form submission should support both GET and POST methods


     [
http://jira.codehaus.org/browse/JBEHAVE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mauro Talevi updated JBEHAVE-213:
---------------------------------

    Fix Version/s:     (was: web-3.0)

> Scenario runner form submission should support both GET and POST methods  
> --------------------------------------------------------------------------
>
>                 Key: JBEHAVE-213
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-213
>             Project: JBehave
>          Issue Type: Improvement
>            Reporter: Mauro Talevi
>            Assignee: Mauro Talevi
>             Fix For: web-2.1.6
>
>
> POST is required for executing very long scenarios - and is now the default. 
> Can be changed via the drop-down selection next to the "Run Scenario" link.

--

-- 
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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane