[inetknght]

One minute? That's terrible. What kinds of tests and how many are you running?

> We never run all of our application’s tests in local development. It’s not a good use of time and will never be as fast as running them on CI.

WTF this is bad practice. Developers should always get in the habit of running tests locally first. No test should require running in the cloud. And, even more, it's actually rare that CI is more performant than your developers' machines. You should invest in your developers.

> Our whole test suite locally takes around 12 minutes running serially on a MacBook Pro.

That's really really really awful. Most projects' tests, even when they're poorly written, still run in 3 or 4 minutes. My own tests run on the order of single-digit seconds.

> We haven’t put much effort here because it’s not something our engineers ever run.

Well of course not. They can't iterate fast if they're slowed down by tests. That's why tests have to be fast!

> This gave us some speed gains, but we wanted it really fast. Our infrastructure team set us up with some 64 core machines

Holy schnapple if I had 64 core machines, a complete test suite would finish on the order of tens of milliseconds!

I'm glad ya'll have gotten your tests down from 12 minutes to 1 minutes. There's a ton more improving you can do though.

[quesera]

> Most projects' tests, even when they're poorly written, still run in 3 or 4 minutes. My own tests run on the order of single-digit seconds.

That is an absurd statement to make without context.

I work on a large project with a few thousand very well-written tests, which run in 24 minutes serially on a recent-era laptop, or under a minute in well-parallelized CI environment.

[hdjjhhvvhga]

How can you tell that if you don't know the complexity of their projects?

[pskinner]

This is because RoR projects do not do unit testing, they do integration testing with a real DB.

This approach is terrible and causes the poor performance.

There are whole sets of testing "tools" for RoR projects that promote this mechanism of testing - if you're testing an API you need to use an external tool to properly hit that API.

If you're writing unit tests, write unit tests with mocked dependencies.

[ch4s3]

> This is because RoR projects do not do unit testing, they do integration testing with a real DB.

Lots of RoR projects do unit testing without the DB involved, I did it for ~10years and you can write small unit tests until your eyes bleed, but eventually you'll want to test the controllers.

> There are whole sets of testing "tools" for RoR projects that promote this mechanism of testing - if you're testing an API you need to use an external tool to properly hit that API.

You can just use the built in minitest tools and some fixtures to hit the API, and even back it with sqlite so it's fast and light. Most people don't because thing like Rspec, FaktoryBot, and Cuprite are convenient and nice to work with if a bit slow.

>If you're writing unit tests, write unit tests with mocked dependencies.

There were like 3 talks at Rails Conf about this, people do it all the time in Rails land.

[pmontra]

It's hard to really test business logic without hitting the database or other components, no matter the language and the framework. You really have to trust your mocks and sometimes you discover only in production that one of them didn't do what it should do. It happened to me.

The teams I work with tend to write unit tests to demonstrate that a class or module or whatever work, then integration tests to demonstrate that that part of the application works from the frontend code down to the database.

[quesera]

> This is because RoR projects do not do unit testing, they do integration testing with a real DB.

This is not correct.

Rails projects use unit testing, integration testing, and functional testing, as appropriate for the case.

[realusername]

If you write all yours tests without spinning up once a database, I'm not vouching for the effectiveness of said tests...

Especially that we're talking about a web framework, the db is a core part of your stack.

Yes there's going to be strictly unit tests but then at some point there are also queries and models.

[syspec]

Oh the number of times I've run my tests for springboot in which passed, only to fail because of a subtle db issue when hitting the real DB

I'll take hitting real "_test" db anyday

[touisteur]

Might be a place to bypass fsync/fdatasync via LD_PRELOAD using libeatmydata, it will save hours of CI time without switching DAO or DB configuration.