One way would be to use an environment variable:
$ CUSTOMER=foo spec spec
Then read out the customer name in your specs:
login = ENV['CUSTOMER']
Otherwise, I would guess you might be able to look at ARGV from
within, say, spec_helper.rb but I've never tried it.
On 3 Feb 2010, at
On Feb 02, 2010, at 8:58 am, Kristian Mandrup wrote:
Where should the spec command be found?
Did you find it?
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
___
rspec-users mailing list
rspec-users@rubyforge.org
On Tue, Feb 2, 2010 at 19:00, Frank Lakatos m...@franklakatos.com wrote:
Hi guys, been following for about 3 weeks, first question -
This might help a little: http://bit.ly/ONpXE
To bring things back to Rails, I use mock_model whenever I want to
design controller behavior without relying on
On 3 Feb 2010, at 11:35, J. B. Rainsberger wrote:
I find this rule of thumb helpful: stub unless you're certain to want
to verify this time that the client invoke the server correctly, and
never, never mock multiple methods at once.
Right, because the mock (should_receive) is an assertion,
On Wed, Feb 3, 2010 at 8:18 AM, Matt Wynne m...@mattwynne.net wrote:
On 3 Feb 2010, at 11:35, J. B. Rainsberger wrote:
I find this rule of thumb helpful: stub unless you're certain to want
to verify this time that the client invoke the server correctly, and
never, never mock multiple methods
Ok, so these ideas seem kind of natural to me, which is nice:
mock_models being used to mock non-tested models
stub for queries and/or well-tested methods, should_receives for commands
While reading over Dave Astlels, I kind of got concerned because of
something he states that I feel I'm
On Wed, Feb 3, 2010 at 8:52 AM, m...@franklakatos.com wrote:
Ok, so these ideas seem kind of natural to me, which is nice:
mock_models being used to mock non-tested models
stub for queries and/or well-tested methods, should_receives for commands
While reading over Dave Astlels, I kind of
To say thank you for all your constuctive feedback would not be
enough; all these insights are really helping me to get the provebial
it.
Dave, I completely agree that the mock_model(ActiveRecord) was
bizzare, but my specs kept failing because @projects was to receive
.build, and it
On Wed, Feb 3, 2010 at 2:07 PM, m...@franklakatos.com wrote:
I absolutely love the idea of encapsulated the daisy chained calls
(c_u.comp.project) into a controller methods so all i gotta do is stub that
out.
Oooh, I hate that one :)
You're adding lots of small methods that actually don't
2010/2/3 Nicolás Sanguinetti godf...@gmail.com:
On Wed, Feb 3, 2010 at 2:07 PM, m...@franklakatos.com wrote:
I absolutely love the idea of encapsulated the daisy chained calls
(c_u.comp.project) into a controller methods so all i gotta do is stub that
out.
Oooh, I hate that one :)
You're
A bit off topic, but does anybody know if there's an equivalent to
spec_server for test-unit style tests?
Thanks.
-r
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On Wed, Feb 3, 2010 at 4:36 PM, rogerdpack rogerpack2...@gmail.com wrote:
A bit off topic, but does anybody know if there's an equivalent to
spec_server for test-unit style tests?
spec-server was deprecated and removed a few versions back in favor of
spork, which works with rspec and test/unit
Hello group,
I've searched through several months messages in the archive, but haven't
found an answer to this...
What is the 'best practice' way to structure RSpec code and documentation
when testing a very large project, where the RSpec code base has to be
maintained and extended over a long
13 matches
Mail list logo
