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 rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users