logoalt Hacker News

asa400today at 1:46 AM3 repliesview on HN

I worked on a project where a dev wanted to mock out the database in tests "for performance, because the database is slow". I almost lost my shit.

Even funnier, this was all hypothetical and yet taken as gospel. We hadn't even written the tests yet, so it was impossible to say whether they were slow or not. Nothing had been measured, no performance budget had been defined, no prototype of the supposedly slow tests had been written to demonstrate the point.

We ended up writing - no joke - less than 100 tests total, almost all of which hit the database, including some full integration tests, and the entire test suite finished in a few seconds.

I'm all for building in a way that respects performance as an engineering value, but we got lost somewhere along the way.


Replies

8notetoday at 3:23 AM

tne knly reason i like having mocks os so you can define all the data objects the whole way through, and see the whole workflow as if you'd written it on paper, without having to open a bunch of files or jump around. just top to bottom every object that is supposed to be there in what order

MBCooktoday at 3:28 AM

I like Mockito, it’s useful, but I’ll never understand mocking out DB stuff.

Why fake it when an integration test tests the real thing.

I’ve seen what you clearly have. Mocked ResultSets, mocked JDBC templates. “When you get SQL, it should be this string. These parameters should be set. Blah blah.”

It’s so much work. And it’s useless. Where does that SQL to check come from? Copy and paste, so it won’t catch a syntax error.

Test data is faked in each result. You can’t test foreign keys.

Just a bad idea. You’re so right. I find it odd some people are so anti-mock. Yeah it gets abused but that’s not the tool’s fault.

But DB calls are not a good spot to mock out.

danparsonsontoday at 1:59 AM

> I almost lost my shit.

Hopefully one day you'll back at that, and realise what an immature attitude that was.

show 2 replies