Does the plain text story framework support teardowns? There doesn't
seem to
be anywhere to put an after method. My stories test an application
which
parses and modifies a directory tree, which is currently generated in
a
Given-clause, and I want it to be deleted after each story. (I
On Jan 11, 2008 2:50 AM, David Chelimsky [EMAIL PROTECTED] wrote:
On Jan 11, 2008 4:48 AM, Pat Maddox [EMAIL PROTECTED] wrote:
On Jan 11, 2008 2:33 AM, Kerry Buckley [EMAIL PROTECTED] wrote:
This isn't specific to RSpec, but is hopefully on-topic for this list.
I like (especially
On 11 Jan 2008, at 10:50, David Chelimsky wrote:
On Jan 11, 2008 4:48 AM, Pat Maddox [EMAIL PROTECTED] wrote:
lots of sensible advice
Apparently, Pat and I are twins separated at birth.
Thanks both!
Kerry
___
rspec-users mailing list
On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) [EMAIL PROTECTED] wrote:
Daniel Tenner:
Might be a personal thing, but my approach is that I try to test the
public behaviour of the object. Testing private methods is, imho,
getting dangerously close to specifying how the object does its
Does the plain text story framework support teardowns? There doesn't seem to be
anywhere to put an after method. My stories test an application which parses
and modifies a directory tree, which is currently generated in a Given-clause,
and I want it to be deleted after each story. (I don't mind
Daniel Tenner:
Might be a personal thing, but my approach is that I try to test the
public behaviour of the object. Testing private methods is, imho,
getting dangerously close to specifying how the object does its
business, rather than what it does.
I agree on principle, but I ran into the
On Jan 11, 2008 8:04 AM, Shot (Piotr Szotkowski) [EMAIL PROTECTED] wrote:
David Chelimsky:
On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) [EMAIL PROTECTED] wrote:
One run of by_input_sets!() takes a couple of seconds, so can
be tested; one run of decompose!() takes much longer, so to
On Jan 11, 2008 9:45 AM, Tim Glen [EMAIL PROTECTED] wrote:
since i'm on rspec trunk, I applied your patch and ran into a little
issue. All my specs still run but it seems to be looking at and
attempting all of my hidden files and directories (and some other
stuff too?):
snippet
Dunno!
On Jan 10, 2008, at 8:27 PM, James Deville wrote:
We have a custom implementation of the Mother Object idea. It's inside
of a module, basically like this:
module Factory
%w(account friendship person invitation message asset email_address
birth).each do |klass|
eval
since i'm on rspec trunk, I applied your patch and ran into a little
issue. All my specs still run but it seems to be looking at and
attempting all of my hidden files and directories (and some other
stuff too?):
snippet
Dunno! Capfile
Dunno! app/helpers/.svn/format
Dunno!
David Chelimsky:
On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) [EMAIL PROTECTED] wrote:
One run of by_input_sets!() takes a couple of seconds, so can
be tested; one run of decompose!() takes much longer, so to test
decompose!() I should stub by_input_sets!() so it returns canned
data
On Jan 11, 2008 5:23 AM, David Chelimsky [EMAIL PROTECTED] wrote:
On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) [EMAIL PROTECTED] wrote:
Daniel Tenner:
Might be a personal thing, but my approach is that I try to test the
public behaviour of the object. Testing private methods is,
On Jan 11, 2008, at 5:50 AM, David Chelimsky wrote:
Apparently, Pat and I are twins separated at birth.
Would it then be correct to refactor and eliminate one of them??
:))
___
rspec-users mailing list
rspec-users@rubyforge.org
On Jan 11, 2008 10:19 AM, Jonathan Linowes [EMAIL PROTECTED] wrote:
On Jan 11, 2008, at 5:50 AM, David Chelimsky wrote:
Apparently, Pat and I are twins separated at birth.
Would it then be correct to refactor and eliminate one of them??
If you could argue that we were ultimately composed
On Jan 11, 2008, at 5:54 PM, Ben Mabey [EMAIL PROTECTED] wrote:
David Chelimsky wrote:
In TDD there is a rule of thumb that says don't stub a method in the
same class as the method you're testing. The risk is that as the real
implementation of by_input_sets!() changes over time, it has
On Jan 11, 2008 11:36 AM, Tim Glen [EMAIL PROTECTED] wrote:
very cool.
Funny enough, I never knew this functionality even existed - it was
just getting clobbered all this time.
It's only in the last release or two.
Now I see ~10 files that actually need specs, which were totally
getting
We pass the required items in as method arguments. In the spirit of
sharing code and getting people to review code. Here is our current
LoginManager:
class LoginManager
include Injection
inject :invitation_manager
def login_from_cookie(cookies, session)
CookieLoginManager.new(
To add, all of our managers return LoginResult objects which contain
methods like:
- successful?
- user
- message
In the controller our code will look like:
if login.successful?
self.current_user = login.user
else
flash[:error] = login.message
end
This has worked well because it allows
On Jan 11, 2008 3:16 PM, Pat Maddox [EMAIL PROTECTED] wrote:
A couple months ago I asked how stories and specs might impact each
other. [1]If you look at Dan North's example of what's in a story
[2], and you imagine using the spec framework to drive the design, you
can probably imagine a
very cool.
Funny enough, I never knew this functionality even existed - it was
just getting clobbered all this time.
Now I see ~10 files that actually need specs, which were totally
getting missed before!
thanks,
tim
On 11-Jan-08, at 10:56 AM, David Chelimsky wrote:
On Jan 11, 2008 9:52
On Jan 11, 2008 11:56 AM, David Chelimsky [EMAIL PROTECTED] wrote:
On Jan 11, 2008 9:54 AM, Ben Mabey [EMAIL PROTECTED] wrote:
David Chelimsky wrote:
In TDD there is a rule of thumb that says don't stub a method in the
same class as the method you're testing. The risk is that as the
On Jan 11, 2008 12:56 PM, Cody P. Skidmore [EMAIL PROTECTED] wrote:
Thank you Zach. I was just about to ask about this. I'm just getting
started with restful_authentication and have missed the context of your
point. restful_authentication is such a huge improvement over what I'm
use to.
On Jan 11, 2008 11:33 AM, Kerry Buckley [EMAIL PROTECTED] wrote:
This isn't specific to RSpec, but is hopefully on-topic for this list.
I like (especially when ping pong pairing) to write a spec, then
write the smallest amount of code I can to pass it (especially when
ping pong pairing).
On Jan 11, 2008 1:48 PM, David Chelimsky [EMAIL PROTECTED] wrote:
On Jan 11, 2008 3:43 PM, Pat Maddox [EMAIL PROTECTED] wrote:
I don't have any problem with that. I do things that way, and I get
my work done just fine. However, I'm having a tough time clarifying
my position when talking
I'm going to hijack this a bit :)
On Jan 11, 2008 1:25 PM, David Chelimsky [EMAIL PROTECTED] wrote:
But the target of stories are system level descriptions of behaviour.
This will inevitably appear to have some overlap with the specs for
the outermost layers of the system. But when you start
The thing is that, ideally, you don't want to have to make changes to
the tests for object A when you're refactoring B.
WDYT?
Yeah, I buy that. Not everyone does though. Or at least not everyone
feels that it's a particularly important goal.
I think the fear many of us classicists have
On Jan 11, 2008 5:11 PM, Jay Donnell [EMAIL PROTECTED] wrote:
The thing is that, ideally, you don't want to have to make changes to
the tests for object A when you're refactoring B.
WDYT?
Yeah, I buy that. Not everyone does though. Or at least not everyone
feels that it's a
27 matches
Mail list logo
