On 9/8/07, Ben Mabey <[EMAIL PROTECTED]> wrote:
> What was the motivation behind taking that tutorial down, BTW? I really
> like and benefited from it when I was starting to learn rspec. Was it
> just a maintenance issue as far as updating the tutorial to the current
> API (DSL)?
That was part
David Chelimsky wrote:
> On 9/8/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
>
>> On 9/8/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
>>
>>> El 8/9/2007, a las 2:15, Pat Maddox escribió:
>>>
>>>
* Descriptions should be broken up based on the required fixture. I
don't spli
On 9/8/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
> > El 8/9/2007, a las 2:15, Pat Maddox escribió:
> >
> > > * Descriptions should be broken up based on the required fixture. I
> > > don't split them up until I actually have to. For example
El 8/9/2007, a las 17:18, Pat Maddox escribió:
> To give credit where it's due, I'm pretty sure that's from my memory
> of the early examples on rspec.rubyforge.org.
Yes, but it's one thing to look at a finished set of well-written
specs, and it's another to see them built up from scratch in st
On 9/8/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
> El 8/9/2007, a las 2:15, Pat Maddox escribió:
>
> > * Descriptions should be broken up based on the required fixture. I
> > don't split them up until I actually have to. For example, if I'm
> > writing a Stack class. I'd probably start off
El 8/9/2007, a las 2:15, Pat Maddox escribió:
> * Descriptions should be broken up based on the required fixture. I
> don't split them up until I actually have to. For example, if I'm
> writing a Stack class. I'd probably start off with
>
> [snip]
>
> For a simple spec like this it's okay. We
On 9/7/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
> On 9/7/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > > Actually, on that note -- what's the normal way to share a setup across
> > > multiple behaviors, a helper method in an includeable module?
> >
> > You can include callable methods i
On 9/7/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
>
> > Actually, on that note -- what's the normal way to share a setup across
> > multiple behaviors, a helper method in an includeable module?
>
> You can include callable methods in modules, but they have to be
> called from within the spec.
>
On 9/7/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
> > describe MyModel, " when saved twice" do
> >
>
> This is the key point I hadn't considered; makes sense, as long as you make
> sure that there's a context wherein the specification that it
On 9/7/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
> On 9/7/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
> > describe MyModel, " when saved twice" do
> >
>
> This is the key point I hadn't considered; makes sense, as long as you make
> sure that there's a context wherein the specification that it
On 9/7/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
>
> describe MyModel, " when saved twice" do
>
This is the key point I hadn't considered; makes sense, as long as you make
sure that there's a context wherein the specification that it should have a
certain number of revisions. Thanks!
Realized th
On 9/7/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
> Sorry, lots of questions these days.
>
> Is there a normal approach for preconditions? In JUnit, I might put a few
> assertions in the setUp() just to make sure that the test 'data' I've
> created meets expectations before going to test it.
Sorry, lots of questions these days.
Is there a normal approach for preconditions? In JUnit, I might put a few
assertions in the setUp() just to make sure that the test 'data' I've
created meets expectations before going to test it.
So, for instance, I've got an object that is audited using acts
13 matches
Mail list logo
