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

31–40 of 46 posts

Re: Slow Tests Are the Symptom, Not the Cause

#31

Post by programminggeek »

lectrick wrote: post #26
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?

Surprisingly, even though the original version was built in ruby, people are taking the structure and using it in .NET, Java, etc. A lot of things we had to build in ruby already exist as things like interfaces in other statically typed languages.

In a language like Scala Obvious is literally just a way you would organize your program, not so much a library. It already has everything else you need, even things like immutability (if you're into that kind of thing). I just wish it compiled faster.

Obviouscasts is built on Obvious. I built a cool pluggable newsletter tool that you could trivially plug in Mailchimp, Mailgun, Sendgrid, or just your boring SMTP stuff to it. It was a heroku deployable newsletter so that you didn't have to pay monthly fees to a company like AWeber, Mailchimp, etc. just to collect emails for a list that won't be used very often.

I'm working on building out some new things in go with Obvious architecture behind them.

At my old job, some of the Obvious structure ended up powering the ruby services behind StBaldricks.org, which does $30+ million in donations and millions of page views a year.

I honestly don't know of many more examples beyond that, but it's a very small project and it was open sourced in January.

Re: Slow Tests Are the Symptom, Not the Cause

#33

Post by VeejayRampay »

Isn't part of the problem the fact that Ruby is ridiculously slow? I'm not even trolling, I am a Ruby programmer, I've used the language for about 5 years now and seeing friends of mine run their 200+ files test suite in under half a second (C programmers), I can't help but think about how nice that must be to be able to run your tests when you want to without thinking of the consequences (and yes I understand comparing C and Ruby is ludicrous, just pointing to the fact that Ruby is still extremely slow and would very much benefit from a good speed bump eventually).

Cause slow tests as a symptom pretty much means that if you're not an excellent programmer then tough sh*t, testing will be slow and painful, which ultimately drives people away from those good practices.

Also, I find ironic that Rails (as a framework that is supposed to empower people and make them efficient) is, according to many comments in this thread and "tech pundits" conducive to the kind of tight coupling and dependency that will lead to bad design choices and slow tests.

Re: Slow Tests Are the Symptom, Not the Cause

#34

Post by pan69 »

VeejayRampay wrote: post #33

Isn't part of the problem the fact that Ruby is ridiculously slow? I'm not even trolling, I am a Ruby programmer, I've used the language for about 5 years now and seeing friends of mine run their 200+ files test suite in under half a second (C programmers), I can't help but think about how nice that must be to be able to run your tests when you want to without thinking of the consequences (and yes I understand compar…

>> and seeing friends of mine run their 200+ files test suite in under half a second (C programmers)

But they need to spend half hour compiling before they can run their tests.

[tongue in cheek obviously]

Re: Slow Tests Are the Symptom, Not the Cause

#35

Post by regularfry »

lmm wrote: post #4

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 ass…

I'd argue that even a test which is a copy and paste of the implementation method - literally the same code, twice - has value, because you can then refactor the implementation as much as you like in future and know that you're covered. Nothing says that because they are the same now, they will be forever.

Re: Slow Tests Are the Symptom, Not the Cause

#36

Post by regularfry »

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…

I think this is actually an argument that the tests are telling us that having a controller class this shape isn't the design we should aim for.

Re: Slow Tests Are the Symptom, Not the Cause

#37

Post by regularfry »

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…

TDD advocates would disagree.

Re: Slow Tests Are the Symptom, Not the Cause

#38

Post by regularfry »

gingerlime wrote: post #30

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 of…

I think the key here is not to try to aim for anything like full coverage with capybara, just enough to be effective. Martin Fowler has some words on this here: http://martinfowler.com/bliki/TestPyramid.html

Re: Slow Tests Are the Symptom, Not the Cause

#39

Post by regularfry »

huntedsnark wrote: post #25

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.

Yes, but you don't run those all the time. It's the unit tests that have to be fast, and if they aren't, that's a problem.

Re: Slow Tests Are the Symptom, Not the Cause

#40

Post by schmrz »

regularfry wrote: post #37
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…

TDD advocates would disagree.

I'm not sure I follow. What exactly would TDD advocates disagree on?
Post reply on HN