Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

GitHub uses minitest, but same situation.

I don't exactly agree that it's a design problem. I think there is a lot of value in testing at a high level (controller tests) and having them touch the full stack (down to the DB). Gives a lot of confidence that the code will work in production. Throwing money at it (running the tests in parallel) pretty much solves it.

I have seen FactoryBot use get out of control (creating 8x as many records as you'd expect). That's a really easy way to slow down a test suite :). One way I've found to fix that is by adding tests for the factories, and asserting they are only creating what you want them to.

On model tests, another thing GitHub did well was encourage using `.build` when possible to avoid writing the the DB.




> I think there is a lot of value in testing at a high level (controller tests) and having them touch the full stack (down to the DB).

There is a lot of wasted work. Each (similar) test would insert and then delete the same rows, but make a little tweak.

Other languages and frameworks (java, python or golang) don't need to test the db and run super quick. Most db systems do not actually need to be tested. e2e testing can be done manually via curl or qa.

> Throwing money at it (running the tests in parallel) pretty much solves it.

Tests still are slow locally.

> One way I've found to fix that is by adding tests for the factories

That is interesting. I had a meta-test that would limit the number of sql queries a test could trigger.


> Most db systems do not actually need to be tested

Is this like when people say you don't need to test functional code?


I've never heard that. I mean, you can trust postgres to correctly execute the sql you give it, as you can trust active record to work as documented.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: