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