Hi Mauro,
Thanks, that was about the answer I had hoped for.
Yes, I've used the archetypes, I've tried to reverse-engineer the
questions I had and integrate what I wanted into the then-existing
(pretty complex) Maven+(Jenkins|Eclipse) build process based on that
insight. Making the archetypes work was indeed reasonably OK, finding
out how to think about JBehave from the right angle and then
transferring that into the "real" project was the hard part. By the
way, when researching magen, it seemed to me that file locations and
directory hierarchies are a recurring topic when using maven, even
independent of JBehave.
What I was mostly missing was the thinking /behind/ all the things
that are touched upon in today's tutorials and archetypes. The stuff
that is so obvious to the JBehave pro that you can't even /think/ of
it explicitly, and therefore it isn't written down anywhere. As you,
Mauro, put it: "Sometimes though it's not so easy to judge this
steepness when one is too close to the development." I know that
phenomenon.
I'll give the "getting started" topic a shot over the next days.
As a first idea, I'm thinking of:
-Prerequisites: maven. Maybe there is a good maven tutorial somewhere
we can link to, maybe there is a simple (!) way to experiment with
JBehave without maven. (What is the simplest set-up with JUnitStory in
Eclipse?)
-Basic JBehave concepts
oEmbedder, Embedding, basic execution: How does JBehave get executed
in the first place?
("execution as JUnit" and "execution in maven")
oWhat are the basic phases /within/ JBehave? (I guess: Configuration,
Story loading, matching against step implementations, reporting) How
do they relate by default to maven phases?
oConfiguration and loading stories (StoryLoader)
oStep implementations
oReporting basics
o... and how all this relates to each other.
-A minimal step-by-step-documented maven-set-up (what file goes where
and why, what is the thinking process for the person doing the set-up
/during/ configuration)
This is my current best candidate for "Getting Started". It's pretty
close to what's there, I'd just like to add some details (e.g. maven
and directory conventions) and some overview (how do things relate to
each other).
While writing the above, I started to feel that a lot of this is about
lifecycles: Outside-in
1.There is a lifecycle of the project as a whole. JBehave may be there
from the very start, or it may come in later.
2.There is a lifecycle of the JBehave aspect of the project, i.e.
configuration and story loading
3.There are lifecycles for every story.
4.There are lifecycles for every build run. This has a common part
("basic phases" above) and variation depending on environment: in an
IDE (Junit-integration), in a local build (Console output) or on a CI
server (fancy reporting)
Explaining things "inside-out" (starting from JUnit in Eclipse), then
adding complexity (local build etc.) and climbing the lifecycle ladder
from 4->1 might make the whole thing nicely digestible. I'm not yet
sure what to make out of that, I'd just like to bounce these thoughts
off the experts early.
What do you think?
Is my understanding of how JBehave works technically correct (even if
intensely simplified) so far?
Could these approaches be helpful to lower the barrier of entry even more?
Last but not least, Mauro, could you please get me a JIRA user so I
can raise the JIRA issue according to
http://jbehave.org/reference/stable/how-to-contribute.html
Thanks, all. Have a great weekend.
Best regards, best wishes,
Josef
*From:*Mauro Talevi [mailto:[email protected]]
*Sent:* Freitag, 7. März 2014 09:17
*To:* [email protected]
*Subject:* Re: [jbehave-user] JBehave learning curve
Hi Josef,
I think it's a fair comment to say that JBehave is development-centric
(not necessarily developer-centric though) as its main focus has
always been the ability to support CI. As such it does require some
knowledge in the team with respect to build and SCM technologies and
the likes. It could be qualified as a toolkit - which needs to be
customised and adapted to the project needs. Once set up it can be
used by less technical members of the team.
As for your points below, have you ever tried using archetypes:
http://jbehave.org/reference/stable/archetypes.html
They are meant precisely for the purpose of getting people started
with a simple but working project. There is a
jbehave-spring-archetype which sets up the autowiring of steps classes
using Spring.
That said, we always strive to improve the documentation and make the
learning curve less steep. Sometimes though it's not so easy to
judge this steepness when one is too close to the development.
Help from someone like you who's not a full-time developer would be
very welcome. If you have time to provide a doc page as a patch
that would detail how you'd approach a "getting started" page, it'd be
great.
http://jbehave.org/reference/stable/how-to-contribute.html
Thanks for your feedback.
On 06/03/2014 14:36, Josef Dietl wrote:
Hi Janusz,
Thanks for taking up this topic. I was having similar problems to
get started, and for organizational reasons, I couldn't approach
the group.
I don't mean to offend anybody. Everybody here is incredibly
helpful, and the software is really great. But the learning curve
is wild. Given the deep questions I saw here while lurking, I
wasn't exactly inspired to step up, despite all the helpful
attitude of Mauro and everybody.
A bit about myself: I'm not a full-time developer, I'm a project
manager with a passion for continuous improvement of our
development practices. I'm good enough to occasionally find
something in a code review, to make a prototype or an automated
test, but my focus is on providing the optimal environment for the
development team so that /they/ can maximize their productivity.
So in order to get them to look at JBehave and [T|AT|B]DD, I had
to learn Maven and set up JBehave on my own in a branch of the
project to demonstrate the value-add.
To cut a long story short, once I was through, adding stories and
tests on top of the existing set-up was cool and convincing, but
the path there could have been smoother.
When I was working for the W3C, we had a saying: make the simple
things simple and the hard things possible. JBehave doesn't
exactly work like that, but once I had reached the "hard" things,
I also found traction in the documentation and the sample projects.
I don't have the role to suggest anything here, but I did ask
myself repeatedly whether it wouldn't be possible to be more
explicit about the first steps. Back then, I've tried my best here
->
http://digitaler-heimwerker.de/2012/10/26/howto-maven-spring-und-jbehave/
(unfortunately German). If a check with Google Translate suggests
that this is basically useful, I'd translate and tweak this and
its sibling post (below) as needed and contribute it.
Re-reading the post, I find that I struggled most on these topics:
1.What is the /simplest/ possible working configuration of
JBehave? (there's a description on the site, but no full
example... what are the main classes, what is their relationship
to each other? What do I need to import from where?
Reverse-engineering the thinking steps from the example projects
just didn't work for me.)
2.Depending on JBehave configuration and Maven configuration:
Where do I have to put this file, the stories and the step
implementations?
3.And then, specifically for my almost-simplest-possible set-up:
how does all this relate with Spring.
In hindsight, the biggest problem was #2: Which file goes where...
(or, more precisely, as everything is configurable: which
configuration determines what goes where, and what are the defaults?)
For a slightly more advanced topic, there's even a post in
English:
http://digitaler-heimwerker.de/2013/03/04/mocking-file-access-for-testing-with-jbehave-and-easymock/
I hope this helps. JBehave is really great, and I hope this
message is advancing its progress.
Thank you all for your great work!
Best wishes,
Josef
*From:*Janusz Kowalczyk [mailto:[email protected]]
*Sent:* Donnerstag, 6. März 2014 12:58
*To:* [email protected] <mailto:[email protected]>
*Subject:* [jbehave-user] Why JBehave repo examples and website
are the worst example of work ever created by the any of the open
source communitties?
It's truly remarkable that I haven't gave up yet in my attempts to
use JBehave many after days wasted on trying to figure out how to
run examples give on the jbehave.org <http://jbehave.org> or the
ones available in the project's repo.
Does any of the project members heard of Developer Experience?
Are there any chances that this will change in near future or this
project will keep to scare off more people?
Cheers
J
