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

21–30 of 46 posts

Re: Slow Tests Are the Symptom, Not the Cause

#21

Post by lifeisstillgood »

programminggeek wrote: post #14

Pluggable systems (loose coupling) are the easiest way to create a system that is cheap and easy to maintain. I've found that a lot of Rails developers in particular don't see the benefits of this and they really, really like tightly coupled systems because of the convenience of it all. Benefits like fast, easy testing, easier maintenance, swappable external things like databases, queues, external api's are apparentl…

May I advert to you the recorded mutterings of a Gentleman named Fred George who advocates for "Programmer Anarchy" and "micro-web-services" (the last of which is a nice idea)

* http://www.infoq.com/news/2012/02/programmer-anarchy

* http://www.youtube.com/watch?v=uk-CF7klLdA

Edit: would help if I actually added some links

Re: Slow Tests Are the Symptom, Not the Cause

#22

Post by schmrz »

orend wrote: post #16
schmrz wrote: post #13

I don't know (and don't care) if this makes your unit tests faster, you shouldn't write code like that. He took something that should be simple and made it really complicated. The execution time of your tests shouldn't dictate how you will design and write your application. Especially if it makes things harder to maintain and understand. Edit: I love tests and they should be fast so that you can run them every time b…

The point here is not that the tests execution time should dictate the design. On the contrary, the idea of this post was to stress the importance of good design, and that fast tests are just a side effect of it. Now, you might disagree with me on what constitutes good design but that's a different issue.

Don't get me wrong, I agree with the idea that you should look at the root cause of why your tests are slow instead of trying to "fix" the tests. I just feel that what you demonstrated is bad design. So you ended up with bad design and fast tests.

Re: Slow Tests Are the Symptom, Not the Cause

#23

Post by steveklabnik »

lkrubner wrote: post #17
programminggeek wrote: post #14

Pluggable systems (loose coupling) are the easiest way to create a system that is cheap and easy to maintain. I've found that a lot of Rails developers in particular don't see the benefits of this and they really, really like tightly coupled systems because of the convenience of it all. Benefits like fast, easy testing, easier maintenance, swappable external things like databases, queues, external api's are apparentl…

Where I work, we just had a long internal debate about the usefulness of monolithic frameworks such as Rails and Symfony. I argued against the frameworks, but much of the team is committed to using them. The convenience of having everything in one place apparently is important to a lot of people, despite all the problems that are caused by that. I posted the debate here: http://www.smashcompany.com/technology/an-arch…

It's not actually Rails that's the problem, often: it's a cultural issue. You can build a Rails app that has a very thin 'rails' layer and has a super well decoupled domain model layer.

Re: Slow Tests Are the Symptom, Not the Cause

#24

Post by huntedsnark »

steveklabnik wrote: post #23
lkrubner wrote: post #17

Earlier quoted context omitted.

Where I work, we just had a long internal debate about the usefulness of monolithic frameworks such as Rails and Symfony. I argued against the frameworks, but much of the team is committed to using them. The convenience of having everything in one place apparently is important to a lot of people, despite all the problems that are caused by that. I posted the debate here: http://www.smashcompany.com/technology/an-arch…

It's not actually Rails that's the problem, often: it's a cultural issue. You can build a Rails app that has a very thin 'rails' layer and has a super well decoupled domain model layer.

Absolutely, the Rails app I'm working on right now is just like this. Still feels like Rails but the complex logic and interactions can run without it.

Re: Slow Tests Are the Symptom, Not the Cause

#25

Post by huntedsnark »

The slowest part of most tests suites are the integration and acceptance tests. Regardless of how decoupled my actual domain logic is, these will usually be the bottleneck, so I can't really agree with slow tests always being a symptom of some underlying architecture problem.

Re: Slow Tests Are the Symptom, Not the Cause

#26

Post by lectrick »

programminggeek wrote: post #14

Pluggable systems (loose coupling) are the easiest way to create a system that is cheap and easy to maintain. I've found that a lot of Rails developers in particular don't see the benefits of this and they really, really like tightly coupled systems because of the convenience of it all. Benefits like fast, easy testing, easier maintenance, swappable external things like databases, queues, external api's are apparentl…

Obvious looks great. Can't wait to try it on a project actually. Do you know anyone who's used it out in the wild to build cool stuff?

Re: Slow Tests Are the Symptom, Not the Cause

#27

Post by tieTYT »

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...

Spring was probably born as a reaction to EJB. And if you've ever written tests for EJBs you're grateful to Spring for providing an alternative.

Re: Slow Tests Are the Symptom, Not the Cause

#28

Post by ExpiredLink »

tieTYT wrote: post #27
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...

Spring was probably born as a reaction to EJB. And if you've ever written tests for EJBs you're grateful to Spring for providing an alternative.

I've written UnitTests for EJBs today. No Spring bloatware needed.

Re: Slow Tests Are the Symptom, Not the Cause

#29

Post by lucaspiller »

huntedsnark wrote: post #24
steveklabnik wrote: post #23

Earlier quoted context omitted.

It's not actually Rails that's the problem, often: it's a cultural issue. You can build a Rails app that has a very thin 'rails' layer and has a super well decoupled domain model layer.

Absolutely, the Rails app I'm working on right now is just like this. Still feels like Rails but the complex logic and interactions can run without it.

I would be interested to more details on how your architect things - we've been in the process of moving the business logic of our app into service objects as 2000 line models have become a bit unmanageable :D

Re: Slow Tests Are the Symptom, Not the Cause

#30

Post by gingerlime »

after reading sandi metz POODR[1], I tend to prefer the approach on the post too. However, I also must say that the time it takes to execute unit tests, even with factories, db access etc is still an order of magnitude faster than running things like feature tests with capybara. This is by far the biggest drain on test time (and resources), and these are also the tests most difficult to write and maintain. Way too often, when we decide to change some functionality, there's a whole battle with tweaking capybara tests to work again.

Perhaps I'm showing my lack of knowledge or experience with capybara, or integration testing, but that's one aspect I wish there were some better tools / approaches. Having to dig through css/xpath elements to click on or perform interaction is still a major PITA. If anybody has some suggestions to share, I'd love to learn more!

[1]http://www.poodr.com/

Post reply on HN