Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Database mocks are not worth it

shayon.dev

Post reply on HN
Print view View original

141–150 of 268 posts

Re: Database mocks are not worth it

#141

Post by mrkeen »

calmbonsai wrote: post #87

Replace "database mocks" with ANY 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…

> Replace "database mocks" with ANY 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?

Re: Database mocks are not worth it

#142

Post by peterldowns »

jmmv wrote: post #80
btilly wrote: post #3

I've found that replacing the database with in memory SQLite for tests is a sweet spot. Almost as fast as a mock, catches a lot of database issues. And it's really easy to do if you're using something like Django that makes automatically generating database migrations easy. It won't help you with database specific differences. But there should be very few of those if you're using a framework that abstracts away the d…

Came here to say this: I’ve found that using SQLite for tests is a good sweet spot, and maintaining dual DB implementations ensures my business logic remains generic. But there is no replacement for running the tests agains the real database periodically (maybe only in CI for example). I wrote about this and some more in https://jmmv.dev/2023/07/unit-testing-a-web-service.html

Why is maintaining dual DB implementations worth it? Like what is the tangible benefit of "my business logic remains generic"? Do you have to deploy the app in different environments with different DBs?

Re: Database mocks are not worth it

#144

Post by ninetyninenine »

ljm wrote: post #134
ninetyninenine wrote: post #126

Don’t code with mocks period. Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should b…

so what you should do instead is write a load of pure functions and intersperse them with impure functions, and when it comes to testing that, if someone writes a different impure function than the one you wanted, you just fail the test and trigger a post to HN: "don't code with mocks."

You failed to read and/or understand what I wrote. Also how do I fail a test for a new code addition I didn’t even write?

Unit tests dont test impure functions all they do is test pure functions. Impure functions aren’t unit tested period. So when someone writes an impure function I don’t like what happens? Nothing. It wasn’t part of unit tests annyway, understand?

If you’re referring to integration tests well a newly written impure function isn’t part of integration tests anyway so nothing happens in this case either.

I found your last comment about how I’m triggered to write such a comment rude and lacking in even understanding what I wrote. Please try to understand my point before saying something like that… if you can’t please refrain from replying in such a way as it’s against the rules here. Thanks for reading.

Re: Database mocks are not worth it

#145

Post by throwawaymaths »

ninetyninenine wrote: post #126

Don’t code with mocks period. Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should b…

how do you test the imperative shell except with mocks? Suppose you're calling an external API

Re: Database mocks are not worth it

#146

Post by piva00 »

ninetyninenine wrote: post #144
ljm wrote: post #134

Earlier quoted context omitted.

so what you should do instead is write a load of pure functions and intersperse them with impure functions, and when it comes to testing that, if someone writes a different impure function than the one you wanted, you just fail the test and trigger a post to HN: "don't code with mocks."

You failed to read and/or understand what I wrote. Also how do I fail a test for a new code addition I didn’t even write? Unit tests dont test impure functions all they do is test pure functions. Impure functions aren’t unit tested period. So when someone writes an impure function I don’t like what happens? Nothing. It wasn’t part of unit tests annyway, understand? If you’re referring to integration tests well a newl…

How do you write the expected return from an external API in your test setup?

Re: Database mocks are not worth it

#147

Post by paulryanrogers »

ninetyninenine wrote: post #126

Don’t code with mocks period. Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should b…

Please don't write a lot of stored procedures. Changing them in large or sharded DBs is not trivial and tooling to support them is minimal.

Re: Database mocks are not worth it

#148

Post by paulryanrogers »

donjoe wrote: post #92
fcmgr wrote: post #28

Earlier quoted context omitted.

I've had good experience with testcontainers ( https://testcontainers.com/ ) to do that sort of thing.

testcontainers is great. I struggled a bit with testcontainers due to the nature of one container per test which just felt too slow for writing gray/blackbox tests. The startup time for postgres was > 10 seconds. After a bit of experimenting, I am now quite happy with my configuration which allows me to have a snappy, almost instant testing experience. My current setup: - generate a new psql testcontainer _or_ reuse…

You can run Pg against a RAM disk too, if the container isn't effectively already doing that.

And tests can often use a DB transaction to rollback, unless the code under test already uses them.

Re: Database mocks are not worth it

#149

Post by spawarotti »

ninetyninenine wrote: post #126

Don’t code with mocks period. Structure your code such that it has a functional core and imperative shell. All logic is unit testable (functional core). All IO and mutation Is not unit testable (imperative shell). Mocks come from a place where logic is heavily intertwined with IO. It means your code is so coupled that you can’t test logic without touching IO. IO should be a dumb layer as much as possible. It should b…

Great advice. I follow it in my coding efforts and it has never failed me. Great book about this: Unit Testing Principles, Practices, and Patterns, Vladimir Khorikov, 2020

https://www.manning.com/books/unit-testing

Re: Database mocks are not worth it

#150

Post by ljm »

ninetyninenine wrote: post #144
ljm wrote: post #134

Earlier quoted context omitted.

so what you should do instead is write a load of pure functions and intersperse them with impure functions, and when it comes to testing that, if someone writes a different impure function than the one you wanted, you just fail the test and trigger a post to HN: "don't code with mocks."

You failed to read and/or understand what I wrote. Also how do I fail a test for a new code addition I didn’t even write? Unit tests dont test impure functions all they do is test pure functions. Impure functions aren’t unit tested period. So when someone writes an impure function I don’t like what happens? Nothing. It wasn’t part of unit tests annyway, understand? If you’re referring to integration tests well a newl…

[flagged]
Post reply on HN