[rspec-users] Cucumber fat client
f.mischa at gmail.com
Tue Dec 16 06:17:28 EST 2008
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
On Tue, Dec 16, 2008 at 3:08 AM, Mischa Fierer <f.mischa at gmail.com> wrote:
> 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
> 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.
> On Tue, Dec 16, 2008 at 12:42 AM, Matt Wynne <matt at mattwynne.net> wrote:
>> On 15 Dec 2008, at 12:53, Bart Zonneveld wrote:
>>> On 14-dec-2008, at 19:49, mike.gaffney wrote:
>>> 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
>>>> 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
>>> 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.
>> 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
>> rspec-users mailing list
>> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users