Cucumber fat client


#1

Hi folks,

Cucumber has become popular a lot quicker than I had anticipated.
Still, with its plain text nature it is still limited to programmers (in
most teams).

I want to close the gap between customers/product owners/business
analysts
and programmers,
and I’m convinced that a fat client is needed to achieve this. Something
that lets people
browse, edit and run features inside a friendly user interface.

So I’m asking you - what would this user interface be like? How do
people
want to access it
and use it?

Cheers,
Aslak


#2

On 9 Dec 2008, at 09:43, aslak hellesoy wrote:

So I’m asking you - what would this user interface be like? How do
people want to access it
and use it?

I was considering writing (but will probably never have time for) a
simple writeboard/wiki-style site that is linked to a git repository.

So you point the app at a clone of your git repository’s features
folder, people can browse the folder, edit a feature in the browser
(and view the history) and then push them straight back into the repo.

(I noticed someone else had posted a writeboard-based system earlier
too)

B

Rahoul B.
Web design and development: http://www.3hv.co.uk/
Nottingham Forest: http://www.eighteensixtyfive.co.uk/
Serious Rails Hosting: http://www.brightbox.co.uk/
Lifecast: http://www.madeofstone.net/


#3

Hi Aslak,

Below are my manager’s recommendations:

"If you take a look at Twist, Thoughtworks have already done the hard
work in gleaning the requirements for this. Something Twist like would
be well received.

http://studios.thoughtworks.com/twist-agile-test-automation

Their implementation is eclipse based."

Thanks

Aidy

2008/12/9 aslak hellesoy removed_email_address@domain.invalid:


#4

On Tue, Dec 9, 2008 at 11:47 AM, Rahoul B. removed_email_address@domain.invalid
wrote:

writeboard/wiki-style site that is linked to a git repository.

So you point the app at a clone of your git repository’s features folder,
people can browse the folder, edit a feature in the browser (and view the
history) and then push them straight back into the repo.

(I noticed someone else had posted a writeboard-based system earlier too)

Yes, it’s called Remote Feature:
http://github.com/aslakhellesoy/cucumber/wikis/related-tools
http://github.com/mhennemeyer/remote_feature/tree/master

Aslak


#5

Hey Aslak,

Doesn’t this sound a bit like your Kipling project, which we spoke about
at
QCon London, back in March? :wink:

(http://gitorious.org/projects/kipling)

I think it would be a great app to have, which would work well inside a
web
browser, rather than a fat client that customers and managers have to
download…?

From my recollection, you were wanting to keep Kipling quite sparse and text
based, in contrast to the Thoughtworks product which Aidy mentioned in
this
thread.

I would be interested in getting involved with this, if I could be
helpful
in any way :slight_smile:

Steven


#6

On Tue, Dec 9, 2008 at 3:52 PM, steven shingler removed_email_address@domain.invalid
wrote:

Hey Aslak,

Doesn’t this sound a bit like your Kipling project, which we spoke about at
QCon London, back in March? :wink:

(http://gitorious.org/projects/kipling)

A little bit, but the idea with Kipling was to make something similar to
ThoughtWorks Mingle or Pivotal Tracker, which are tools to manage
stories,
iterations, estimates, burndown etc.

My goal with a fat Cucumber client is different (although it clearly
intersects):

  • Browse features
  • Edit features
  • Run features

So I’m thinking more along the lines of Fitnesse, but with a more
business-friendly UI, and focus on Cucumber (of course).

Essentially - I want this to be primarily a tool that replaces TextMate
and
the CLI for editing and running features, and not so much a Scrum/XP
planning tool. And the target audience is not us programmers (most of us
are
happy in TM/CLI) - it’s the non-techies that know Word and Excel only
(and
are experts in their business’ domain).

Aslak


#7

steven shingler wrote:

Hey Aslak,

Doesn’t this sound a bit like your Kipling project, which we spoke
about at QCon London, back in March? :wink:

(http://gitorious.org/projects/kipling)

I think it would be a great app to have, which would work well inside
a web browser, rather than a fat client that customers and managers
have to download…?
+1, I think keeping it in the browser will work well for most
situations. One option is to make it a flex app and could then be used
as a stand-alone Air app. WDYT?

I have been thinking about the requirements for such a project and I
think having it git-powered would be great. Having the stakeholder to
be able to edit features and have the changes show up in a remote branch
automatically would be a great feature IMO. If it is powered off of git
we also get versioning and a lot of other stuff for free. (I would
recommend watching Scott Chacoon’s presentation on using git in this way
from ruby conf:
http://rubyconf2008.confreaks.com/using-git-in-ruby-applications.html)

Anyways, thats my two cents. I would argue that most business people
these days are just as, if not more, comfortable in a browser than they
are in Excel as long as the UI is good. Of course, having clients for
both would be ideal. :slight_smile:

-Ben


#8

Matt W. wrote:

(http://gitorious.org/projects/kipling)

much a Scrum/XP planning tool. And the target audience is not us

Running like a web based application through something like like Adobe
Air or Mozilla Prisim would be nice. (Though these are reliant on
downloading plugins).


#9

branch automatically would be a great feature IMO. If it is powered
off of git we also get versioning and a lot of other stuff for
free. (I would recommend watching Scott Chacoon’s presentation on
using git in this way from ruby conf: http://rubyconf2008.confreaks.com/using-git-in-ruby-applications.html)

Anyways, thats my two cents. I would argue that most business
people these days are just as, if not more, comfortable in a browser
than they are in Excel as long as the UI is good. Of course, having
clients for both would be ideal. :slight_smile:

+1 to having it in browser as the first priority. People are more and
more comfortable all the time in their browsers.

Personally, I’m not sure I would want it tied to git explicitly - we
haven’t quite made that jump at work yet. On the other hand, it should
be easy to put hooks into it to auto-commit changes to pretty much any
type of repository.

-tim


#10

On 9 Dec 2008, at 09:43, aslak hellesoy wrote:

browse, edit and run features inside a friendly user interface.

So I’m asking you - what would this user interface be like? How do
people want to access it
and use it?

We have a person filling the ‘Product Owner’ role who is completely
non-technical.

I think it would be nice if there was a way for her to be able to do
this:

  • fire up the client
  • choose ‘open project’
  • enter the URL to the git repo where the project lives
  • then see a nice overview of all the features
  • be able to print off features for taking to meetings, reading on
    the train etc, nicely formatted
  • be able to edit features and easily push the changes back to the
    git repo

To me, this is more important than being able to run them. I don’t
think non-techie users need to be able to run features as they won’t
be able to do anything about it when they inevitably fail. I also hate
the idea of having to set up Ruby, gems etc on a non-techie person’s
computer. It’s better, IMO, if the tool makes it easy for them to push
their changes into a git repo where they can either be swept into the
main dev fork / branch, or automatically run using CI, et etc.

So that’s where I think the focus of such a tool should be - browsing,
reviewing and editing features rather than executing them, and with
some SCM integration to make all that easier for non-techies. I do
think that eventually the ability to run features will become
important too, but I would like to see this side of the problem solved
first.

Obviously there’s a dependency on git in what I’m suggesting, but I’m
sure it would be easy enough to plug in other SCMs if that was popular
enough.

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#11

Why not make a web client that manipulates git based projects in the
background? I’ve been messing around with Grit and doing things like
this lately for http://rdocul.us a site I run and it is very easy to do.
If everything is in a standard location you could just add a project via
an administrative page and it would be cloned in the background, then
they could:

browse all specs (just a filesystem listing)
edit and save specs (git add, commit, push)
look at a history on a given spec (log)
look at the history of all changes to the specs (log on a path)
merge changes / conflicts

the only thing that would be hard at all would be the conflict
resolution from if/when a normal git user update a spec.

-Mike


#12

On 9 Dec 2008, at 15:11, aslak hellesoy wrote:

similar to ThoughtWorks Mingle or Pivotal Tracker, which are tools
to manage stories, iterations, estimates, burndown etc.

My goal with a fat Cucumber client is different (although it clearly
intersects):

  • Browse features
  • Edit features
  • Run features

I think that some kind of autocomplete / syntax highlighting that
understands the currently-implemented set of step matchers would be
really useful too - I already find myself wondering whether I’ve
already implemented a step as I write the scenario.

So I’m thinking more along the lines of Fitnesse, but with a more
business-friendly UI, and focus on Cucumber (of course).

Essentially - I want this to be primarily a tool that replaces
TextMate and the CLI for editing and running features, and not so
much a Scrum/XP planning tool. And the target audience is not us
programmers (most of us are happy in TM/CLI) - it’s the non-techies
that know Word and Excel only (and are experts in their business’
domain).

It would be good if it could integrate into a a planning tool though -
offer an API that returned the number of Running Tested Features, etc.

I think it would be a great app to have, which would work well
inside a web browser, rather than a fat client that customers and
managers have to download…?

+1

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#13

On 14-dec-2008, at 19:49, mike.gaffney wrote:

look at the history of all changes to the specs (log on a path)
merge changes / conflicts

Correct me if I’m wrong (and I probably missed something), but why do
you and some others in this thread want users to actually edit a
feature?
That’s going to wreck havoc with steps that won’t match anymore,
breaking features, and therefore making the client angry.

WDYT?
bartz


#14

On 15 Dec 2008, at 12:53, Bart Z. wrote:

browse all specs (just a filesystem listing)

WDYT?
bartz

What else would they want to do though that would add much value?

My thinking now is that I would perhaps have the customers working on
a different branch of the code, which was still built in CI but failed
with a ‘softer’ noise, to indicate that there was new work to do. We’d
expect the build for this branch would be ‘broken’ most of the time.

As developers, we could then pull in the commits from this branch
(almost like a todo list) and get to work on the new or changed
features.

Is that making any sense?

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#15

I can maybe offer something here. begin rambling

My team of 4 (2 coders, 2 biz people) has recently switched to using
Pivotal
Tracker, and we’ve been doing the following:

  1. Figure out what we can do that will add value
  2. Draw out the ui / changes on a whiteboard
  3. Write out features & copy them into pivotal (as stories)
  4. Implement

This solves the following problems:

Coders have trouble communicating how long things will take to MBAs
(clients). Putting them in pivotal allows us to be clear about how long
things will take, and that adding things will add time.

Reduces miscommunications between clients and coders, because it forces
clients to be clear about what they want / gives coders ability to show
why
some things are not worth the time.

What is still lacking:

While we’ve been getting better at this, what’s lacking is a client
ability
to understand how features can/should be written.
I’ve been just allowing them to write them however they want, with a few
pointers, as for a lot of steps it requires a bit too much understanding
about how Rails works. For example, explaining to a long-term client the
difference between “press” and “follow” is fine, but I can imagine
feeling a
bit silly trying to explain it to a new client whom I am making a
proposal
to.

So, the solution to this may be to work together (on this list) to come
up
with better ways of writing features. (E.g. I’ve stopped using “And I
should
be at xyz” and “And there should be a xyz form” and a few other similar
things except in cases where they’re necessary, as clients would not
themselves include these kind of steps for the most part)

So, in terms of an interface:

I like the idea of changes coming in via something like git, where I
would
be able to see the differences. However this is not particularly
different
from updaing a feature on Pivotal, Trac or Lighhouse.

I think a more interesting idea for an interface would be something that
helps clients write features, like, some sort of drag and drop thing
where
they could start as a certain type of user, then drag in whens, then
type in
thens, or something. Probably not specific enough to be usefull, but
maybe
this will spark an idea for someone else.

In the distant future I can imagine some sort of speccing web app that
would
allow clients to build features by clicking and typing, and then
rearrange /
sort them plus visualize how they link together.

So, for example, there might be:

UserTypes - role:string

Actions - what:string

Results - what_happens:string

As a client I would be able to create a bunch of these, then arrange
them
and then print them out for my coders.

M


#16

A few other things…

In the interface that I was describing, it would solve several problems
to
have something like:

Given I’m a client
When I follow “new story”
And I drag in “Given I am a Pet Owner”
And I press “new action”
And I select “When I follow”
And I fill in “follows_what_link” with “Buy another dog”
And I press “new result”
And I select “Then i should see”
And I fill in “see_what” with “Say hello to your new dog”
And I press “Save feature”
Then I should see “Your feature has been saved!”
When I select “mischa – developer”
When I press “Send feature”
Then I should see “feature sent to mischa”

Obviously a bit hacky of a feature, but does everyone see what I’m
getting
at?

M


#17

On 16-dec-2008, at 9:42, Matt W. wrote:

could just add a project via an administrative page and it would
a feature?
failed with a ‘softer’ noise, to indicate that there was new work
to do. We’d expect the build for this branch would be ‘broken’ most
of the time.

That’s what I missed, I guess :).
rake features --as-blissfully-ignorant-client anyone?

As developers, we could then pull in the commits from this branch
(almost like a todo list) and get to work on the new or changed
features.

Is that making any sense?

Yep!

thanks,
bartz


#18

Also, if people are into this sort of thing, I would be up for helping
build
it.


#19

Correct me if I’m wrong (and I probably missed something), but why do
you and some others in this thread want users to actually edit a
feature?
That’s going to wreck havoc with steps that won’t match anymore,
breaking features, and therefore making the client angry.

WDYT?
bartz

My thinking now is that I would perhaps have the customers working on
a different branch of the code, which was still built in CI but
failed > with a ‘softer’ noise, to indicate that there was new work to
do. We’d > expect the build for this branch would be ‘broken’ most of
the time.

I was thinking the same thing with my original comment about letting
people edit the features. I didn’t think it fully through though. In our
distributed environment we typically have people discussing stories /
specs what have you over vnc or over the phone or over email and they
change until they are ‘accepted’. I was thinking that allowing this type
of interaction in this tool before the specs are actually ‘accepted’. eg
keep them pending until ‘accepted’/greenlit.

Having developers pull them in would be another way as well. Perhaps
‘accepting’ could be done with pull requests. The accepting / pulling
paradigm would depend on how you wanted to handle half done specs and
not yet implemented features.

Please bear with my terminology as I’m 1/2 way in the test::unit world.

-Mike