El 02/02/2011, a las 02:28, Julian Leviston escribió:
> Surely as the private methods of a class change, the testing code HAS to
> change...
That statement sets off all sorts of alarm bells for me.
In order for your specs to be non-brittle, they should be concerned with the
externally-visible
El 28/01/2011, a las 03:53, Rick DeNatale escribió:
> On Thu, Jan 27, 2011 at 6:16 PM, David Chelimsky wrote:
>> On Jan 27, 2011, at 5:11 PM, John Feminella wrote:
>>
>>> That's not quite right. :each runs before _each_ spec, while :all runs
>>> once, before _any_ spec.
>>
>> Perhaps :any is a
El 06/12/2010, a las 01:19, DK escribió:
> Hi all, anyone have an idea why I am getting an error trying to 'rake
> spec':
>
> 'kernel.rb:27:in `should': uninitialized constant RSpec::Expectations
> (NameError)'.
Can you paste the full backtrace and the code of the spec which is causing this
fai
On 02/11/2010, at 01:36, Iain E. Davis wrote:
> I've been puzzling over how to test that attr_accessible has been set
> for the correct columns; but the tests I've come up with so far seem
> to fail to fail when I expect. I came across this old message from
> this list:
>
> http://www.mail-archiv
El 18/10/2010, a las 20:20, Joe Fiorini escribió:
> I started testing routes for the first time in Rails 3 this weekend
> during Rails Rumble. I was so exhausted that I found writing route
> specs a very painful task. I came up with my own routing DSL and I'd
> love to see it get included in RSpec
El 21/09/2010, a las 13:55, David Chelimsky escribió:
> On Sep 21, 2010, at 4:57 AM, Lord Raiden wrote:
>
>> David Chelimsky wrote:
>
>> Reason I'm asking is I really want to write few view specs, (outside of
>> cucumber), and I would like not to use Webrat, to keep things clean.
>
> Why would
El 30/08/2010, a las 05:52, Arco escribió:
> Is there an ETA for a production version of Rspec2 ??
I'll let David answer that one, but as a humble user, having used the betas of
RSpec 2 for a few months now I'd say it's certainly production-ready. I'd
deploy the latest beta to production server
El 16/08/2010, a las 06:39, David Chelimsky escribió:
> On Tue, Aug 10, 2010 at 11:17 AM, Brad Pauly wrote:
>> I've just uninstalled all versions of rspec and installed
>> rspec-2.0.0.beta.19 and rspec-rails-2.0.0.beta.19 for a rails project
>> and I can't find the rspec command. Based on what bu
El 30/07/2010, a las 16:10, David Chelimsky escribió:
> Actually - maybe I spoke to soon. Ordering things this way would mean that
> you couldn't do this:
>
> shared_examples_for Enumerable do
> def enumerable
>raise "you must provide an enumerable method that returns the object which
> yo
El 26/07/2010, a las 15:52, nathanvda escribió:
> For test::unit there exists a solution: http://github.com/jm/skippy
> Is there a similar solution for Rspec?
> Or how do you guys solve this?
The way to do the "Skippy" thing under RSpec 2 will be filtering:
http://blog.davidchelimsky.net/2010/06
El 26/07/2010, a las 14:09, Ashley Moran escribió:
> The solution I'm playing with is to extract shared contract (ie shared
> example groups) that you can mix into a spec for a host class (eg User,
> Checklist) above to prove the feature (here collections) works, without
> reference to the impl
El 26/07/2010, a las 09:31, Ashley Moran escribió:
> I'm back again, and still on a quest to tame shared example to do my bidding.
> This time what I'm wondering is... is there any way to format shared example
> specdoc description output with data passed in with #let, or otherwise? eg:
> How
El 24/07/2010, a las 16:33, chatgris escribió:
> I have two issues with beta 2.0.0.beta.18. First, here's the gems :
>
> gem "rails", "3.0.0.beta4"
> gem "mongoid", "2.0.0.beta10"
>
> group :test do
> gem "rspec-rails", "2.0.0.beta.18"
> gem "factory_girl_rails", "1.0"
> end
[snip]
> That gi
El 24/07/2010, a las 15:34, Lille escribió:
> David,
>
> Yes, your reading of the request is what I originally meant.
>
> I appreciate the points made by others in this thread and the thread
> David has referred to.
>
> As I continue to learn RSpec I will undoubtedly avail myself of the
> appro
El 24/07/2010, a las 08:26, David Chelimsky escribió:
> On Fri, Jul 23, 2010 at 6:46 PM, Lille wrote:
>> Hi,
>>
>> I've been browsing the RSpec book and the RDoc, but I can't see how to
>> ensure the following:
>>
>> Stub an instance with a method it doesn't have and raise NoMethodError
>> (or
El 23/07/2010, a las 09:09, Ashley Moran escribió:
> I'm looking for the best way to parameterise shared examples. Imagine (as an
> academic example...) you were doing it for subclasses of Struct instances (a
> more realistic example might be ActiveRecord subclasses, or DataMapper
> resources)
El 19/07/2010, a las 16:20, Phillip Koebbe escribió:
> On 2010-07-19 5:38 AM, Wincent Colaiuta wrote:
>> I don't necessarily think so. Matt says you can probably do this right now
>> by using macros. I don't actually know what he means by that, but I do know
>&g
El 19/07/2010, a las 15:52, David Chelimsky escribió:
> On Jul 19, 2010, at 8:17 AM, rogerdpack wrote:
>
>> Hi all.
>>
>> Saw this:
>>
>> Usage: rspec [options] [files or directories]
>> -b, --backtrace Enable full backtrace
>> -c, --[no-]color, --[no-]colour Enable color
El 19/07/2010, a las 10:58, Matt Wynne escribió:
> On 18 Jul 2010, at 00:10, David Chelimsky wrote:
>
>> On Jul 17, 2010, at 1:18 PM, Costa Shapiro wrote:
>>
>>> Hello,
>>>
>>> I've been thinking of how to express my idea in code, but since I've never
>>> been involved in RSpec development, I'
El 17/07/2010, a las 17:37, doug livesey escribió:
> Hi -- how are people speccing Rails 3 ActiveRecord queries?
> At the minute I'm chaining a load of should_receive calls on mock relation
> objects, but can't help thinking that there must be a more elegant way of
> going about it.
> Is there a b
El 10/07/2010, a las 12:21, Wincent Colaiuta escribió:
> I think the biggest speed gain wouldn't be from doing more mocking and
> stubbing, but actually from swapping in an in-memory database instead of
> MySQL. Not sure how hard that would be, to be honest. (Wondering if it&#x
El 10/07/2010, a las 05:29, Phillip Koebbe escribió:
>> It is not "better" nor "the right" way, it is just "a" way of doing it. I've
>> also written controller specs where I ended up mocking left, right and
>> center, but if I can take the state-based approach I generally prefer it.
>> The app
El 09/07/2010, a las 14:29, Frank J. Mattia escribió:
>>> it "should explicitly set created_by" do
>>> controller.stub(:current_user) { mock_user }
>>> mock_order.should_receive(:created_by=).with(mock_user)
>>> post :create
>>> end
>>
>>> This is my newly working spec. Does this look well tho
El 09/07/2010, a las 04:25, Frank J. Mattia escribió:
>> Seems reasonable to me. You could test with either an interaction based
>> approach (use mocks and stubs to confirm that @object receives the
>> "created_by" message with the expected param) or a state based approach (hit
>> the controlle
El 08/07/2010, a las 18:36, nruth escribió:
> I'm setting up a Paypal IPN listener and need the create action to not
> use rails' default CSRF protection.
>
> I've got that working fine & test it actually works with cucumber
> (where I've turned CSRF back on, since it's full-stack testing) but
>
El 08/07/2010, a las 18:17, Frank J. Mattia escribió:
> My controller does something like this for create
> @object = Object.new(params[:object])
> @object.created_by = current_user
> if @object.save... yadda yadda yadda...
>
> I have my model spec testing for the presence of created_by but I fee
El 08/07/2010, a las 04:45, Lalish-Menagh, Trevor escribió:
> OK, here is an idea. I was thinking about how to make routing tests
> that make sense. I agree with Wincent that the Rails verbiage for the
> routing tests is confusing, but what is NOT confusing is the new
> routing format, so why not
El 07/07/2010, a las 16:42, David Chelimsky escribió:
> On Jul 7, 2010, at 7:39 AM, Wincent Colaiuta wrote:
>
>> El 07/07/2010, a las 13:29, David Chelimsky escribió:
>
> How about going back to map, with to_and_from:
>
> it { should map(get "/issues/
El 07/07/2010, a las 13:29, David Chelimsky escribió:
> Seems as though this format has been abandoned in this conversation:
>
> it { should route(get "/issues/new").to("issues#new") }
> it { should generate("/issues/new").from("issues#new") }
>
> I think that verbiage is concise and intention
El 07/07/2010, a las 03:54, Lalish-Menagh, Trevor escribió:
> I am sure most of you could do this easily, but I wanted to write down
> how I got there in any case, so here are my instructions on how to set
> up rspec-rails to hack on:
> http://trevmex.com/post/779078048/how-to-start-hacking-a-ruby
El 07/07/2010, a las 01:16, Lalish-Menagh, Trevor escribió:
> Hi David,
>
> You make a good point. I was talking with a coworker about this
> problem, and he suggested a simpler format, that I think will coincide
> some with Wincent's thoughts. Here is my next stab
> (http://gist.github.com/46606
El 05/07/2010, a las 20:18, Randy Harmon escribió:
> I'm uncertain about the need to easily specify one-directional routes.
> While in theory it sounds fine, I don't understand why you'd want to
> specify either a route that isn't recognized (why bother routing it, in
> this case?) or one that do
El 05/07/2010, a las 21:00, Randy Harmon escribió:
> David Chelimsky wrote:
>> Check out these two threads:
>>
>> http://groups.google.com/group/rspec/browse_thread/thread/9ac4ff6f3bac8423
>> http://groups.google.com/group/rspec/browse_thread/thread/4775eaa9b8b3c25f
>>
>> Both of them were, coin
El 05/07/2010, a las 19:17, David Chelimsky escribió:
> On Jul 5, 2010, at 11:58 AM, Wincent Colaiuta wrote:
>
>> El 05/07/2010, a las 18:18, David Chelimsky escribió:
>>
>>> The thing that concerns me the most is the DestinationParser. Even though
>>> it s
El 05/07/2010, a las 18:58, Wincent Colaiuta escribió:
> El 05/07/2010, a las 18:18, David Chelimsky escribió:
>
>> Slight tangent - one nice thing about 'recognize' as a matcher name is we
>> get this for free:
>>
>> it { should_not recognize(:get =&
El 05/07/2010, a las 18:18, David Chelimsky escribió:
> The thing that concerns me the most is the DestinationParser. Even though it
> seems simple, that's the sort of code that ends up making rspec-rails a
> rails-dependent maintenance problem.
But seeing as we're wrapping Rails assertions we'
El 05/07/2010, a las 13:56, David Chelimsky escribió:
> Nice overall. Much of the code belongs in Rails, though, so I'd like to try
> to get a patch in to Rails once we get this worked out. I'd like the
> rspec-rails matchers to be simple wrappers for rails' assertions wherever
> possible.
We
Hi folks,
I've been unhappy with routing specs for a long time now and last night when
updating some old 1.3 specs for 2.0 I decided to see if I could come up with
something that didn't make me feel unhappy.
Principal causes of unhappiness:
1. Historically we had "route_for" and "params_from",
El 29/06/2010, a las 09:50, Timo Rößner escribió:
> Hi David,
>
> Gemfile and spec/spec_helper (not sure what you mean with "in-line
> posting"? I hope it's ok like that, if not, let me know):
He means, don't top-post.
http://idallen.com/topposting.html
http://en.wikipedia.org/wiki/Posting_sty
El 25/06/2010, a las 17:44, geetarista escribió:
> Gemfile: http://gist.github.com/453032
>
> On Jun 25, 7:41 am, Wincent Colaiuta wrote:
>> El 25/06/2010, a las 15:38, geetarista escribió:
>>
>>> That did not fix it.
>>
>> What have you got in your G
El 25/06/2010, a las 15:38, geetarista escribió:
> That did not fix it.
What have you got in your Gemfile?
Cheers,
Wincent
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
El 22/06/2010, a las 08:16, Marcelo de Moraes Serpa escribió:
> Hello list,
>
> I have noted a few problems when using rake spec. First, it doesn't seem to
> load the gems from the Gemfile (:test group) I had to add a required for
> each gem in this group on the spec_helper.rb file when I tried t
El 20/06/2010, a las 19:59, David Chelimsky escribió:
> On Jun 20, 2010, at 10:34 AM, Wincent Colaiuta wrote:
>
>> El 20/06/2010, a las 15:09, David Chelimsky escribió:
>>
>>>
>>> On Jun 20, 2010, at 8:06 AM, David Chelimsky wrote:
>>>
>>&g
El 20/06/2010, a las 15:09, David Chelimsky escribió:
>
> On Jun 20, 2010, at 8:06 AM, David Chelimsky wrote:
>
>> On Jun 20, 2010, at 8:03 AM, David Chelimsky wrote:
>>
>>>
>>> On Jun 20, 2010, at 7:30 AM, Michael Schuerig wrote:
>>>
On http://github.com/rspec/rspec-rails under "View sp
El 01/03/2010, a las 21:32, drewB escribió:
> I need to create some integration tests without cucumber. Can anyone
> point me in the right direction for how to do that in rails? I tried
> creating specs under 'spec/integration/' but no matchers are being
> included. I also tried rspec_integratio
El 07/01/2010, a las 03:53, Phillip Koebbe escribió:
Wincent Colaiuta wrote:
Well, there is more than one way to skin a cat, but the thing I
like about my proposed solution is that:
- the specification of the behavior appears in the "describe" block
that corresponds to the
El 06/01/2010, a las 16:17, Phillip Koebbe escribió:
Wincent Colaiuta wrote:
I test inherited stuff with shared behaviors. It might be something
you could use here.
Basically, I have a bunch of behavior in my ApplicationController,
for example, and in my spec/controllers
El 05/01/2010, a las 21:52, Phillip Koebbe escribió:
Pat Maddox wrote:
The spec has Admin::BaseController as the described type. So of
course it's going to test against that. If you want to test a
different class, you need to describe that instead!
Hi Pat,
Right. But, I'm not really wan
El 09/12/2009, a las 19:15, David Chelimsky escribió:
On Wed, Dec 9, 2009 at 11:55 AM, Pat Maddox > wrote:
[...@admin, @allowed_user].should all(be_allowed_to_visit(url))
[...@admin, @allowed_user].should all_be_allowed_to_visit(url)
On Dec 9, 2009, at 5:27 AM, David Chelimsky wrote:
On Wed,
El 29/6/2009, a las 17:15, Wincent Colaiuta escribió:
El 29/6/2009, a las 16:26, Ben Mabey escribió:
You probably know this, but for the benefit of others... Pat made a
change a while back that makes it so the stubbed return value will
still be returned even if an expectation is added
El 29/6/2009, a las 16:26, Ben Mabey escribió:
You probably know this, but for the benefit of others... Pat made a
change a while back that makes it so the stubbed return value will
still be returned even if an expectation is added. Meaning,
assuming the stub is in the before block, you ca
El 29/6/2009, a las 9:33, Matt Wynne escribió:
On 28 Jun 2009, at 23:02, Wincent Colaiuta wrote:
El 28/6/2009, a las 23:04, Matt Wynne escribió:
On 28 Jun 2009, at 13:07, Wincent Colaiuta wrote:
I've had one of my recurring doubts about test doubles come up
again.
The full post is
El 28/6/2009, a las 23:04, Matt Wynne escribió:
On 28 Jun 2009, at 13:07, Wincent Colaiuta wrote:
I've had one of my recurring doubts about test doubles come up again.
The full post is here but I'll abbreviate the content in this
message in any case:
https://wincent.com/blo
I've had one of my recurring doubts about test doubles come up again.
The full post is here but I'll abbreviate the content in this message
in any case:
https://wincent.com/blog/thinking-about-switching-to-rr
Basically, in one of my controller specs I wanted to verify that the
following
Has anybody had any luck getting Cucumber, Webrat and Selenium to play
nicely together for SSL sites?
My test environment:
- nginx front-end accepting SSL requests, proxying them to mongrel
back-end
- mongrel back-end accepting normal HTTP requests
- application routes configured with ":p
El 19/2/2009, a las 7:56, David Chelimsky
escribió:
rspec-1.2 and rspec-rails-1.2 are just about ready, but I'd like to
get some feedback from the field before the release. Would the
adventurous among you kindly grab the latest github gems (1.1.99.7 as
of this email) and check 'em out? I'm ho
El 14/2/2009, a las 21:56, James Byrne escribió:
Wincent Colaiuta wrote:
# always return false for tests
return false if RAILS_ENV == 'test'
I brand this as "hideous" because it commits the heinous crime of
dynamically modifying application behaviour only when exe
Thanks for the reply, James.
El 13/2/2009, a las 16:28, James Byrne escribió:
You could consider moving your spec_helper method into a separate
library module, put that in /lib and load it in
config/environments/test.rb.
Moving the hack from the spec_helper.rb file into a different file
un
I'm trying to write features for an SSL-only site, but I can't test
anything because every request in my stories results in a redirect
(the site is set up to redirect non-SSL requests to SSL).
In my _specs_ I hack around this problem with this nasty kludge in my
spec_helper:
module Acti
I am trying to convert from Story Runner to Cucumber so have started
with a really minimal story, but am dying with exceptions in
ActiveRecord's decrement_open_transactions method. I started took my
shortest story and trimmed off steps until I got it down to the
minimal case that aborts:
Hi folks,
Up until now I've always used RSpec as a plug-in in my vendor dir, but
seeing as the gem is the endorsed way to install I decided I would try
the gem this time (still vendoring it though because I vendor
everything).
Anyone had any luck doing that?
Here's what I did. First, to
El 26/9/2008, a las 16:16, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
On Fri, Sep 26, 2008 at 8:42 AM, Wincent Colaiuta <[EMAIL PROTECTED]>
wrote:
El 26/9/2008, a las 14:59, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
On Thu, Sep 25, 2008
El 26/9/2008, a las 14:59, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
On Thu, Sep 25, 2008 at 3:50 PM, Wincent Colaiuta <[EMAIL PROTECTED]>
wrote:
The following trick, calling "pending" from inside the before block,
effectively does what I want. But
El 26/9/2008, a las 13:30, Ashley Moran
<[EMAIL PROTECTED]> escribió:
On Sep 25, 2008, at 9:50 pm, Wincent Colaiuta wrote:
The following trick, calling "pending" from inside the before block,
effectively does what I want. But I'm wondering if I can count on
this be
Hi folks,
Wondering what the best (that is, neatest and most supported) way to
conditionally turn off some specs depending on the runtime platform.
Background: some of my specs call out to some third-party tools that
may or may not be installed on the system. I'd like to check for the
pre
El 11/9/2008, a las 11:58, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
On Wed, Sep 10, 2008 at 3:06 AM, Wincent Colaiuta <[EMAIL PROTECTED]>
wrote:
Hi all,
I had some stories which worked fine under RSpec 1.1.3 which are
broken
under 1.1.4 (suddenly all steps
Hi all,
I had some stories which worked fine under RSpec 1.1.3 which are
broken under 1.1.4 (suddenly all steps are marked as PENDING, and one
of the steps raises a NoMethodError due to an unexpected nil object in
the store_and_call method of rspec/lib/spec/story/world.rb).
Here is the ou
El 18/4/2008, a las 14:16, David Chelimsky <[EMAIL PROTECTED]>
escribió:
> On Apr 18, 2008, at 3:43 AM, Dan North wrote:
>
>> With mercurial I nearly did a similar thing, working on my own but
>> committing from two different machines. Luckily mercurial gave me a
>> warning that allowed me to mak
El 18/4/2008, a las 11:44, "Pat Maddox" <[EMAIL PROTECTED]> escribió:
> I believe that pull-merge-commit would work fine, I experimented
> locally to understand the effects of handling submodule reference
> merge conflicts. As I mentioned before, it is just a bit of a hassle
> to have to do. Dav
El 9/4/2008, a las 20:15, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
>
> It's official: http://tinyurl.com/5npxxb
>
> Git some happiness!
>
> Cheers,
> David
One thing, on the wiki you say:
> The easiest way to create a clean history is to make a new branch
> that tracks RSpec’s master
Perhaps I am missing something extremely obvious, but I am unable to
get my specs to work for an ArticlesController which is accessed using
URLs like "/wiki/foo".
Here's the corresponding line from config/routes.rb:
map.resources :wiki, :controller => 'articles'
This is Rails 2.0.2, but i
Rails mailers live under "app/models" even though they have some
controller-like responsibilities, and I stick the corresponding specs
under "spec/models"
In one of my mailers I use the kind of dynamic route generation
methods that Rails provides, things like foo_bar_path and foo_bar_url.
W
Is it just me, or is the output of "spec --diff" "back to front"?
In other words given expected result:
foo 1
foo 2
foo 3
And actual result:
foo 1
foo 2
bar x
foo 3
This is what "spec --diff u the_spec.rb" shows me:
2)
'Thing should blah' FAILED
expected: "foo 1\nfoo 2\nfoo 3\n",
got: "
El 18/11/2007, a las 0:59, [EMAIL PROTECTED] escribió:
> Probably not. There was a longer discussion of it here:
> http://rubyforge.org/tracker/index.php?func=detail&aid=13837&group_id=797&atid=3152
>
> As you point out, creating an alias is a one-liner.
> The main reason I don't want to add it is
(Coming in a little late on this thread...)
Although I use "should" in basically all of my examples I share some
of Brian's objections to it. IMO, the strongest argument against it is
that it is repetitive, and the strongest argument in its favor is that
it perfectly captures the discrepancy
El 31/10/2007, a las 15:40, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> On Oct 30, 2007 7:05 PM, Ashley Moran <[EMAIL PROTECTED]> wrote:
>> Hi
>>
>> I can't get heckle working. In fact, I've built an example so simple
>> that it either shows a bug, or I am being really, REALLY stupid.
>
>
El 21/10/2007, a las 14:42, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
>
> On 10/21/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
>>
>> Not actually a big deal; seeing as the specs don't have any side-
>> effects and running them twice
Given the following ApplicationController specs:
describe ApplicationController, "one facet", :shared => true do
it 'foo' ...
it 'bar' ...
end
describe ApplicationController, "some other facet", :shared =>
true do
it 'abc' ...
it 'xyz' ...
end
describe Applic
El 19/10/2007, a las 0:41, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> On 10/18/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
>> El 18/10/2007, a las 18:42, "David Chelimsky" <[EMAIL PROTECTED]>
>> escribió:
>>
>&g
El 18/10/2007, a las 18:42, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> Easier to type, sure. I'm not in love w/ the names yet though because
> they sound like verb phrases - "given matcher", "when matcher", "then
> matcher".
>
> How about something like match_given, match_when, match_then
El 18/10/2007, a las 10:33, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> Take a look at examples/story/calculator.rb to see what's going on.
>
> Needs docs
>
> Thoughts welcome.
Could this:
step_matcher(:given, "an addend of $addend") do |addend|
@adder ||= Adder.new
@add
El 17/10/2007, a las 7:26, "Pat Maddox" <[EMAIL PROTECTED]> escribió:
> Well, you'll find differing opinions on this. Every time I've done
> validations I've written a spec that actually exercises the behavior.
> For example
>
> class Person < ActiveRecord::Base
> validates_presence_of :name
>
El 16/10/2007, a las 6:50, Steve <[EMAIL PROTECTED]> escribió:
> Is anyone out there writing specs to check attr_accessible fields?
> I had
> originally written my spec to check for allowing the desired
> fields, and
> then none of the other regular db fields. Unfortunately this isn't
> satisf
El 16/10/2007, a las 2:44, "Pat Maddox" <[EMAIL PROTECTED]> escribió:
>> Wincet Colaitua brings up a good point [3] in regards to
>> StepMatchers:
>>
>> "My main concern here is that you're now having to keep two
>> files in
>> sync to have the stories work properly."
>
> Perhaps there was
El 16/10/2007, a las 0:58, Jay Levitt <[EMAIL PROTECTED]>
escribió:
> Yeah.. this is an age-old Internet debate, of course, but I think the
> problem is that (a) we're all top-quoting but (b) we're never
> trimming,
> not even the mailing-list footer.
>
> If you're gonna top-quote/bottom-post
El 15/10/2007, a las 17:01, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> Part of this is to separate the programming 'noise' from the text, so
> if we do head down this path (which remains to be seen) I doubt these
> would end up in the same file.
Thinking about this, the only way to reall
El 15/10/2007, a las 14:21, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> On 10/15/07, Wincent Colaiuta <[EMAIL PROTECTED]> wrote:
>>
>> - The customer/client (not necessarily with any programming
>> knowledge) writes the stories in a format which
El 15/10/2007, a las 14:21, "David Chelimsky" <[EMAIL PROTECTED]>
escribió:
> On 10/15/07, Steve <[EMAIL PROTECTED]> wrote:
>> Should the stories dir be located on the project root? I was
>> expecting to
>> find it located under spec/ but there isn't anything there, just the
>> stories dir off
El 15/10/2007, a las 14:21, "Pat Maddox" <[EMAIL PROTECTED]> escribió:
> On 10/14/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
>> On 10/14/07, Pat Maddox <[EMAIL PROTECTED]> wrote:
>>> Actually a parser for this would be quite simple
>>
>> Dead simple. It would also allow us to do away with meth
El 15/10/2007, a las 5:49, [EMAIL PROTECTED] escribió:
>>> Actually a parser for this would be quite simple
>>
>> Dead simple. It would also allow us to do away with methods like
>> Given, When and Then, which some people have objected to (because of
>> the capitalization), because the stories are
El 3/10/2007, a las 22:23, Carl Porth escribió:
> I'm having trouble with TextMate and assigning the RSpec language to
> *_spec.rb files within rails projects. Here is what is happening:
>
> I'm in a file that has the language "Ruby on Rails" selected.
> I do a ctrl-shift-down to switch to the co
El 27/9/2007, a las 22:23, Pat Maddox escribió:
> I'm sure you could hook into some kind of validator. I jumped on
> RubyForge and found http://rubyforge.org/projects/feedvalidator/. It
> kind of sucks because you'd depend on a web service for this...there
> have to be validators that you can ru
El 16/9/2007, a las 15:38, Jay Levitt escribió:
> * Test::Unit is ubiquitous. Everyone knows it. This is hard to
> counter; it comes with Rails and is the default.
Sorry to hear that you lost the fight. And that "better" doesn't
always win. For me "better" beats "ubiquitous" any time.
Ah wel
El 10/9/2007, a las 8:01, Ben Mabey escribió:
> Hey all,
> A couple of weeks a go I posted a quested about using rSpec to spec C
> code. Soon after I posted that I found about about SWIG.. anyways, I
> have posted a quick example on how easy it is to use rSpec with C:
> http://www.benmabey.com/20
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
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
El 7/9/2007, a las 5:36, Jay Levitt escribió:
>> There's a very useful guideline in TDD that says "test YOUR code, not
>> everyone elses." The validation library we're testing here is
>> ActiveRecord's. It's already tested (we hope!).
>
> Right... and I'm not testing that ActiveRecord's validation
El 4/9/2007, a las 22:51, Geoffrey Wiseman escribió:
> Using this as an example, if a new validation rule is added, this
> test will
> fail without indicating /why/. Sure, I can get that answer in
> other ways,
> but I'd hate to discover things like:
>
> it "should be valid with valid attribu
El 3/9/2007, a las 13:59, Ashley Moran escribió:
> Hi
>
> Easy one - I just wondered why all spec files for rspec_on_rails end
> "_spec.rb" instead of just ".rb"? They are all inside the spec
> folder so surely the fact they are specs is implicit?
>
> Ashley
I know it's very application-specific
El 1/9/2007, a las 11:15, Peter Marklund escribió:
> I understand where you're coming from Tom. But it's currently two
> script/plugin installs to start using RSpec with Rails, making it be
> three (the current two plus a mocking framework) is presumably not
> going to change adoption or the hurdl
1 - 100 of 108 matches
Mail list logo
