- Other features: I don’t use most of the fancy features, but I do find
stubs useful. Do you expect people to use when_told_to without
was_told_to? in order to stub something out?
- I also find the ‘null object’ pattern useful. That is where the
isolated object always returns nil to methods called on it.
- Finally, I’ve been slow on pushing lately because I’m moving, I’ll do
a push when I get to decent internet. I’ll also work on automating thid
in the next couple of weeks.
JD
…there is no try
Sent from my phone. Please excuse typos and txtspk.
Responses:
1: Yes stubbed by default and only when you’re actually interested in
asserting if it was called you use the was_told_to? assertion2: Yes
always
null unless you explicitly tell it to fall through to the implementation
of
the method. I may make use of the default(T) thing later on to return
the
default value for value types.
3: no problem I was just curious about that
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
Emma Goldman
http://www.brainyquote.com/quotes/authors/e/emma_goldman.html
- “If voting changed anything, they’d make it illegal.”
I- tried the pure stubbing approach as did Pete Y. with his
notamock
rails plugin - the stubs will return nil for any method call unless to
tell
them to do otherwise (return something, yield something and/or raise
something). So everything is a stub (just one that happens to be a .net
interface implementation) that records all calls for later inspection.
The null object i’ll add next (the stubs will just return another stub
instead of nil and record all calls).
The assertions are then at the end of the test/spec (where I think all
expectations should be) - at this stage you need to scan the list of
recorded calls - i’ll add some syntax to do nicer checking.
Does your final point suggest that the event implementation will be
available soon?
Mark.