On 28 Aug, 04:13, Justin Ko wrote:
>
> I would suggest switching to capybara.
Hi Justin,
I tried changing a part of my Gemfile to this:
group :development, :test do
gem 'rspec-rails', '>= 2.0.0.beta.19'
gem 'capybara'
end
I am not sure if this is correct or what to do next. I tried "bundle
I think you're having this problem:
http://github.com/rspec/rspec-rails/issues#issue/140
- Toni
On Sat, Aug 28, 2010 at 1:59 PM, Daniel Lidström wrote:
> On 28 Aug, 04:13, Justin Ko wrote:
>>
>> I would suggest switching to capybara.
>
> Hi Justin,
>
> I tried changing a part of my Gemfile to t
On Aug 27, 2010, at 7:18 PM, Myron Marston wrote:
> One of the primary dangers of using mocks is that your unit tests may
> be testing against an interface that is different from that of your
> production objects. You may simply have misspelled the method (e.g.
> object.should_receive(:methd_name
On Aug 27, 2010, at 10:52 PM, Justin Ko wrote:
>
>
> On Aug 27, 8:18 pm, Myron Marston wrote:
>> One of the primary dangers of using mocks is that your unit tests may
>> be testing against an interface that is different from that of your
>> production objects. You may simply have misspelled t
On Aug 27, 2010, at 8:06 AM, David Chelimsky wrote:
> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote:
>
>> Not sure what I must have bumped, but autotest won't run any specs--only
>> features. No errors are given on startup. I've taken "export
>> AUTOFEATURE=true" out of my ./bashrc file--n
> My other objection is that we're dealing with a dynamic
> language here, and there are going to be cases in which methods
> are defined dynamically. For average users, this is likely not
> a problem (as long as the check is done at the time the stub is
> invoked rather than when the stub is defin
> Not necessarily. In the case of a stub on a real object, the purpose is to
> control the environment in which the example runs. Consider a method on an
> object that returns one value before noon and a different value at noon and
> after. In an example for another object that depends on the t
On Aug 28, 6:59 am, Daniel Lidström wrote:
> On 28 Aug, 04:13, Justin Ko wrote:
>
>
>
> > I would suggest switching to capybara.
>
> Hi Justin,
>
> I tried changing a part of my Gemfile to this:
>
> group :development, :test do
> gem 'rspec-rails', '>= 2.0.0.beta.19'
> gem 'capybara'
> end
On Aug 28, 2010, at 11:33 AM, Justin Ko wrote:
>
>
> On Aug 28, 6:59 am, Daniel Lidström wrote:
>> On 28 Aug, 04:13, Justin Ko wrote:
>>
>>
>>
>>> I would suggest switching to capybara.
>>
>> Hi Justin,
>>
>> I tried changing a part of my Gemfile to this:
>>
>> group :development, :test
On Aug 28, 2010, at 11:32 AM, Myron Marston wrote:
>> My other objection is that we're dealing with a dynamic
>> language here, and there are going to be cases in which methods
>> are defined dynamically. For average users, this is likely not
>> a problem (as long as the check is done at the time
On 28 Aug, 19:32, David Chelimsky wrote:
> On Aug 28, 2010, at 11:33 AM, Justin Ko wrote:
>
> > Did you remove webrat from the Gemfile?
>
> That won't help with beta.19, which has a hard dependency on webrat. beta.20
> does not, so you can choose between webrat and capybara.
Thanks for the respo
On Aug 28, 2:44 pm, Daniel Lidström wrote:
> On 28 Aug, 19:32, David Chelimsky wrote:
>
> > On Aug 28, 2010, at 11:33 AM, Justin Ko wrote:
>
> > > Did you remove webrat from the Gemfile?
>
> > That won't help with beta.19, which has a hard dependency on webrat.
> > beta.20 does not, so you can
Have selector is a webrat matcher. If you're not using webrat you
can't use it. Capybara's matcher is have_css. I suggest you take a
look at capybara docs.
- Toni
On Sat, Aug 28, 2010 at 9:59 PM, Justin Ko wrote:
>
>
> On Aug 28, 2:44 pm, Daniel Lidström wrote:
>> On 28 Aug, 19:32, David Chelim
On 28 Aug, 21:21, Toni Tuominen wrote:
> Have selector is a webrat matcher. If you're not using webrat you
> can't use it. Capybara's matcher is have_css. I suggest you take a
> look at capybara docs.
>
> - Toni
Aha, that makes perfect sense Toni. Thanks!
Daniel
_
On Thursday 19 August 2010, Dylan Markow wrote:
> Is there a way to get to the content captured in a "content_for"
> block through my view specs, or at the very least get my "render"
> call to use the full layout?
Try defining a method like this in your spec
def content_for(name)
view.insta
> I think "separate from the spec run" mislead you as to my intention here.
> What I mean is that I don't want this to raise errors, but rather it
> would be part of the output, just like pending and failed examples.
I'm OK with this idea. I just didn't want to have a separate file to
read :).
>
16 matches
Mail list logo
