[rspec-users] array order-agnostic matching?

Julian Leviston julian at leviston.net
Wed Feb 2 00:39:31 EST 2011


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.




More information about the rspec-users mailing list