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

How to test without mocking

amazingcto.com

Post reply on HN
Print view View original

161–170 of 225 posts

Re: How to test without mocking

#161

Post by thiht »

d0mine wrote: post #146
UK-Al05 wrote: post #42

Earlier quoted context omitted.

You have to mock/fake when modules call dependencies. Your way means you only ever have siblings. With an orchestrator pulling results out of one module and pushing it into another.

Code that uses hexagonal architecture/dependency inversion requires less mocks in their tests.

That’s… not true? No matter how you define your dependencies to inject, if you want to mock the dependencies you inject you have to mock them (it’s almost tautological), no matter if you use dependency inversion or not

Maybe you mean "less surface to mock", which is irrelevant if you generate your mocks automatically from the interface

Re: How to test without mocking

#162

Post by kevwil »

"What to do instead of Mocking"

should be more like

"Enhance your use of Mocks with better unit tests and integration tests".

The listed complaints sound more like problems with sloppy/lazy coding practices than actual problems with mocks.

Re: How to test without mocking

#164

Post by erik_seaberg »

mvdtnz wrote: post #153
CuriouslyC wrote: post #110

Earlier quoted context omitted.

I've worked with a lot of pro-mocking engineers, and the time they spent on mocks easily outstripped the time a good build engineer would have spent creating a fast reusable test framework using real databases/dummy services/etc. The mocks won not because they were better or more efficient, but because of lack of deeper engineering skill and cargo culting.

That engineer may have spent a couple of dozen hours on their mock. But the engineers who spent time on a test framework that uses real databases will soak up thousands of developer hours in CI time over the next decade.

Each mock needs to be maintained, sanity checking against the latest behavior of the actual dependency. And CI costs hardware, not developer time if he has anything else to work on.

Re: How to test without mocking

#165

Post by cryptonector »

pasc1878 wrote: post #80
cryptonector wrote: post #50

Earlier quoted context omitted.

> Do you spin up a new postgres DB for each unit test? Yes.

Isn't that rather slow - or do you mean for each run of unit-tests.

In my tests spinning up a PG instance (ultimately just an `initdb` and `createdb` invocation, loading a schema and test data (`psql`), running the test, and tearing down the PG instance is quite fast.

Re: How to test without mocking

#166

Post by mlni »

micvbang wrote: post #160
_hl_ wrote: post #17

Earlier quoted context omitted.

Re. postgres, this is actually something I have always struggled with, so would love to learn how others do it. I’ve only ever worked in very small teams, where we didn’t really have the resources to maintain nice developer experiences and testing infrastructure. Even just maintaining representative testing data to seed a test DB as schemas (rapidly) evolve has been hard. So how do you - operate this? Do you spin up…

I've been on teams where we've done this (very successfully in my opinion!) by creating helper code that automates creating a separate Postgres schema for each test, running all migrations, then running your test function before tearing it all down again. This all runs on CI/CD and developer machines, no credentials to any actual environments. A major benefit of doing separate schemas for each test is that you can ru…

Running all migrations before every tests can take you a surprisingly long way.

Once that gets a bit too slow, running migrations once before every suite and then deleting all data before each test works really well. It's pretty easy to make the deleting dynamic by querying the names of all tables and constructing one statement to clear the data, which avoids referential integrity issues. Surprisingly, `TRUNCATE` is measurably slower than `DELETE FROM`.

Another nice touch is that turning off `fsync` in postgres makes it noticeably faster, while maintaining all transactional semantics.

Re: How to test without mocking

#167

Post by brushfoot »

CuriouslyC wrote: post #110
brushfoot wrote: post #74

Bad article. Some of the advice is good, like decoupling I/O and logic where that makes sense. But the general idea of mocking being an anti-pattern is overreach. This kind of thinking is overly rigid/idealistic: > And with Postgres you can easily copy a test database with a random name from a template for each test. So there is your easy setup. > You need to test reality. Instead of mocking, invest in end-to-end (E2…

I've worked with a lot of pro-mocking engineers, and the time they spent on mocks easily outstripped the time a good build engineer would have spent creating a fast reusable test framework using real databases/dummy services/etc. The mocks won not because they were better or more efficient, but because of lack of deeper engineering skill and cargo culting.

> the time they spent on mocks easily outstripped the time a good build engineer would have spent creating a fast reusable test framework

This goes back to team size and skills. Not all teams have build engineers. And not all mocks are so complicated that they take up that much time.

Again, it depends on the scope and the resources. The article goes too far by calling mocking an anti-pattern. It simply isn't.

Re: How to test without mocking

#168

Post by TacticalCoder »

_hl_ wrote: post #17
solatic wrote: post #12

If you're writing a CRUD app and mocking your database calls instead of just starting an actual Postgres instance before running the tests, you're probably using mocking wrong. If you're writing a custom frontend for GitHub using the GitHub API and don't bother writing a decent set of mocks for how you expect the GitHub API to behave, your app will quickly require either full manual QA at best or become untestable at…

Re. postgres, this is actually something I have always struggled with, so would love to learn how others do it. I’ve only ever worked in very small teams, where we didn’t really have the resources to maintain nice developer experiences and testing infrastructure. Even just maintaining representative testing data to seed a test DB as schemas (rapidly) evolve has been hard. So how do you - operate this? Do you spin up…

> So how do you > ... > - maintain this, eg have good, representative testing data lying around?

This one can be very easy, depending on the kind of data you're working with. Many places shall simply dump a part (or the whole if it's not too big) of the production DB into dev and pre-prod environments.

Now if there are sensitive, non-encrypted, data that even the devs cannot see, than it can get tricky (but then arguably they cannot see the logs in the clear either, etc.).

But yeah: a recent dump of the prod DB is good, representative data.

I've worked at places where pre-prod had a daily dump of the prod DB. Simple.

Re: How to test without mocking

#169

Post by leni536 »

CuriouslyC wrote: post #108

I prefer dependency injection instead of mocking. Not only is injecting a "mock" service better than monkey patch mocks in pretty much all cases, but it's an actually useful architectural feature beyond testing.

That's the only way to mock in some languages/testing frameworks. In C++ monkey patching would be quite difficult, but DI is simple. googlemock works this way.

Re: How to test without mocking

#170

Post by ffsm8 »

drewcoo wrote: post #126
switchbak wrote: post #112

Earlier quoted context omitted.

I would prefer that we all try to use this language consistently: https://www.martinfowler.com/articles/mocksArentStubs.html What you're describing sounds like a fake to me.

Can't tell from the context that's here. It's important to have a contract testing layer in place to make sure your test doubles are still behaving like the real thing, though.

Contract testing is still a thing?

I thought interested mostly fizzled out over the years after the initial hype died down

Post reply on HN