Dan North wrote:
I started down this path and then backed it out.
Thing is, you need the syntactic sugar in the class so you can
returnValue(sheep). This will necessarily vary from framework to
framework (the type of returnValue(Object) in jmock is different from
the equivalent in minimock, b
Title: [jbehave] [615] trunk/core/src/java/jbehave/core/story: [dn] Renamed Scenario.assemble() to Scenario.specify() - note, still need to do this for Story
Revision 615
Author tastapod
Date 2006-12-05 13:36:06 -0600 (Tue, 05 Dec 2006)
Log Message
[dn] Renamed Scenario.assemble() to Scena
Hi folks.
There's an odd recursion bug happening in the newly-factored behaviour
verification. I broke a behaviour method in MultiStepScenarioBehaviour
and found it reported errors in no fewer than six other behaviour
methods! Note - no change to (working) code, just a broken behaviour
metho
I started down this path and then backed it out.
Thing is, you need the syntactic sugar in the class so you can
returnValue(sheep). This will necessarily vary from framework to
framework (the type of returnValue(Object) in jmock is different from
the equivalent in minimock, because it's a para
Ensure is also used as part of the assertion framework. Maybe it
should stay as the core?
As for the Block interface, I believe it is because Runnable does not
declare any exception to throw. A minor plus is that the Block is a
little better named.
Cheers
Shane
On 12/5/06, Mauro Talevi <[EMAI
Joe Walnes wrote:
Just to clarify - is the scope of assemble() to avoid big constructors
or is there another usecase for it?
That's definitely one of the reasons.
Another is to allow the API to evolve over time without necessarily
breaking people's code when a new dependency is ad
Hi,
I was looking into making the mocking framework used by scenarios injectable.
I would:
- pull up to UsingMocks interface methods now found in UsingMiniMock,
UsingJMock ... eg
Mock mock(Class type);
Mock mock(Class type, String name);
Object stub(Class type);
Object stub(Class type, St
Just to clarify - is the scope of assemble() to avoid big constructors
or is there another usecase for it?
That's definitely one of the reasons.
Another is to allow the API to evolve over time without necessarily breaking
people's code when a new dependency is added to the scenarios. It separ
Dan North wrote:
Hi gang.
Please read this all the way through - it probably affects _you_. :)
I reworked a lot of the scenario stuff over the last few days. Mostly it
comes down to this:
1. A MultiStepScenario is made up of a bunch of Steps, defined in an
assemble() method.
2. A Given, Eve
Title: [jbehave] [614] trunk/core/src/java/jbehave/core/story/domain: Removed Scenarios - merged functionality in ScenarioDrivenStory.
Revision 614
Author mauro
Date 2006-12-05 07:05:03 -0600 (Tue, 05 Dec 2006)
Log Message
Removed Scenarios - merged functionality in ScenarioDrivenStory.
M
Title: [jbehave] [613] trunk: Removed redundant method in Scenario - already in super interface HasCleanUp.
Revision 613
Author mauro
Date 2006-12-05 06:30:33 -0600 (Tue, 05 Dec 2006)
Log Message
Removed redundant method in Scenario - already in super interface HasCleanUp.
Modified Paths
You already can. UsingMiniMock has exactly those methods. I just haven't
added them to Ensure yet.
Feel free to add them - it'll save me a small chore :)
Cheers,
Dan
Shane Duan wrote:
Ah. Thanks for the explanation.
Are we going to add it now? In this way, people who are using Java5
can us
Ah. Thanks for the explanation.
Are we going to add it now? In this way, people who are using Java5
can use this style right now.
On 12/5/06, Dan North <[EMAIL PROTECTED]> wrote:
That's what I meant - sorry, didn't explain it very well.
In Ensure we will have pairs of methods, called that(..
That's what I meant - sorry, didn't explain it very well.
In Ensure we will have pairs of methods, called that(...) and
ensureThat(...) for each signature. That way, 1.4 folks can do
Ensure.that(...), and 1.5 people can statically import Ensure and use
ensureThat(...).
Shane Duan wrote:
If
If someone using Java5 with static import, it will be something like
result.doesSomething();
that(result.status(), eq(status));
Are you sure that you don't want the following? I thought that the
old code read better.
result.doesSomething();
ensureThat(result.status(),
Hi Shane.
Annoyingly, we can't use Hamcrest because it's generics-based, and not
designed to be backward-compatible with java 1.4 (our target).
However, I'm creating an abstraction that will make sense to people who
understand Hamcrest, hence the vocabulary switch.
As a post-1.0 activity, I
hamcrest change, eh? :)
I had some fun/pain with it over the weekend.
http://agileworks.blogspot.com/2006/12/so-much-for-java-generics.html
On 5 Dec 2006 08:42:14 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Revision 612 Author tastapod Date 2006-12-05 02:42:05 -0600 (Tue, 05 Dec
20
17 matches
Mail list logo
