21–29 of 29 posts
Actually I've just released something for that. It's a way of running from your local environment extremely quickly (spoiler alert we use non-local servers).
You can check it out at https://brisktest.com/ we have a demo running Jest at the moment but I'm recording a rails demo right now.
Earlier quoted context omitted.
In the grand scheme of things it doesn't matter that much. Once you starts parallelizing, CI time is: setup_time + (test_run_time / workers), so assuming money isn't a problem you can add more workers as you keep adding more tests. What really matter is how fast you can setup your test workers and how slow individual tests are.
I think your last statement captures something that not often emphasized, which is that startup time of workers and app are variable costs which scale with the amount of parallelization and so if you have a very large test suite there may be a limit where setup eats up so much time that parallelizing more is going to be pretty "wasteful" and I guess that's where the money comes in. Secondly if you're actually trying…
Buildkite doesn't directly help with it, but since you bring your own hardware and that it's highly customizable, it does allow you to invest in improving setup time quite dramatically. It's a great product.
Earlier quoted context omitted.
How can you tell that if you don't know the complexity of their projects?
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.
Earlier quoted context omitted.
How can you tell that if you don't know the complexity of their projects?
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.
I'll take hitting real "_test" db anyday
"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. " Actually I've just released something for that. It's a way of running from your local environment extremely quickly (spoiler alert we use non-local servers). You can check it out at https://brisktest.com/ we have a demo running Jest at the moment but I'm recording a rails d…