Hi Simon,
thanks for your feedback on this. As confirmed by your finding, your
behaviour is simply a consequence of the fact that we moved to using a
Map instead of a List to hold the steps classes.
I would say it's not a best practice to depend on the order of
execution of the @BeforeStories steps. Certainly, it was never a
feature we encouraged or recommended. As it happens, this feature came
with the List impl and went with the Map impl. You may decide to
keep this feature by providing your own impl of the steps factory, or
you may want to consider other forms of dependencies: e.g. using
GivenStories keyword or implementing your own PrioritisingStrategy in
the StepFinder:
http://jbehave.org/reference/stable/prioritising-steps.html
Cheers
On Tue Jan 3 18:15:33 2012, Simon Kent wrote:
Hi Mauro
OK have proved this out by providing my own implementation of the
InstanceStepsFactory, maintaining an ArrayList of ordered steps
classes in the constructor as well as the Map. So instead of returning
the map's keyset (which essentially randomises the order), we return
the ordered list (only used for the return value of stepsTypes). This
then works as per 3.4.3.
So probably nothing to do with "Lazy Loading" - just a side effect of
the Map implementation of the steps list.
However I'd like to check if this was a deliberate change, i.e.
whether this means that you now actively discourage multiple
@BeforeStories steps (in multiple Steps classes) or that you are
trying to discourage any interdependencies (in terms of invocation
order) between them as "best practice"? Otherwise, imho I'd view this
(random ordering) as a regression.
Best regards
Simon
-------- Original Message --------
Subject: Re: [jbehave-user] Lazy loading with 3.5.4
Date: Thu, 22 Dec 2011 19:45:17 +0100
From: Mauro Talevi <[email protected]>
Reply-To: [email protected]
To: [email protected]
Hi Simon,
you can always provide your own impl of InjectableStepsFactory. The
main method returns the instances of the CandidateSteps classes, which
you can instantiate in the order you need.
Cheers
On 22/12/2011 18:41, Simon Kent wrote:
> We are currently using JBehave 3.4.3 and considering an upgrade to
> 3.5.4. However one of the improvements (JBEHAVE-534) adds lazy loading
> of steps classes, which makes the order of loading less deterministic.
> This becomes an issue when we use generic steps classes with
> @BeforeStories annotations which we'd like to assume are actioned up
> front (and hence currently defined earlier in the list of steps
> classes). Can you recommend any way around this?
>
> e.g. with a list of steps : myGenericSteps, myStorySteps
> with 3.4.3 these were executed in this order
> with 3.5.4 they reverse
>
> myGenericSteps :
> @BeforeStories
> public void before1() {
> // want to execute this first
> }
>
> myStorySteps:
> @BeforeStories
> public void before2() {
> // want to execute this second
> }
> @Given
> ..
> @Then
> ..
> etc
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
------------------------------------------------------------------------
Privileged or confidential information may be contained in this
message. If you are not the addressee of this message please notify
the sender by return and thereafter delete the message, and you may
not use, copy, disclose or rely on the information contained in it.
Internet e-mail may be susceptible to data corruption, interception
and unauthorised amendment for which Gresham does not accept
liability. Whilst we have taken reasonable precautions to ensure that
this e-mail and any attachments have been swept for viruses, Gresham
does not accept liability for any damage sustained as a result of
viruses. Statements in this message that do not relate to the business
of Gresham are neither given nor endorsed by the company or its
directors. Gresham Computing plc Registered in England and Wales.
Company No. 01072032 Registered Office: Sopwith House, Brook Avenue,
Warsash, Southampton. Hants. SO31 9ZA Further information about
Gresham Computing can be found on our website: www.gresham-computing.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
