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

Stop mocking your system

blog.bitgloss.ro

Post reply on HN
Print view View original

91–100 of 178 posts

Re: Stop mocking your system

#91

Post by [deleted] »

detaro wrote: post #87
tuxie_ wrote: post #72

Earlier quoted context omitted.

I'm sorry, I did not intend to offend anyone obviously. Needless to say, this is just my opinion condensed in a sentence (therefore lacking a lot of context, which I should have provided). I was not aiming to define what a unit test is, more like when it stops being a unit test (which I thought it would be an easier agreement to reach than a definition of what is, but I guess I underestimated the task). My point was…

So components that talk to the outside can't be unit-tested at all?

[deleted]

Re: Stop mocking your system

#92

Post by tuxie_ »

detaro wrote: post #90
tuxie_ wrote: post #89

Earlier quoted context omitted.

Hi detaro. Good question. If all my module does is make an api call, and I mock the API, what am I testing? I would rather leave that out of the unit tests because the added value is, in my opinion, close to none if you are relying on mocked data. Now, if the module does more than just call the API then I would argue that it's breaking the single responsibility principle and would prefer to split it into a module tha…

Ok, then go one level in: If a component uses the "only makes an API call module", how do I unit test it? I can't let it use the module to make the API call (because the API might not be available in testing/that's an integration test/...), and I can't mock it, because using a mock would make it a not-unit test? I guess this gets at the line between mocks and stubs, but I never found that all that convincing.

Yes, you just don't unit test it, because if you mock out the only dependency it has you are left with nothing. So you are not unit testing anything anyway. You know what I mean? That code can (and should) be tested, through an integration test.

Re: Stop mocking your system

#93

Post by spaetzleesser »

arkh wrote: post #73
alecbz wrote: post #51

True "unit" tests are: * faster to run * give you less confidence in the correctness of the system (per time spent writing them) * when they fail, give you more information about where the failure is The more integration-y/e2e-y a test is, the more it strays from this: slower to run, more confidence that the system is correct, less info about where the failures are. I think people have learned to undervalue the prope…

Don't forget a very important thing: unit test are hindering any refactoring. People will resist it because it means they have to rewrite their tests. And if you don't have enough e2e tests, you have nothing to check your refactoring efforts have not broken anything.

Very true. A lot of unit tests, especially the ones with mocks tend to test a lot of internal behavior. So when you refactor your system, you often have to rewrite unit tests although the system actually performs correctly.

Re: Stop mocking your system

#94

Post by 8note »

tuxie_ wrote: post #2

Mocking has a place, which is not unit testing. If you find yourself mocking a dependency in a unit test you are not unit testing any more. Those points of contact with 3rd parties should be clearly defined and encapsulated at the perimeter of your system. Mock at that level. Not when testing business logic.

something else calls that encapsulation.

So you can also mock your encapsulation in the next layer, than that one in the next, etc

Re: Stop mocking your system

#96

Post by rualca »

alecbz wrote: post #51

True "unit" tests are: * faster to run * give you less confidence in the correctness of the system (per time spent writing them) * when they fail, give you more information about where the failure is The more integration-y/e2e-y a test is, the more it strays from this: slower to run, more confidence that the system is correct, less info about where the failures are. I think people have learned to undervalue the prope…

> I think people have learned to undervalue the properties of integration tests and overvalue the properties of unit tests. Is it nice to know exactly what's broken based on the test failure? Sure. Is it _as_ nice as having confidence that the whole system is working? Probably not, in a lot of cases.

This comment alone demonstrates a collosal misunderstanding regarding unit tests.

Unit tests are not used to verify if the system is working. They were never used for that. At all. Unit tests only specify invariants which are a necessary but insufficient to verify that the system works as expected. These invariants are used to verify that specific realizations of your input and state will lead your implementation to produce specific results, no matter which code you change. If you expect function foo to return true if you pass it a positive integer, you want to know if a code change suddenly leads it to return false or throw an exception. That's what unit tests are for.

If unit tests worked anything remotely similar to the way you misrepresented them, we would not need integration or end-to-end tests at all, would we?

Re: Stop mocking your system

#97

Post by zestyping »

gravypod wrote: post #7

> But dude, I don’t want to use a real database (or AWS endpoint or rocket launcher) in my tests. Debatable, but fair enough. Is this debatable? Hermetic tests give you a lot of things for free and I don't really see a reason why you would default to making all of your tests hermetic. The real thing that this article is touching on is that your tests should test all of the code you write but not code others have writ…

You don't need to test that Postgres knows how to parse a query. But you do need to test that the query you wrote means what you think it means to Postgres. The only way to know that for sure is to hand the query to Postgres.

Maybe you don't need to test that the ORM is correct. But you do need to test that you are using the ORM in the way that the ORM's designer expected, which is often non-trivial. And so on.

Re: Stop mocking your system

#98

Post by BirdieNZ »

lilyball wrote: post #77

Why stop there? Why not delete your test methods too and just test in production? Mocks are just test code, same as your test functions. And they’re necessary fur unit tests. If the thing you’re testing talks to another component without a mock, it’s now an integration test instead of a unit test. Unit tests test the API surface of a component. They’re useful for ensuring a component adhere to its documented API cont…

> Why not delete your test methods too and just test in production?

This, but unironically.

Depending on your use case, any local tests, whether mocked or using a swarm of local containers attempting to represent production may be a far stretch from production reality. Put everything behind feature flags and test your contracts, then release to production regularly and test against live data and live services.

Re: Stop mocking your system

#99

Post by AtlasBarfed »

alecbz wrote: post #48
jnaddef wrote: post #24

The author seems to believe people either mock everything or don't mock anything. Obviously using mocks for all your tests is a very bad idea, but that's not how things are done generally. Unit tests allow you to validate a unit's behavior very quickly. If your unit test takes more than 1 second to run it is probably a bad unit test (some would argue 1/100 second max so your whole unit test suite can complete in a fe…

I've certainly seen people who mock almost everything to test units at the smallest scale possible because they think that's what they're supposed to. E.g., I once saw someone test a factory method like: def make_thing(a, b, c): return thing(a, b, c) with a unit test where they mocked `thing`, and ensured that calling `make_thing(a, b, c)` ended up calling `thing(a, b, c)`. They write just a shit ton of tests like th…

harkens back to the early obsession with "100% code coverage" and java robots were coding tests on bean getters/accessors.

100% code coverage was a bad breadth-first metric when unit tests should be depth based on many variant inputs. Also, "100% code coverage" ignores the principle that80% of execution is in 20% of the code/loops, so that stuff should get more attention than worrying about every single line being unit tested.

Well, unless you were in some fantastical organization of unicorn programmers that had an infinite testing budget and schedule...

Post reply on HN