Zach Dennis wrote: > Can someone change this implementation and still have your tests pass, > but have the implementation be broken? If they can then yes it is > worth the 40 lines.
It is partly this paranoia of someone changing the code that makes me question testing of this magnitude. Other than attaching files if a file was uploaded I have yet to have any real logic in my controllers, so I can't imagine why I would change anything, but maybe that is how it all starts :) > The problem I have with what Pat is doing is that it takes a lot of > discipline from the developer to not let the controller grow into a > cesspool of logic and interaction that shouldn't be there, but you put > it there because you aren't "testing" it directly. From what I've seen > most Rails apps have important interaction in the controller actions > and logic in the before filters. I would not personally take this > approach on customer paid for software. Pat may be more disciplined > then me though. =) I guess that is where I am blind, as I don't have any apps that have reached the point of "additional functionality" yet. > If a change to one object results in multiple failing integration > tests, then that is awesome because you know exactly what you broke > with that change. If that change breaks a bunch of model, controller, > etc specs then how there is an issue in how you're testing. After writing a lot of tests I began to think that taking more of a black box approach, ie test what goes in and what comes out, is the best way in that it allows me to make changes inside the box, without having to pick up the pieces of all the broken tests. > Dennis my last name. Zach is my first name ;) :) Sorry about that, I figured that out right after I posted. Somehow I saw Dennis and that is what registered upstairs. -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
