Hi Stefan.
Excuse me for wading in halfway through. I just want to add a couple of
observations or suggestions. Firstly, as I have been doing more and more
bdd-style projects, I have evolved into the following code structure:
- app [the application]
- src
- resources
...
- behaviour
- stories [all the story/scenario/given/when/then classes]
- src
- resources
...
- examples [all the object behaviour classes]
- src
- resources
...
- integration [examples that use real services, like databases]
- src
- resources
...
I used to think there was a continuum between describing object
interactions (traditional TDD plus mocking) and describing application
behaviour (stories and scenarios) but I've since concluded that there
are (at least) two discrete levels, hence the directory structure.
(There is probably another one above this for interactions across
multiple system boundaries, but enterprise BDD is still a little way off
- I'm working on it!). I'm trying to come round to Brian Marick's term
of "exemplars" rather than "examples" because it is more correct, but it
just sounds odd to me.
My build starts by compiling up the app classes (sometimes into a jar),
then compiles and runs the example classes /with the app classes on the
classpath/, then compiles and runs the story classes with /both the
examples and app/ classes on the classpath.
This three-stage approach means I know my app doesn't have any
dependencies on any supporting code, and that my story behaviours can
reuse code from my example behaviours (say, Builders or other helper
classes). It also means my app classes are ready to be bundled up and
deployed.
I have found that this is easy using ant (sorry, I'm not a maven user)
with the added benefit that it doesn't require any classpath mojo from
jbehave itself.
I would prefer to keep the classpath magic as simple as possible in
jbehave, so I'd need to see a compelling reason to change Mauro's
existing solution (other than tidying it up - have you /seen/ the code
Mauro writes?)*
Cheers,
Dan
* For the record: Mauro writes some pretty good code :)
Stefan Hübner wrote:
Hi,
Mauro wrote:
Bringing discussion to the list:
[SNIP]
I personally see behaviours as more along the lines of acceptance
testing than unit testing. So
rather than a replacement for JUnit, I would see it a replacement for
Fit.
That said, some people might want to use BDD as a replacement for TDD.
I would aim to find a configurable way to support both paradigms.
So this would boil down to placing behaviours/stories either in
"src/main/java" or "src/test/java" and scoping jbehave either in
compile or test scope.
The switch could be easily supported by a simple boolean configuration
option, I guess. The plugin then would create a classloader upon
either compile scope or test scope classpath elements.
> I took the approach the surefire-plugin is based on. It doesn't
import *any* JUnit-specific classes, but instead loads them into a
completely isolated classloader. Of course this brings some nasty
reflection mechanics as a side effect, though.
>
> The difference to your implementation is, that the patched plugin
doesn't leave the classloading hassles to the jbehave-library. Rather
it puts the jbehave-classes into the same classloader, that serves as
the classloader for the behaviours to be verified. So jbehave is on
the same classpath as the behaviours and nowhere else.
>
> I did some experiments with the hellbound example, put it's sources
into different modules and tried to run the behaviours. The patch
worked fine. So I was happy with it and thought, you'd find it handy
too.
I still need to convince myself of the best approach in this
regard. I don't see "hyper-isolation"
in classloading as necessarily a significant advantage - especially
if offset against other cons or
complications. The current approach is quite simple and configurable
- it takes the libs configured
in a given maven scope and builds a classloader with them. I'll give
it more thought.
Fine. I'll those two classloader approaches a try in different scenarios.
> But either way, I'd just like to see a maven plugin that works,
since I appreciate your effort very much. I do hope seeing the
project gaining momentum in the near future. To me, a maven plugin is
a must though, before I can spread the word.
Sure - and I appreciate your help greatly. I've been snowed under of
late, but I'm aiming to get
some work done (have some other patches to apply) and get out a 1.1
release soon.
Since we're talking about Maven2 support, may I also suggest to update
jbehave's parent- and core-poms? The dependencies should be mentioned
properly. This would help developers great deals.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
