Forum: RSpec Cucumber fat client

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2008-12-09 10:44
(Received via mailing list)
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
Afe1e6b75aace67db4b3ac064256b0f1?d=identicon&s=25 Rahoul Baruah (Guest)
on 2008-12-09 11:49
(Received via mailing list)
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 Baruah
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/
Ee6788c2faaad7a5cd0bc466c9ea60d8?d=identicon&s=25 aidy lewis (Guest)
on 2008-12-09 11:56
(Received via mailing list)
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 <aslak.hellesoy@gmail.com>:
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2008-12-09 12:15
(Received via mailing list)
On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah <baz@madeofstone.net>
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
1cb5d53d5bbf3e3afa7960ef55c240e4?d=identicon&s=25 Steven Shingler (sshingler)
on 2008-12-09 15:54
(Received via mailing list)
Hey Aslak,

Doesn't this sound a bit like your Kipling project, which we spoke about
at
QCon London, back in March? ;)

(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 :)

Steven
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2008-12-09 16:13
(Received via mailing list)
On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <shingler@gmail.com>
wrote:

> Hey Aslak,
>
> Doesn't this sound a bit like your Kipling project, which we spoke about at
> QCon London, back in March? ;)
>
> (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


>
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2008-12-09 16:17
(Received via mailing list)
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 Wynne
http://blog.mattwynne.net
http://www.songkick.com
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2008-12-09 17:52
(Received via mailing list)
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? ;)
>
> (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-rub...)

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. :)

-Ben
F68f69615423aa3851bd445409754dbf?d=identicon&s=25 Joseph Wilk (joesniff)
on 2008-12-09 17:53
(Received via mailing list)
Matt Wynne 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).
D1b0fee9c743f544f9efa49dde7965a8?d=identicon&s=25 Tim Glen (Guest)
on 2008-12-09 18:04
(Received via mailing list)
> 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-rub...)
>
> 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. :)

+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
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2008-12-14 18:26
(Received via mailing list)
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 Wynne
http://blog.mattwynne.net
http://www.songkick.com
8a5aa12eda8d4fb55490f1653926fd3e?d=identicon&s=25 Mike Gaffney (paramonkreel)
on 2008-12-14 21:51
(Received via mailing list)
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
3880f04333bf8375b44cd6aa135406c7?d=identicon&s=25 Bart Zonneveld (Guest)
on 2008-12-16 05:45
(Received via mailing list)
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
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2008-12-16 09:44
(Received via mailing list)
On 15 Dec 2008, at 12:53, Bart Zonneveld 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 Wynne
http://blog.mattwynne.net
http://www.songkick.com
3880f04333bf8375b44cd6aa135406c7?d=identicon&s=25 Bart Zonneveld (Guest)
on 2008-12-16 12:01
(Received via mailing list)
On 16-dec-2008, at 9:42, Matt Wynne 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
Ff937b6907db49432c980f2b6a5c7e71?d=identicon&s=25 Mischa Fierer (mischa)
on 2008-12-16 12:10
(Received via mailing list)
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
Ff937b6907db49432c980f2b6a5c7e71?d=identicon&s=25 Mischa Fierer (mischa)
on 2008-12-16 12:21
(Received via mailing list)
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
Ff937b6907db49432c980f2b6a5c7e71?d=identicon&s=25 Mischa Fierer (mischa)
on 2008-12-16 12:26
(Received via mailing list)
Also, if people are into this sort of thing, I would be up for helping
build
it.
8a5aa12eda8d4fb55490f1653926fd3e?d=identicon&s=25 Mike Gaffney (paramonkreel)
on 2008-12-16 16:15
(Received via mailing list)
>>> 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
This topic is locked and can not be replied to.