Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slow Tests Are the Symptom, Not the Cause

re-factor.com

Post reply on HN
Print view View original

1–10 of 46 posts

Re: Slow Tests Are the Symptom, Not the Cause

#2

Post by bradhe »

Was mostly with the author right up until he shows an example of the worst possible unit test. Testing the implementation and not the intent.

This feels like how Spring must have been born. Trying to think of an alternative, and I think I would be happy with the fat controller example originally given. It's simple enough and straight forward.

Perhaps it's just bad examples all the way around...

Re: Slow Tests Are the Symptom, Not the Cause

#4

Post by lmm »

In my experience when you do this you end up with anaemic tests that are basically useless. As the page comes close to admitting, all you do is write the same code twice. The result is a lot of wasted effort on unit tests that never fail.

In an app designed like this the integration tests are the useful ones, because they're more contentful and test assumptions that are more likely to be wrong. The article flatly asserts that code written in this extremely decoupled style will require fewer integration tests, but I see no evidence for this. And you still need to figure out how to make them run fast.

Re: Slow Tests Are the Symptom, Not the Cause

#7

Post by lectrick »

bradhe wrote: post #2

Was mostly with the author right up until he shows an example of the worst possible unit test. Testing the implementation and not the intent. This feels like how Spring must have been born. Trying to think of an alternative, and I think I would be happy with the fat controller example originally given. It's simple enough and straight forward. Perhaps it's just bad examples all the way around...

I think this was only a poor example because the method under test was a "director" style method (not sure what the name of it would actually be) that simply forwards a bunch of messages/commands to other objects and doesn't do much actual logic/computation.

Tests for these "director" style methods must by nature assert that all the right messages were forwarded to the right objects under the right circumstances, so yes, you do end up with tests that look a lot like what they're testing.

Agreed that ideally you are only testing ins and outs though, but I think this case was exceptional.

Re: Slow Tests Are the Symptom, Not the Cause

#8

Post by orend »

bradhe wrote: post #2

Was mostly with the author right up until he shows an example of the worst possible unit test. Testing the implementation and not the intent. This feels like how Spring must have been born. Trying to think of an alternative, and I think I would be happy with the fat controller example originally given. It's simple enough and straight forward. Perhaps it's just bad examples all the way around...

As I mention in the post, I'd also be perfectly happy with the original if the rest of the application was small and simple. It's hard to come up with an example that's both meaningful and not too long for a blog post.

As for the testing issue, we have a controller-like object there, and a controller’s job is to coordinate sending messages between collaborators so I don't think a unit test for this object should test anything than these interactions. This also might be a consequence of using a simple example.

Re: Slow Tests Are the Symptom, Not the Cause

#9

Post by yxhuvud »

Personally I would have

1: Added a users resource beneath the mailing list, ie

  resources :users
  resources :mailing_lists do 
    resources :users
  end
add_foo is almost always a sign that a new nested controller should be made, and there is almost always a need for a delete as well - in this case users should be able to remove themselves from a mailing list.

2: Put the add method on the mailing list and not on the user, because that is where I'd expect the least logic to be.

because:

3: I'd put the actual mailing list mailer logic in a separate class for the configuration of it.

Re: Slow Tests Are the Symptom, Not the Cause

#10

Post by pkolaczk »

lectrick wrote: post #7
bradhe wrote: post #2

Was mostly with the author right up until he shows an example of the worst possible unit test. Testing the implementation and not the intent. This feels like how Spring must have been born. Trying to think of an alternative, and I think I would be happy with the fat controller example originally given. It's simple enough and straight forward. Perhaps it's just bad examples all the way around...

I think this was only a poor example because the method under test was a "director" style method (not sure what the name of it would actually be) that simply forwards a bunch of messages/commands to other objects and doesn't do much actual logic/computation. Tests for these "director" style methods must by nature assert that all the right messages were forwarded to the right objects under the right circumstances, so…

It is better to not have a test at all than to have a test that looks a lot like what it is testing. I never uderstood that crazy push for 100% unit test coverage that some are advocating. Unit tests are just one tool among many. Use with care and where appropriate.
Post reply on HN