On 02/02/2011, at 3:47 PM, Wincent Colaiuta wrote:
> 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 behavior of the code and not with the internal
> implementation details. For me, private methods fall under "internal
> implementation details".
>
> Being non-brittle and focussed on externally-visible behavior rather than
> implementation is a valuable attribute for a spec suite to have, because it
> allows us to refactor and improve the code with confidence that the behavior
> remains unchanged, but without having to engage in duplicative and
> error-prone updating of our specs to match the internal changes in
> implementation.
>
> So, if you're feeling the need to spec private methods, its an indication
> that you could be doing something better, because you're either:
>
> - specifying internal implementation details (and if that's the case, why are
> you specifying it?); or
>
> - you've made something private that shouldn't really be that way (and in
> that case, there are various refactorings you can use to restructure the code
> in order to make it more amenable to testing)
>
> Cheers,
> Wincent
>
That's hopefully already fairly obvious. Yes, I agree. Program to an interface.
The idea is pretty much scope: ie, it depends what you're testing... it's the
behaviour of the thing you're testing that is important...
We have application-level scope ("behaviour testing"), class-level scope
(testing that the class does what it's supposed to) and method-level scope
dependant on what we're programming, right?
If I'm programming a method, I want to test that it does certain things
(preferably the things it's supposed to do, right? This is, after all, what a
spec is....).
Binding a set of components together to build an enclosing component, each
component should have tests... including any enclosing components.
Encapsulation of tests... :-)
Julian.
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
