On Thu, Aug 11, 2011 at 5:07 PM, Cedric Lamalle
Post by aslak hellesoyOn Thu, Aug 11, 2011 at 1:26 AM, aslak hellesoy
Post by aslak hellesoyOn Wed, Aug 10, 2011 at 2:50 AM, Cedric Lamalle
Post by Cedric LamalleHi,
Since there seem to have some interest about Cucumber-Jvm, I'm joining the
thread. I'd like to participate in the development of this jvm version, to
help speed up the release and to give back a little to the cucumber
community.
I have made a fork on github and made some pull requests there. I've worked
in the conversion part (transformables), and I am close to finish this part,
it still lacks the registering of Transform methods. I have some plans to
make this registering part more modular, mapping annotations with register
classes. This could be useful for registering Hooks too, for instance.
It would be great too to have the jars deployed on maven central to simplify
adoption of the tool.
That's on the radar. It's a fairly heavy process, but I have managed
to do it once (https://github.com/joewalnes/webbit/wiki/Releasing) so
I could do it again :-)
Post by Cedric LamalleThis will need a little cleaning in the poms [1] and
could be done by uploading the jars to sonatype oss repository [2], or
deploying directly to this nexus instance. I could help with this too.
Awesome. I guess step 1 is to file a JIRA ticket, right? It would be
awesome if you could do that.
The groupId can be cukes.info and the artifactId cucumber. I'd like to
keep the cucumber.* package name. Would that work?
Post by Cedric LamalleWhat I would like to know is how is the contributing process of the project.
Like you have done is fine! Fork, hack, push, send pull request.
* Had to comment out a couple of lines in TransformerTest.java because
of compilation errors (not merge related I think). Can you take a look
at that?
I will take a look at it. Maybe I'm using a different JDK version (6.0) or
something like that.
I believe I'm on 6.0 as well...
Post by aslak hellesoy* I'm using IntelliJ, you're using Eclipse. It would be great if we
could use the same formatting settings. Any clues on this? (I'm using
the default settings).
I don't know what the default settings of IntelliJ are, but I can make a
configuration xml to use the same settiings in Eclipse. Maybe someone
already did it. Googling quickly I only found the inverse[1]. Will have a
look at it too. Or maybe I should simply switch to IntelliJ...
The most important is that we try to keep the diffs clean.
One more thing I remembered - if you're working on many different
features, it is easier for me if you keep a branch for each one. That
makes it easier to follow what's going on, do selective merging etc.
Post by aslak hellesoy"Yup, that's exactly what I had planned to do". How did you figure out
what my plan was with Locales and argument transforms? Just by reading
a couple of TODOS? :-). Anyway, really awesome.
Yeah, I've read the TODOS while browsing the code. Using the Locale just
seemed natural for this kind of operation, and without locale the features
will be a lot less business friendly.
Post by aslak hellesoyThe next big task is to implement a CLI so cucumber can run without
JUnit. Some languages don't use JUnit at all (Clojure for example). I
have started on this, and I'd like the CLI runner and the JUnit runner
to share the same guts. I'm planning on sticking the common part in
cucumber.runtime, and have cucumber.junit and cucumber.cli use it.
Right now it's all in cucumber.junit.
I agree on the common part in cucumber.runtime, it could be useful too to
write plugins using cucumber. For instance, the maven plugin, a wiki plugin
(à la GreenPepper), etc.
Post by aslak hellesoyIs there anything in particular you'd like to tackle next? Here are a
* Implement cucumber.Table. It should have a similar API to the Ruby
counterpart. Constructor takes a List<Row> object. Diffing would be
awesome.
* Add support for Hooks
* Add support for Background (should run after any Before hooks)
I was planning to continue the arguments part, tables and custom
transformers.
For the first one what I had in mind besides the regular tables was to use
the transformable parts to create rich objects, this would speed up the
|name | birth date | bonus points|
|john doe | 01/01/1970 | 10000 |
|mary doe | 01/01/1970 | 15700 |
The specialiazed table in the step implementation would return a list of
public class User {
private String name;
private Date birthDate;
private Integer bonusPoints;
// ....
}
Nice - this is something I have wanted for a long time. So the stepdef would be:
@Given(...)
public void registeredUsers(List<User> users) {
}
How would Cucumber know what columns to use for what arguments? IIRC
we can't get method/ctor parameter names with reflection (unless we
use hacks like paranamer). I think positional arguments might be good
enough, but it does introduce a little risk if someone (a
non-technical feature writer) swaps two columns to improve
readability. Not sure here...
BTW, what do you think about this:
@Given(...)
public void registeredUsers(Table<User> users) {
}
public class cucumber.Table<T> extends ArrayList<T> {
public void diff(List<T> other);
}
For the second part (Custom Transformers), it would be great to think in a
modular way of metadata processing, to delegate the registration part to
annotations.
How about this:
Given a user named Cédric
@Given("a user named (.*)")
public void aUser(User user) {
// Cucumber creates the User just like it would for table rows.
}
alternatively:
@Given("a user named (.*)")
public void aUser(@Transform(MyUserTransformer.class) User user) {
// Cucumber creates the User like so: User user = new
MyUserTransformer().transform(arg1);
}
@Before.
That's the way it's done in Cuke4Duke already. Needs to support tags
as well. It would also be nice to be able to pass an optional argument
to a hook (like in Ruby):
@After("@mytag")
public void doIt(Scenario scenario) {
// Exit after first failure
if(scenario.isFailed()) {
Cucumber.stop();
}
}
-similar to this:
http://groups.google.com/group/cukes/browse_thread/thread/7ce3278ace15403b/a678b1eb27cda618?lnk=gst&q=wants_to_quit#a678b1eb27cda618
Aslak
What do you think?
Post by aslak hellesoyAnything else?
Cheers,
Aslak
Post by aslak hellesoyPost by Cedric LamalleDo you accept external contributions? Is there a formal code review process?
Not more formal than me looking at your commits, possibly commenting
on some of them and then merging it to the main repo.
I really like your code, so I hope to be able to merge your stuff in
next week. Am to busy before that. Let's discuss the road ahead next
week!
Thanks for helping out!
Aslak
Post by Cedric LamalleCheers,
Cédric.
[1]
https://docs.sonatype.org/display/Repository/Central+Sync+Requirementshttp://maven.apache.org/guides/mini/guide-central-repository-upload.html#Publishing_your_artifacts_to_the_Central_Repository
[2]
http://maven.apache.org/guides/mini/guide-central-repository-upload.html#Publishing_your_artifacts_to_the_Central_Repository
On Tue, Aug 9, 2011 at 9:59 PM, John Lonergan
Post by John LonerganAslak,
I assume you have considered the option of collaborating with the
JBehave folk?
What were your thoughts on this.
I considered it early on, and we discussed it. We both agreed to part ways.
Cucumber has evolved into a much bigger community than JBehave, and
one of the exciting things we're doing is to have a shared Gherkin
parser and test suite (in Cucumber) for various programming language
implementations. Collaborating with a different community while doing
this would impractical. Cucumber-JVM will support a half dozen JVM
languages (making it easy to add more).
I know the JBehave folks well. Dan North (who started BDD and JBehave)
sits next to me in the office!
Aslak
Post by John LonerganOn Tue, Aug 9, 2011 at 4:54 PM, alex.ikhelis
Post by alex.ikhelisHi there!
We are using cucumber for UI level tests against a big J2EE product
code base. We are in the process of choosing a BDD tool for the "below
the UI" levels of testing , which allows smooth access to our java
code / interpreted in jvm. We started to look into JBehave and
cuke4duke. The latter seems to allow us reuse our existing cucumber/
ruby infrastructure.
That's right. It's essentially some Java/Groovy/Scala ++ glue on top
of (Ruby)Cucumber and JRuby
Post by alex.ikhelisHowever it is difficult to find descriptive documentation and we are
uncertain about how reliable cuke4duke is now. Question based on the
reply from Aslak below - are we safe to start using it and then expect
a smooth migration to pure java implementation?
That depends what you mean by "safe". I don't plan on changing
Cuke4Duke going forward. I know people are using it with success.
Cucumber-JVM will be compatible on the Gherkin/Feature level, you
won't have to change anything there. StepDefinitions will probably be
identical with the exception of some package names that might change.
There is likely to be some other changes, but I can't tell what they
are as Cucumber-JVM is not released yet.
All in all I'd say "somewhat risky" as I don't know when Cucumber-JVM
will be released or how different it will be.
Aslak
Post by alex.ikhelisBest reagrds,
Alex Ikhelis,
SDET Expedia.Com
---------- Forwarded message ----------
Date: 9 August 2011 13:17
Subject: Re: cuke4duke query
Hi Ajay,
Cuke4Duke is in maintenance mode, and not very active. I'm working on
a pure Java replacement that I hope to release in 2-3 months. The
https://github.com/cucumber/cuke4duke/wiki
http://groups.google.com/group/cukes
Cheers,
Aslak
--
You received this message because you are subscribed to the Google
Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
Cédric.
[1] http://plugins.intellij.net/plugin/?id=1605
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to cukes+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.