5 ms·

> set up a real DB, cache, whatever You should shoot for both, actually. If your tests require a live DB to run, they can't be automated (or they can be autom

> set up a real DB, cache, whatever You should shoot for both, actually. If your tests require a live DB to run, they can't be automated (or they can be automated, but failures won't tell you much useful). There's a non-unit-test value of having good code coverage, too: being able to run any function independent of the rest of the app, with arbitrary inputs. When you have a problem that's difficult to reproduce in a controlled environment, it's really useful to be able to run a function that's normally ten function calls deep all by itself over and over again while trying to isolate a problem. If you have to run the entire app to run any of it, that becomes impossible.

bird_monster 6y ago
> You should shoot for both, actually. If your tests require a live DB to run, they can't be automated (or they can be automated, but failures won't tell you much useful). Can you define a scenario in which hitting a real DB wouldn't present useful information while a mocked DB would?
- commandlinefan 6y ago
  Sure, if the DB is down. Or if somebody else deleted the data that your test relied on. It'll happen often enough that you'll stop paying attention to failing "unit" tests.
  - bird_monster 6y ago
    > Or if somebody else deleted the data that your test relied on If you're relying on a shared database you're already not really testing effectively. I don't really think this is a scenario to worry about (meaning, if you're in this scenario, you have bigger things to worry about). > if the DB is down. An interesting suggestion.
- raducu 6y ago
  When you have multiple teams pushing changes and a limited mumber or DB licenses and you want your CI pipeline to run faster, mocks are a very good compromise. DB bugs rarely happen if you don't change any DB stuff after a couple of years in a project, at that point you are really confident in your DAOs and ORM services and you can mock them. You write integration tests for the DAOs and ORM, but you rely on the mocked version in 95% of the test cases.

bird_monster 6y ago

> You should shoot for both, actually. If your tests require a live DB to run, they can't be automated (or they can be automated, but failures won't tell you much useful). Can you define a scenario in which hitting a real DB wouldn't present useful information while a mocked DB would?

commandlinefan 6y ago
Sure, if the DB is down. Or if somebody else deleted the data that your test relied on. It'll happen often enough that you'll stop paying attention to failing "unit" tests.
- bird_monster 6y ago
  > Or if somebody else deleted the data that your test relied on If you're relying on a shared database you're already not really testing effectively. I don't really think this is a scenario to worry about (meaning, if you're in this scenario, you have bigger things to worry about). > if the DB is down. An interesting suggestion.
raducu 6y ago
When you have multiple teams pushing changes and a limited mumber or DB licenses and you want your CI pipeline to run faster, mocks are a very good compromise. DB bugs rarely happen if you don't change any DB stuff after a couple of years in a project, at that point you are really confident in your DAOs and ORM services and you can mock them. You write integration tests for the DAOs and ORM, but you rely on the mocked version in 95% of the test cases.