On Sat, Oct 18, 2008 at 2:34 AM, William Tozier <[EMAIL PROTECTED]> wrote:
> I'm trying to set up cucumber so we can try it in some Ruby automation
> scripts I'm working on. These will be straight Ruby, for use in BBEdit and
> TextMate (on the Mac).
>
> NOT Rails.
>
> The big early-stage stumbling
On Oct 17, 2008, at 11:42 AM, Stephen Eley wrote:
On Fri, Oct 17, 2008 at 10:54 AM, Joseph Wilk <[EMAIL PROTECTED]
> wrote:
"The dynamic nature of JavaScript makes mocking frameworks mostly
unnecessary"
A small but interesting difference from using Ruby, Rspec and its
built-in
mocking fra
On 2008-10-17, at 17:16, David Chelimsky wrote:
Cool. Don't forget the seldom used #head, though I don't know what to
call it: when_heading_to?
I looked through the docs at http://rspec.rubyforge.org/rspec/1.1.8/
for #head , but the closest thing I found was #header , which is
undocumented.
On Oct 17, 2008, at 8:34 PM, William Tozier wrote:
* A "fixtures" directory... but with what necessary subdirectories
in it?
Sorry. Meant "features" directory.
-
Bill Tozier
AIM:[EMAIL PROTECTED] • Twitter:Vaguery
http://williamtozier.com/slurry
"The brotherhood of man is not a mere poe
On Fri, Oct 17, 2008 at 11:55 AM, Mark Thomson <[EMAIL PROTECTED]>wrote:
> It seems as if "should_receive" is queuing up the messages that come into
> the file object and when it tests an expectation it just looks at the next
> one in line. If it doesn't match then the expectation will fail.
>
Y
On Fri, Oct 17, 2008 at 10:54 AM, Joseph Wilk <[EMAIL PROTECTED]> wrote:
>
> "The dynamic nature of JavaScript makes mocking frameworks mostly
> unnecessary"
>
> A small but interesting difference from using Ruby, Rspec and its built-in
> mocking framework.
So... Wait. Is the implication here th
On Thu, Oct 16, 2008 at 1:18 PM, Rahoul Baruah <[EMAIL PROTECTED]> wrote:
>
> On 16 Oct 2008, at 16:02, Stephen Eley wrote:
>
>> This confused me too at first. To put it another way:
>>
>> (1) controller.expect_render(:layout => 'index') [set expectation]
>> (2) get :index [perform action]
>>
I'm trying to set up cucumber so we can try it in some Ruby automation
scripts I'm working on. These will be straight Ruby, for use in BBEdit
and TextMate (on the Mac).
NOT Rails.
The big early-stage stumbling block I'm having is setting up the
initial Rakefile and directory structure. I t
On Fri, Oct 17, 2008 at 3:28 PM, Rasmus Rasmussen <[EMAIL PROTECTED]> wrote:
>
> this feels like a duplication. If I write rspec-tests I should not do
> ordinary tests, because then I need to maintain two fixtures. Right?
Correct. You don't need it. But the standard Rails generator doesn't
know
On Fri, Oct 17, 2008 at 12:51 PM, Zach Dennis <[EMAIL PROTECTED]> wrote:
> alias tmig='rake db:migrate && rake db:rollback && rake db:migrate
> && rake db:test:prepare'
>
Sounds good. Nice to see someone paying attention to their downs as well as
their ups.
rake db:migrate:redo will do the rol
On Fri, Oct 17, 2008 at 3:54 PM, Zach Dennis <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 3:37 PM, Stephen Eley <[EMAIL PROTECTED]> wrote:
>>
>> That sounds right to me. You declared 'file' as a mock. Mocks are
>> bratty little children that treat it as an error and throw a tantrum
>> if
On Fri, Oct 17, 2008 at 3:37 PM, Stephen Eley <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 2:55 PM, Mark Thomson <[EMAIL PROTECTED]> wrote:
>>
>> and then check that the expected messages are being received -
>> file.should_receive(:puts).with("a string").once
>> file.should_receive(:puts).
On Fri, Oct 17, 2008 at 3:42 PM, Stephen Eley <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 2:46 PM, Rasmus Rasmussen <[EMAIL PROTECTED]> wrote:
>>
>> Something got messed up when I changed a table's name from 'works' to
>> 'work_periods'. Now the fixture:load thing does not work. Obviously
On Fri, Oct 17, 2008 at 2:46 PM, Rasmus Rasmussen <[EMAIL PROTECTED]> wrote:
>
> Something got messed up when I changed a table's name from 'works' to
> 'work_periods'. Now the fixture:load thing does not work. Obviously the
> old table is still in there in some file.
Dumb question, but did you cl
On Fri, Oct 17, 2008 at 2:55 PM, Mark Thomson <[EMAIL PROTECTED]> wrote:
>
> and then check that the expected messages are being received -
> file.should_receive(:puts).with("a string").once
> file.should_receive(:puts).with("another string").once
>
> Here's what I'm puzzled about. If I don't inclu
Rasmus Rasmussen wrote:
> Zach Dennis wrote:
>> Do you still have "works.yml" in your fixtures/ directory? If so
>> you'll need to rename that to "work_periods.yml".
>>
>>
Zach, you are right, there is another fixture under "test". I only
searched in "spec"-dir.
And I am in the wrong forum :-)
On 2008-10-17, at 14:46, Rasmus Rasmussen wrote:
I'm sorry if this is posted in wrong forum. I am new to all of this
with
rails and rspec.
Something got messed up when I changed a table's name from 'works' to
'work_periods'. Now the fixture:load thing does not work. Obviously
the
old table
On 2008-10-17, at 14:55, Mark Thomson wrote:
..snip..
It seems as if "should_receive" is queuing up the messages that come
into the file object and when it tests an expectation it just looks
at the next one in line. If it doesn't match then the expectation
will fail.
Hi Mark. From my unde
Actually, this is evidently not the whole story. I actually have two
examples in the same spec, and I just realized that the other one has
instances of file.should_receive(:puts) that don't seem to suffer the
same limitation I described. So it looks like there is something about
the example I d
Zach Dennis wrote:
> Do you still have "works.yml" in your fixtures/ directory? If so
> you'll need to rename that to "work_periods.yml".
>
> Zach
>
> On Fri, Oct 17, 2008 at 2:46 PM, Rasmus Rasmussen <[EMAIL PROTECTED]>
> wrote:
>>>
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
Do you still have "works.yml" in your fixtures/ directory? If so
you'll need to rename that to "work_periods.yml".
Zach
On Fri, Oct 17, 2008 at 2:46 PM, Rasmus Rasmussen <[EMAIL PROTECTED]> wrote:
> I'm sorry if this is posted in wrong forum. I am new to all of this with
> rails and rspec.
>
> So
I'm writing my first controller spec - for a controller that already
exists, and in the process have observed some behavior I find a little
surprising. I'd like to know whether I'm interpreting the situation
correctly...
In my controller I have some stuff written to a file, i.e.
file = File.n
I'm sorry if this is posted in wrong forum. I am new to all of this with
rails and rspec.
Something got messed up when I changed a table's name from 'works' to
'work_periods'. Now the fixture:load thing does not work. Obviously the
old table is still in there in some file.
Anyone have any idea on
On of the things I've noticed with ScrewUnit is to quote the ScrewUnit wiki:
"The dynamic nature of JavaScript makes mocking frameworks mostly
unnecessary"
A small but interesting difference from using Ruby, Rspec and its
built-in mocking framework.
--
Joseph Wilk
http://www.joesniff.co.uk
On Oct 17, 2008, at 10:41 am, Matt Wynne wrote:
I'm also interested in this, as we're currently deciding which route
to go.
I like the philosophy behind screw unit - it feels like the team
want to give us RSpec for javascript.
That's the feeling I got, that SU is trying to be a cleaner,
On Thu, Oct 16, 2008 at 4:28 PM, Ashley Moran
<[EMAIL PROTECTED]> wrote:
> So I just wondered if anyone here has used Screw.Unit[2], and if so, how
> does it compare to RSpec? It seems to offer many of the features of RSpec
> (with the notable exception of shared behaviours).
I just want to thank
On 17 Oct 2008, at 06:44, Scott Taylor wrote:
On Oct 16, 2008, at 4:28 PM, Ashley Moran wrote:
Hi
Hope this isn't OT. I'm currently contemplating using the Dojo[1]
JavaScript framework, and I suspect it's powerful enough that using
Cucumber features and Celerity alone will quickly leave
Steph I sucessfully wrote my first test
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
28 matches
Mail list logo
