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

231–240 of 268 posts

Re: Database mocks are not worth it

#231

Post by SOLAR_FIELDS »

icedchai wrote: post #202
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…

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

Re: Database mocks are not worth it

#232

Post by avg_dev »

peterldowns wrote: post #153
jph wrote: post #151

Earlier quoted context omitted.

This is so great Peter-- first I've heard of pgtestdb and it's immediately useful for me. How can people donate money to the pgtestdb project? Or hire you for consulting for pgtestdb? I'm joel@joelparkerhenderson.com and would love to help fund your work.

I sincerely appreciate the sentiment and the offer — but pgtestdb is MIT license, actual, for real, not kidding, open source. No payment necessary; please enjoy. (I'm always open to discuss potential contracts or consulting opportunities. If you have one that you think might be a good fit, my email is in my profile here and on github and on my homepage.)

How much of a commission do I make? ;)

Re: Database mocks are not worth it

#233

Post by marcosdumay »

jcgrillo wrote: post #173
marcosdumay wrote: post #163

Earlier quoted context omitted.

There's something very, very wrong in the way we write programs nowadays. Because yeah, the database is you main source of invariants. But there is no good reason for you application environment not to query the invariants from there and test or prove your code around them. We do DRY very badly, and the most vocal proponents are the worst... But I don't think this is a good example of the principle failing.

> no good reason for you application environment not to query the invariants from there and test or prove your code around them As a developer who primarily builds backend web applications in high level languages like golang and java I run the risk of sounding ignorant talking like this but.. I'm led to believe lower level systems and embedded software has a lot more invariant preserving runtime asserts and such in i…

Hum... I'm not sure we are talking about the same thing. Of course system and embedded software won't have invariants stored in a database, the comment isn't about them.

But, there isn't a faster way to fail to an invariant than to prove statically that your code fails it, or to test it before deploying. I don't really understand your criticism.

Re: Database mocks are not worth it

#234

Post by ninetyninenine »

throwawaymaths wrote: post #228
ninetyninenine wrote: post #220

Earlier quoted context omitted.

https://chatgpt.com/share/6773b196-7da8-8001-accd-aefbfe4bac... Rarely used unless necessary is what I meant. The point of the integration test is to avoid mocking and I don’t want to argue a pedantic point with you and I also don’t like your attitude so I’m ending this section of the thread don’t bother replying.

hey man the least you could say us "yeah i wrote something that I didn't mean, my bad" when i called you out. instead you dug in, moved goalposts, and claimed you wrote shit you didn't. it started with literally bad professional advice. junior developers reading these forums need to not have professional habits influenced by the sort of behavior on display by you here. and a ChatGPT transcript? really? just do a simp…

Ok. My bad. I have no problem saying that. But I cut off the convo because I don’t like your attitude. Didn’t like this reply either. Let’s just end it here I have nothing further to say to you and I don’t care about your technical opinions. Good day.

Re: Database mocks are not worth it

#235

Post by withinboredom »

9rx wrote: post #188
withinboredom wrote: post #165

Earlier quoted context omitted.

> Ensuring that an implementation properly satisfies the interface is not within the scope of tests where mocking would be useful. As I mentioned, if you need mocks to test a code path, you are probably "doing it wrong" as there are much better ways to do that. Such as refactoring the code so you can test just that code path. Mocks are a code smell, IMHO. In other words, if you need mocks, then the interface/contract…

> if you need mocks to test a code path, you are probably "doing it wrong" as there are much better ways to do that. Most code paths you want to test are error branches, and creating real error conditions is hard to completely unrealistic (e.g. causing hardware malfunction on each test run). What is the better way in your mind? Mocks can only exist at the integration points, fundamentally. There is a natural interfac…

Heh, when you are working on hardware, you usually build a real test device and yes, actually cause real hardware faults. Mocks or tests will not prepare you for the real thing; as the hardware fault you detect is usually just the surface of the problem. Let's examine a practical example where a disk becomes full. Suddenly, file creation will fail, as will writes, yet, how do you handle that? In isolation, you may mock that condition out so you can test it. You handle the error in isolation, but this is actually quite dangerous. Your application should fail explosively -- don't be like some popular databases that just continue as though nothing happened at all, corrupting its state so it will never start again.

Generally, if you can detect a hardware fault in your code, crash unless you know for certain that you can actually recover from it -- meaning you know what the problem is (can somehow detect the difference between a missing disk or a missing file). 99.9% of the time, you cannot recover from hardware issues with software, so it is pointless to actually test that case. Please, for the love of working software, just crash so the state doesn't get corrupted instead of trying to overengineer a solution.

Re: Database mocks are not worth it

#236

Post by 9rx »

withinboredom wrote: post #235
9rx wrote: post #188

Earlier quoted context omitted.

> if you need mocks to test a code path, you are probably "doing it wrong" as there are much better ways to do that. Most code paths you want to test are error branches, and creating real error conditions is hard to completely unrealistic (e.g. causing hardware malfunction on each test run). What is the better way in your mind? Mocks can only exist at the integration points, fundamentally. There is a natural interfac…

Heh, when you are working on hardware, you usually build a real test device and yes, actually cause real hardware faults. Mocks or tests will not prepare you for the real thing; as the hardware fault you detect is usually just the surface of the problem. Let's examine a practical example where a disk becomes full. Suddenly, file creation will fail, as will writes, yet, how do you handle that? In isolation, you may mo…

> Heh, when you are working on hardware, you usually build a real test device

All software works on hardware. Your web application doesn't need a test device, though. The hardware is already tested. You can treat it as an integration point. But even if you did create a test device for whatever reason, that's a mock! Which you say is to be avoided, and that there are better ways, without sharing what those better ways are...

> Please, for the love of working software, just crash so the state doesn't get corrupted instead of trying to overengineer a solution.

While you're not wrong, you need to test to ensure that it actually crashes. All defined behaviour needs to be tested, and you have defined behaviour here.

Re: Database mocks are not worth it

#237

Post by RaftPeople »

scarface_74 wrote: post #195
tbrownaw wrote: post #185

Earlier quoted context omitted.

Is this about having application logic in multiple places, or having application logic co-located with the data? Does it make a difference if the procedures are database triggers vs being directly called by the application code? Would splitting off some of the logic into a separate service (that does its own database accesses) have the same issues?

Say I have functionality to get customer data. If the sql logic is in code, I can create a new branch and work on it, merge my changes, I can do blue/green deployments. A rollback if you’re using Kubernetes is a simple matter of reverting back to the configuration file containing a reference to the old Docker container etc. How do you roll back a dozen stored procedures quickly? How do you just create a new branch or…

> 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?

Re: Database mocks are not worth it

#238

Post by nrr »

marcosdumay wrote: post #163
jcgrillo wrote: post #102

Earlier quoted context omitted.

The database is often the thing that enforces the most critical application invariants, and is the primary source of errors when those invariants are violated. For example, "tenant IDs are unique" or "updates to the foobars are strictly serializable". The only thing enforcing these invariants in production is the interplay between your database schema and the queries you execute against it. So unless you exercise the…

There's something very, very wrong in the way we write programs nowadays. Because yeah, the database is you main source of invariants. But there is no good reason for you application environment not to query the invariants from there and test or prove your code around them. We do DRY very badly, and the most vocal proponents are the worst... But I don't think this is a good example of the principle failing.

> There's something very, very wrong in the way we write programs nowadays.

I largely agree, but...

> ... the database is you main source of invariants.

I guess my upbringing through strict typing discipline leaves me questioning this in particular. I'm able to encode these things in my types without consulting my database at build time and statically verify that my data are as they should be as they traverse my system with not really any extra ceremony.

Encoding that in the database is nice (and necessary), but in the interest of limiting network round-trips (particularly in our cloud-oriented world), I really would prefer that my app can get its act together first before crossing the machine boundary.

Re: Database mocks are not worth it

#239

Post by scarface_74 »

RaftPeople wrote: post #237
scarface_74 wrote: post #195

Earlier quoted context omitted.

Say I have functionality to get customer data. If the sql logic is in code, I can create a new branch and work on it, merge my changes, I can do blue/green deployments. A rollback if you’re using Kubernetes is a simple matter of reverting back to the configuration file containing a reference to the old Docker container etc. How do you roll back a dozen stored procedures quickly? How do you just create a new branch or…

> 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?

Re: Database mocks are not worth it

#240

Post by nerdponx »

bdangubic wrote: post #190
sickblastoise wrote: post #179

Earlier quoted context omitted.

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.

in 2024/2025 you just might be working with 985 petabyte database which just might have a few issues being “spun up” :)

I am definitely not talking about a full copy of the data here. I more head in mind a small but representative sample, enough to run and exercise units of code with confidence.
Post reply on HN