[rspec-users] Cucumber fat client

Mischa Fierer 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
it.

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
> at?
>
> M
>
>
>
> 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
>> 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
>>
>>
>>
>>
>> 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
>>>>> 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
>>>>>
>>>>
>>>> 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
>>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081216/392cb6c3/attachment-0001.html>


More information about the rspec-users mailing list