Hacker News Reader

Comment by kentwistle | Hacker News Reader

Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me.

You know what could increase the speed dramatically.... decoupling.

I also think decoupling phrased in the context of the Rails 2 to Rails 3 upgrade, where pretty much everything changed, makes perfect sense. Imagine just having a few wrapper classes that spoke to Rails and only having to adapt them. Sounds good to me!

Bernhardt: Boundaries http://www.confreaks.com/videos/1314-rubyconf2012-boundaries

Weirich: Decoupling from Rails http://www.youtube.com/watch?v=tg5RFeSfBM4

Wynne: Hexagonal Rails http://www.youtube.com/watch?v=CGN4RFkhH2M

View on HN

You know what has a high chance of introducing a crap ton more bugs? Unnecessary code. :)

Also, did you read the rest of the post? Typical test cycles are much faster than that. But a full test of the entire system takes some time. As it should.

This is also why the test suite for git takes a long time, but has a very good signal to noise ratio.

> You know what has a high chance of introducing a crap ton more bugs? Unnecessary code. :)

If only that "unnecessary code" had tests... Oh wait.

At some point, you will find you have bugs in the tests. It isn't like that code is magically immune to mistakes.

Not to mention you have increased the workload of everyone just to mitigate the impact of additional code. Let me know how that works out for you. :)

Slightly more complex code with tests beats code with no tests every time, and it works just fine. Having 1 more class or function call is not exactly what makes an impact on workload. If you are optimizing your application by reducing function calls you are doing it wrong. But tell me, how does not having tests work out for you? Can you modify old applications, or applications that you didn't develop alone, with a high degree of certainty that you didn't break things in the least expected places?

At no point was it declared there were no tests. So... different topic?

Seriously, straw men not withstanding, this thread is specifically about tested code where a complaint was raised about how long the tests take. And the "how long" was only 4 friggin minutes for a full suite, or 4 seconds for a module.

Five minutes of tests really isn't such a big deal. Not long enough to bother re-architecting a bunch of stuff. But what frustrates me is that DHH seems to bullheadedly continue believing that problems they haven't had with Bootcamp simply aren't real problems. Bootcamp isn't all that big an app, so it isn't particularly surprising that the tests run that quickly. But once you get up into the high tens of minutes for unit tests, and the low hours for a full suite including end-to-end tests, it becomes really really annoying. Changing the architecture isn't going to help much or at all with those end-to-end tests, but it's easy to find yourself thinking "boy I wish we could at least get a bit of confidence in the correct functioning of our application in the face of this little change in less than half an hour - I wonder how we could accomplish that?". The three common answers once you find yourself wondering that are "let's parallelize our tests in the cloud!", "let's reduce external coupling in our tests!", and "let's make small services so any given change affects only a few tests!". All of those answers have fairly tough trade-offs.

> Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me.

I don't really mind if a given branch is marked red on CircleCI. master must always be green, but a branch, not so much.

Say I change a model. I'll probably run the unit test for that model (4 seconds), then just push up the branch and forget about it. 9 times out of ten, I didn't break any other tests and everything's fine. Once in a while, I did, and 3-4 minutes later Circle via HipChat let's me know I need to check it again.

It's a bit meta, but this process is just like actual Rails apps—when the task can happen asynchronously in the background, it usually doesn't matter if it takes a couple minutes.

In a 30 KLOC rails project I find those numbers acceptable. Also you are unlikely to run the full suite after every editor save. Even Jim Weirich runs a single test file and not the full suite.

Its not supposed to be impressive, its supposed to be quick enough to provide a reasonable feedback cycle, with the ability to run specific tests that is drastically reduced, you make a few changes, run the relevant tests (they can run automatically via watching), tests pass you are happy, if its an intrusive change you might want to run the full suite before pushing, then when you push CI runs a far more exhaustive set of tests (possibly across patforms), these can happily take a lot more time.

It differs very much across projects, full pouchdb test suite takes ~4 minutes, full firefox test suite takes hours, for rails ~4 minutes sounds entirely reasonable (kinda faster than I would expect) and wouldnt give me no reason to think about reducing the coverage and reliability of the tests by decoupling anything.

Yes it is too slow. After having taking the time to build a decoupled Rails application I can tell you that having tests run in under 2 seconds has been a great help in refactoring and allowing us to quickly add new features. I can't imaging how we'd add new features without it.

"Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me."

No.

It kinda feels like you didn't read the whole way through.

He mentions per model, which is what you're doing while doing dev, it's 4 seconds.

Reply on news.ycombinator.com