3 ms·
Replace "database mocks" with ANY <X> distributed API service calls in your execution flow and there's still ZERO excuse to NOT to be using SQLite or LocalStack
by calmbonsai 2y ago
Replace "database mocks" with ANY <X> distributed API service calls in your execution flow and there's still ZERO excuse to NOT to be using SQLite or LocalStack mocks in your basic unit and pre-integration testing.
Sure, there's no substitute for optimizing things for a particular query engine and EVERY database engine has SUBSTANTIAL quirks (cough, cough Redshift), but you should be crawling and walking before you try running.
- mrkeen 2y ago> Replace "database mocks" with ANY <X> distributed API service calls in your execution flow and ... so far so good - you're inviting the comparison of "use a real database" to "use a real X", where X could be anything - a bank, or a nuke. > ... there's still ZERO excuse to NOT to be using SQLite or LocalStack mocks in your basic unit and pre-integration testing. And I'm lost. Do we hope for a BankLite and NukeLite implementations to exist?
- calmbonsai 2y ago> so far so good - you're inviting the comparison of "use a real database" to "use a real X", where X could be anything - a bank, or a nuke. I should've used different angle-brackets. "ANY <X distributed API service call>" would've been better. > And I'm lost. Do we hope for a BankLite and NukeLite implementations to exist? No, but it's still worth mocking BankLite and NukeLite with the same call interface and suitable test data, variance, and jitter. The overriding point is nothing will ever replace "the real thing", but that's not what mocks are for and it's even worth mocking 3rd party network services which can be, if not more, "quirky" than SQL query engines.