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

Don't Use Mocks

joeblu.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Don't Use Mocks

#61

Post by ehutch79 »

krubar wrote: post #33
wickoff wrote: post #4

Earlier quoted context omitted.

If your database isn't involved in your business logic then you're probably significantly underutilizing capabilities of modern databases.

How is that so?

For SQL databases at least:

You can your db sum columns faster than you can grab the data, parse it, and compute the sum. In query calculations to avoid race conditions from doing the math on separate servers, etc.

Triggers and procedures are a thing.

The nosql/kv store hype missed a lot of stuff relational/sql dbs did well. Mostly because at the time they declared sql was too hard, or just never studied anything.

Re: Don't Use Mocks

#62

Post by ehutch79 »

joeblubaugh wrote: post #44
sumedh wrote: post #32

Earlier quoted context omitted.

> business level code with side-effecting code (like calling APIs or DBs). Sometimes the business logic is in DBs with stored procs.

That’s a whole other can of worms! The difficulty of versioning stored procedures is such a detriment to effectively using all that power.

They should be part of your migrations? and your migration should be versioned?

Re: Don't Use Mocks

#64

Post by Maxion »

sethammons wrote: post #37

My goto simple example here for dumb mocks is a multiply function. You are doing it wrong if you have: MyMock.Mocks(myMultiplyFunc).WithArgs(3, 4).ToCall(myAddFunc).Times(3).WithArg(4).ExpectsResponse(12). Your multiply func being backed by add is not important to the unit test for multiplying. If you change it to have special handling for bitshifting in different cases, your mock tests break. Badly. Mocks add coupli…

> Make a dependency interface "SendEmail(userID int, content []byte) (SendGridResp, error)". Inject that.

Am I an idiot for thinking of this as a Mock? This is how I mock things anyway

Re: Don't Use Mocks

#65

Post by drewcoo »

This misses the point. It briefly touches the point, then . . . facepalm.

If you test behaviors, either with mocks or with fakes, you're not tied to implementation details. I can only assume this stops things from being what the author calls "brittle."

If your test doesn't test a behavior, then you are testing (at best!) an implementation detail. So maybe remove the test. If you're looking at code coverage, you should be able to get complete coverage testing at this level without testing implementation details or . . . you've found dead code - remove that, too! Tell your boss what a wise greybeard you must be because your commits remove bad things.

Whether or not you test behaviors, there are more running processes with fakes. There's a lot more happening that can fail. I'd call that brittle. Fakes have their place, but the reason to use them is because they're much less brittle (prone to fail) than full-stack end-to-end tests are. You can spin up your new microservice with all of its shared-nothing data stores, surround it with fakes, and completely exercise all of its reachable code - code like those error paths that are hard to hit otherwise. Better to test as much as you can in isolation first - faster feedback, easier to diagnose failures, and less test maintenance than a deployed environment.

Re: Don't Use Mocks

#66

Post by sethammons »

Maxion wrote: post #64
sethammons wrote: post #37

My goto simple example here for dumb mocks is a multiply function. You are doing it wrong if you have: MyMock.Mocks(myMultiplyFunc).WithArgs(3, 4).ToCall(myAddFunc).Times(3).WithArg(4).ExpectsResponse(12). Your multiply func being backed by add is not important to the unit test for multiplying. If you change it to have special handling for bitshifting in different cases, your mock tests break. Badly. Mocks add coupli…

> Make a dependency interface "SendEmail(userID int, content []byte) (SendGridResp, error)". Inject that. Am I an idiot for thinking of this as a Mock? This is how I mock things anyway

It is maybe a semantics issue. See https://martinfowler.com/articles/mocksArentStubs.html.

Traditionally, a mock asserts against internal behavior while a fake does not.

Re: Don't Use Mocks

#67

Post by TillE »

brianmcc wrote: post #12

There are entirely separate communities IMO when it comes to automated tests. There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing. And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to th…

Tests are often extremely helpful, but I think the goal of 100% coverage has done much more harm than good, and leads to the kind of trivial tests you describe.

TDD usually works well, and helps guide you towards designing a usable, testable API. Don't test getters and setters, test the actual logic you care about.

Re: Don't Use Mocks

#68

Post by cultofthecow »

readthenotes1 wrote: post #56
cultofthecow wrote: post #18

Such a bad take IMHO. Sorry. 1. You still need to update the fake object once you gonna add a new behaviour. 2. Fake object has a tendency to become logic heavy. Someone will add a stupid-not-needed-map to test some shit you don't need to test in this unit\layer. 3. You only need to mock the behaviour you depend on. If you've added new Method and you need to mock it despite the fact you're not using it in the code yo…

I once worked with a mockist who mocked out hashtable. It didn't end well when we had to debug his code. I once knew a mockist who mocked out all the external code's behavior, but didn't add tests to ensure that the external code behaved as they expected. That didn't end well either. Just don't use mocks, unless they're the simplest thing that could work (usually not).

what does it mean “mocked out hashtable”?

Whole hashtable? Or what?

You mock interface/api of “something” you depend on to model the behavior you might deal with within the part of code you test.

thats it. nothing else.

during unit test phase I want to make sure that this exact code works as a state machine given all the possible inputs/outputs and that it handles any possible situation any dependency can cause.

If you need to debug code BECAUSE of the tests and not WITH the tests then something is wrong with the architecture or approach.

tldr. mock dependencies. model behavior of the dependencies. make sure you can debug the code with the help of your unit tests on the very layer you’re working with at the moment.

Re: Don't Use Mocks

#69

Post by willio58 »

jmartrican wrote: post #22

This topic of testing techniques is fraught with extreme points of view. The way I see it is that unit testing, int-testing, mocks, stubs, and now fakes are all techniques and tools in your toolbox. Do not throw out a tool in favor of always using one of them. Instead, I implore devs, to try and use the *best tool for the job at the time for a specific test. Understanding that "best" is based on opinions and current…

Totally agree. In the past year, I've started getting my org into writing tests, and it's pretty hard to find the "right" way of doing things. Everyone is so opinionated, which is fine but they're all opinionated in different directions.

I've found some solace in finding one person that's really experienced in writing tests for my specific platform, and kind of following their blog as a "bible" of sorts. cough https://kentcdodds.com/blog cough

Re: Don't Use Mocks

#70

Post by cultofthecow »

NBJack wrote: post #55
cultofthecow wrote: post #18

Such a bad take IMHO. Sorry. 1. You still need to update the fake object once you gonna add a new behaviour. 2. Fake object has a tendency to become logic heavy. Someone will add a stupid-not-needed-map to test some shit you don't need to test in this unit\layer. 3. You only need to mock the behaviour you depend on. If you've added new Method and you need to mock it despite the fact you're not using it in the code yo…

Mocks force you to be aware of how your method/function under testing operates at a low level. At that point your test is now tightly coupled to a specific implementation. YMMV, but I can safely say from working on large codebases across several companies I've seen this get painful at scale when things change, whether it's a simple refactoring or an optimization pass. Mocks also tend to be much, much more complicated…

how come mocks make you tightly coupled with implementation?

Use and depend on abstractions maybe?

Post reply on HN