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

251–260 of 268 posts

Re: Database mocks are not worth it

#251

Post by jasonjmcghee »

t-writescode wrote: post #116
senex wrote: post #4

Does anyone have experience making tests against real databases fast? I resonate with the sentiment of this article, but have struggled to find an alternative that’s fast enough as the test suite grows, isn’t flakey in CI, and is able to share the production schema definition for relevant relations. I’d love to hear more from anyone that’s solved for some of these constraints!

My app: Kotlin, Ktor, Exposed Databases: - Production/Dev: Postgresql - Test suite/CI: SQLite Performance: - ~1000 tests - ~5 seonds For testing anything below the ktor layer, I create and roll back transactions for everything, including db table creation (though I should probably fix that, just bigger fish to fry in this project) For the SQLite / PostgreSQL differences that Exposed doesn't naturally handle, namely j…

I've been bitten by using an in memory database instead of the one production uses. If you're using GitHub Actions it's as easy as using "hoverkraft-tech/compose-action" and providing a docker compose yaml with a postgres image a step.

Re: Database mocks are not worth it

#252

Post by withinboredom »

9rx wrote: post #250
withinboredom wrote: post #241

Earlier quoted context omitted.

> Which you say is to be avoided, and that there are better ways, without sharing what those better ways are... That's because it would better fit in a book than an HN comment, not because I don't want to answer. Basically the gist is to write "obviously correct" code that doesn't need to be tested, along with an architecture that lends itself to being testable without mocks. Most people tend to write an interface an…

> Basically the gist is to write "obviously correct" code that doesn't need to be tested I don't see how that follows. The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. The only 'correctness' a test proves is that the documentation is true. Which is still incredibly useful, as I am sure you are painfully aware if you have ever dealt with legacy forms…

> The purpose of testing is to document the code for the understanding of future developers, not to prove correctness.

Hmm. I've never seen tests with that goal in mind, except for behavioral tests that test the acceptance critera.

> as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation [...] that quickly become out of date

I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen. When I open PRs to open source software, I always include a PR to the docs if it changes anything. At work, updating the docs is part of the default acceptance criteria and is usually the thing we do before writing any code, and goes through a PR process just like the code. But, we service enterprise customers, so we aren't going to be giving them code or tests to understand how to use our product.

> These are all mocks, ultimately.

This is a software field and there are specific words with specific meaning; trying to shoehorn things that aren't those things to generalize a meaning is acceptable when teaching. It isn't acceptable when working on those things. In other words, I would accept this if trying to explain the concept to a junior engineer, but not from a senior engineer to a senior engineer.

> it is all the same at the end of the day.

No, not at all.

Re: Database mocks are not worth it

#253

Post by pdimitar »

sickblastoise wrote: post #179
nerdponx wrote: post #48

Earlier quoted context omitted.

I've had a nice experience using Docker Compose for this, although you might still want a task runner wrapper around it. Podman Compose should work fine as well.

My current setup on a personal project is docker compose with Postgres and pgadmin container. I would never think of mocking a database in 2024/2025, just spin one up. Also keep your lynch pin invariants in the database and not in your code.

> Also keep your lynch pin invariants in the database and not in your code.

I do both. That is how you protect against stressed devs at 2:00 AM trying to insert crap in the production database and how you also make good apps that don't blow up with database exceptions and give you neat validation errors in forms and/or JSON `errors` keys (when it's an API).

Re: Database mocks are not worth it

#254

Post by pdimitar »

hinkley wrote: post #175
pdimitar wrote: post #5

I thought this was common knowledge and that it became even easier after Docker became a thing? Mocks are wishful thinking incarnate most of the time, though here and there they are absolutely needed (like 3rd party APIs without sandbox environments, or quite expensive API, or most of the time: both). Just pick a task runner -- I use just[0] -- and make a task that brings up both Docker and your containers, then run…

Too many people use fakes and call them mocks. Which makes the conversations quite tortured.

Guilty as charged, I mix them both freely; I use fakes but also assert that a function has (not) been called [N times]. The latter is mostly testing implementation but there are rare cases when it's too much work to mock a quality 3rd party library (say, an HTTP client) but you still want to mock parts of it and ensure they get called.

Not sure why mixing up both things makes the conversations tortured though? Can you clarify?

Re: Database mocks are not worth it

#255

Post by zeeZ »

scarface_74 wrote: post #239
RaftPeople wrote: post #237

Earlier quoted context omitted.

> How do you just create a new branch I'm not really following what you are saying. Sprocs are in the same repo as any other code, a branch is a branch, why do you think you can't create a branch that contains sprocs?

Am I then going to deploy the stored procedures to a shared database that other developers are using with their own branch or am I going to have my own database instance?

Are all those developers running different branches of code with automated schema changes on the same database? What if someone adds or removes a field? Stored procedures are not the issue here

Re: Database mocks are not worth it

#256

Post by scarface_74 »

zeeZ wrote: post #255
scarface_74 wrote: post #239

Earlier quoted context omitted.

Am I then going to deploy the stored procedures to a shared database that other developers are using with their own branch or am I going to have my own database instance?

Are all those developers running different branches of code with automated schema changes on the same database? What if someone adds or removes a field? Stored procedures are not the issue here

I’m not referring to schema changes.

If I have logic that returns customer data in code, I can branch the code, make and test my changes locally and other developers can do the same without any conflicts.

Now imagine the next major release requires 50 different sql changes. Would that be easier to push and maintain one git branch or 50 stored procedures?

Again how do you rollback easily and effectively when your release depends on multiple store procedures?

Adding a nullable field shouldn’t be a breaking change, removing a field would be.

Re: Database mocks are not worth it

#257

Post by 9rx »

withinboredom wrote: post #252
9rx wrote: post #250

Earlier quoted context omitted.

> Basically the gist is to write "obviously correct" code that doesn't need to be tested I don't see how that follows. The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. The only 'correctness' a test proves is that the documentation is true. Which is still incredibly useful, as I am sure you are painfully aware if you have ever dealt with legacy forms…

> The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. Hmm. I've never seen tests with that goal in mind, except for behavioral tests that test the acceptance critera. > as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation [...] that quickly become out of date I have, but allowing that to happen is a culture-issu…

> I've never seen tests with that goal in mind

Then you've never seen a test, I guess. That is the only goal they can serve, fundamentally.

> I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen.

Mistakes are guaranteed to happen given enough output/time. No matter how hard you try, you are going to make a mistake at some point. It is the human condition. In the olden days one might use a proofreader to try and catch the mistakes, but with the advent of testing a computer can do the "proofreading" automatically, leaving the human effort to be pointless.

Maybe in the age of LLMs we can go back to writing documentation in "natural" language while still using machines to do the validation work, but then again if you write code you probably would prefer to read code. I know I would! The best language is the one you are already using. Having to read code documentation in English is a horrible user experience.

> This is a software field and there are specific words with specific meaning

Sure, but in this case you won't find any real difference in meaning across the vast array of words we try to use here. The desperate attempts to try and find new words is to broach silly soundbites like "mocks are a code smell", so that one can say "I'm not mocking, I'm flabbergasting!", even though it is the same thing...

Re: Database mocks are not worth it

#258

Post by Two4 »

SOLAR_FIELDS wrote: post #231
icedchai wrote: post #202

Earlier quoted context omitted.

I haven't seen the "stored procs only"-style of DB development since the early 2000's, and I'd never go back to that.

For every “I made this way more efficient/clean with a stored procedure” there’s some incident where the stored procedure was left off, fired too many times, or just caused some problem due to its lack of visibility to the end user in the codebase

Exactly. I only break out SPs when I absolutely need to squeeze as much performance from my data store as possible. I'd rather pay for more horizontal scaling than push my logic across a system boundary where it's difficult to monitor and debug, because bugs in SPs are probably the single costliest class of bug in a prod system.

Re: Database mocks are not worth it

#259

Post by RaftPeople »

scarface_74 wrote: post #256
zeeZ wrote: post #255

Earlier quoted context omitted.

Are all those developers running different branches of code with automated schema changes on the same database? What if someone adds or removes a field? Stored procedures are not the issue here

I’m not referring to schema changes. If I have logic that returns customer data in code, I can branch the code, make and test my changes locally and other developers can do the same without any conflicts. Now imagine the next major release requires 50 different sql changes. Would that be easier to push and maintain one git branch or 50 stored procedures? Again how do you rollback easily and effectively when your rele…

> Now imagine the next major release requires 50 different sql changes. Would that be easier to push and maintain one git branch or 50 stored procedures?

Why aren't those 50 stored procedure changes also in your one branch?

It kind of sounds like you only put some types of code in git, as opposed to everything. Is that correct?

Re: Database mocks are not worth it

#260

Post by t-writescode »

jasonjmcghee wrote: post #251
t-writescode wrote: post #116

Earlier quoted context omitted.

My app: Kotlin, Ktor, Exposed Databases: - Production/Dev: Postgresql - Test suite/CI: SQLite Performance: - ~1000 tests - ~5 seonds For testing anything below the ktor layer, I create and roll back transactions for everything, including db table creation (though I should probably fix that, just bigger fish to fry in this project) For the SQLite / PostgreSQL differences that Exposed doesn't naturally handle, namely j…

I've been bitten by using an in memory database instead of the one production uses. If you're using GitHub Actions it's as easy as using "hoverkraft-tech/compose-action" and providing a docker compose yaml with a postgres image a step.

Oh certainly! The problem is that it's yet another thing to add to the pile of things I need to configure, etc, at this point and it's of lower priority than many, many, many other things - and will easily take as long as so many other of the steps, which are all taking a long time due to learning curve.
Post reply on HN