[rspec-users] Mocking, changing method interfaces and integration tests
pergesu at gmail.com
Fri May 25 18:38:02 EDT 2007
On 5/25/07, Courtenay <court3nay at gmail.com> wrote:
> Pat, I use rails' integration tests to test my whole app. Usually I
> get lazy, and just dump my production data into the test DB and tell
> my SpiderTest to just spider every single page and tell me what broke.
That's cool. I discussed what I think of the integration tests in my
response to David. I'd be really interested to know if I'm missing
key benefits though.
> Also, I try to hide my database code behind methods, so 'find_by_user'
> would forever remain as a method and whatever DB code will always be
> hidden there. To the controller, the actual fields I'm using are
> irrelevant. When starting a new project I'll try hard to define a
> nice uncoupled interface between models and controllers. It's like,
> when you assume that the model's public methods will never change, you
> name them a bit differently.
Totally. I did end up just writing a find_by_user method that
delegated to find_by_username, so I didn't have to change any of my
application code. My concern though was that I didn't know it broke
in the first place because I was using mocks. But you're right, had I
just written and tested find_by_user method instead of using the
dynamic finder, I wouldn't have run into that issue. I'll be sure to
keep that in mind. It goes along with "don't mock APIs you don't
own," and I certainly don't own the dynamic finders.
> I'm not much of a theorist, though, and much prefer to let others kick
> it out and wait for the dust to settle.
> On 5/25/07, Pat Maddox <pergesu at gmail.com> wrote:
> > This is something I've kind of struggled with over the past few months
> > . And just yesterday I made the decision to move away from mocks
> > in most cases. That decision resulted from me changing a db column
> > name from 'user' to 'username', but one of my tests mocked a
> > #find_by_user method, so the test passed even though my code was
> > broken.
> > Just to note, I've got ~7k lines of Rails spec code that uses mocks,
> > and tens of thousands that don't. So I've used both approaches
> > extensively in multiple projects, and have formed the following ideas.
> > I think David has a really good point about mock usage being related
> > to customer/programmer test coverage. At this point, we don't have
> > any customer tests. I also don't like the idea of relying on
> > heavyweight browser-based tests. I want to be able to run rake and
> > know that my code works.
> > Over the past week, I've converted a number of my controller tests to
> > use the real implementations instead of using mocks. It was obvious
> > when I realized that in my controllers I'm concerned with state a lot
> > more than interaction - a request is made, some state changes, a
> > response is given. I want my tests to prove that those state changes
> > are actually being made. In this way, my controller specs act as
> > integration tests. I do a *tiny* bit of mocking in controller specs,
> > in cases where I can't verify state such as making some notification
> > request to another machine in the system.
> > I'm still using mocks quite a bit in my model specs, and I'm not quite
> > sure if I'll be cutting back or not. Just going to take it a day at a
> > time and try to remove any pain.
> > You've all surely read Martin Fowler's discussion about
> > interaction-based vs state-based testing. One of the points Dave
> > Astels always hammers on about BDD and interaction-based testing is
> > that it's not testing, it's a design tool. I've found that with mocks
> > I tend to arrive at a better design earlier on than I do without
> > mocks. I've also found that I can't change the design very easily.
> > Mocks are coupled to the design of the code, not the behavior. Aslak
> > says that state-based testing ain't BDD , but I disagree. If I
> > can't refactor - changing the design of the code without changing the
> > behavior - that doesn't seem very behavior-driven to me.
> > Mocks are nice as a design tool, but I've come to accept the fact that
> > creating a moderately good design early isn't as useful as having the
> > freedom to change my design later on. I'm just not good enough to
> > come up with the perfect design the first time around. My tests need
> > to give me the confidence to refactor. And I need to be able to run
> > those tests quickly from the command line rather than having to start
> > up a browser, even if it's automated. In that regard, mocks just
> > aren't for me, at least on my current project.
> > Sorry for the length. pat.should be_less_verbose
> > Pat
> >  http://evang.eli.st/blog/2007/4/9/i-think-i-might-not-get-mocks
> >  http://www.martinfowler.com/articles/mocksArentStubs.html
> >  http://blog.aslakhellesoy.com/2006/12/11/the-bdd-cargo-cult
> > (for some reason it doesn't feel right to link to my blog and MF's
> > bliki together :)
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users