Because it's so much easier and it still lets me test 95% of my code. And the alternative is not testing at all because there is limited time for testing and setting up a proper database for this is so much more trouble.
The choices are not good test vs bad test. They are test-with-issues vs. no test.
(Obviously you have to do SOME testing with the real DB but this article is talking about unit tests (or related))
How is it so much trouble? Install postgres & any extensions you use on your dev/test boxes, this is a one-off cost that takes minutes.
Have your test bootstrapper run "createdb somethingunique" and then "export APP_DBCONN_STR='somethingunique'". Adding this to your bootstrapper will take minutes.
Comments
No, I will do this.
Because it's so much easier and it still lets me test 95% of my code. And the alternative is not testing at all because there is limited time for testing and setting up a proper database for this is so much more trouble.
The choices are not good test vs bad test. They are test-with-issues vs. no test.
(Obviously you have to do SOME testing with the real DB but this article is talking about unit tests (or related))
How is it so much trouble? Install postgres & any extensions you use on your dev/test boxes, this is a one-off cost that takes minutes.
Have your test bootstrapper run "createdb somethingunique" and then "export APP_DBCONN_STR='somethingunique'". Adding this to your bootstrapper will take minutes.
Ive found running the tests in docker works quite well.