[rspec-users] Cucumber fat client
f.mischa at gmail.com
Tue Dec 16 06:23:57 EST 2008
Also, if people are into this sort of thing, I would be up for helping build
On Tue, Dec 16, 2008 at 3:17 AM, Mischa Fierer <f.mischa at gmail.com> wrote:
> 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