I contributed an article on BDD and RSpec to the Ruby Advent Calendar
2008, going over some of the rules I've collected for interpreting
what your specs say about your design. It can be found here:
http://advent2008.hackruby.com/past/2008/12/10/listening_to_your_specs/
--
Avdi
Home: http://avdi
On Tue, Dec 9, 2008 at 5:19 PM, nicholas a. evans <[EMAIL PROTECTED]> wrote:
> I've always been a little bit bemused by the default ruby test/unit and
> rspec output. Basically, what I want is a progress bar and that any
> errors and warnings be displayed immediately. I also want warnings to be
>
"nicholas a. evans" <[EMAIL PROTECTED]> writes:
> I've always been a little bit bemused by the default ruby test/unit and
> rspec output. Basically, what I want is a progress bar and that any
> errors and warnings be displayed immediately. I also want warnings to be
> printed for slow specs. When
I've always been a little bit bemused by the default ruby test/unit and
rspec output. Basically, what I want is a progress bar and that any
errors and warnings be displayed immediately. I also want warnings to be
printed for slow specs. When using color, I want the entire progress bar
printed in g
Thanks Nick
the first approach seems the best for my situation.
Appreciate the response
Ivor
On Tue, Dec 9, 2008 at 4:45 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> On 2008-12-09, at 06:29, Ivor Paul wrote:
>
>> Hi
>>
>> I have the following code:
>>
>> def will_paginate(items, options = {})
I have decided that for now I am going to use the authlogic gem to
provide authentication for the project I am creating. The question
arises, since authentication is a user feature request and since it is
to be satisfied through the use of a gem (not a plugin) then should one
test for the availabi
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
use
Matt Wynne wrote:
On 9 Dec 2008, at 15:11, aslak hellesoy wrote:
On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <[EMAIL PROTECTED]>
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/
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
On 9 Dec 2008, at 15:11, aslak hellesoy wrote:
On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <[EMAIL PROTECTED]>
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 littl
On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <[EMAIL PROTECTED]> 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 mak
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
On 2008-12-09, at 06:29, Ivor Paul wrote:
Hi
I have the following code:
def will_paginate(items, options = {})
options = options.merge(:container => true, :class => 'paging')
super(items, options)
end
I am curious about how to test that the call to super is infact
being called wi
Hi
I have the following code:
def will_paginate(items, options = {})
options = options.merge(:container => true, :class => 'paging')
super(items, options)
end
I am curious about how to test that the call to super is infact being called
with the added options.
I have this
it 'shou
On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah <[EMAIL PROTECTED]> wrote:
>
> 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 neve
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 ec
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.
Check this out: http://github.com/aslakhellesoy/cucumber/wikis/logo-contest
Aslak
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
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 need
You can improve the features you've given by
1. use named routes not url's
2. not checking for not seeing specific things
3. A combined step with a more examples table
Given I am logged in as a developer
4. having a general policy for what happens when access fails and testing
that e.g.
I usually assume my scenario user has been Given permission
and instead, I do the authorization testing in the controller specs
with shared behaviors, for example,
it_should_behave_like "a login required action"
it_should_behave_like "a manager authorized action"
That said, I also might have
21 matches
Mail list logo
