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

121–130 of 178 posts

Re: Stop mocking your system

#121

Post by oriolid »

rad_gruchalski wrote: post #16

I agree with the premise of this post. Instead of mocking, design your components in such a way that they are easy to spin up in tests. Or use containerized versions of services. I started disliking the idea of mocks a few years ago. I was writing a system based on the Play framework. Play framework used to (still does?) come with a dedicated integration testing environment. The problem with it was that the setup of…

The problem is not spinning up services, but setting them up to fail in the way your test case needs them to fail. Testing the happy path isn't that useful, just trying out the system should show that they work. Edge cases and error conditions are what needs testing.

Re: Stop mocking your system

#122

Post by oriolid »

AtlasBarfed wrote: post #99
alecbz wrote: post #48

Earlier quoted context omitted.

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 un…

A good exercise is to get 100% coverage for anything that uses ByteArrayInput/OutputStreams. The language enforces handling IOException for a bunch of methods that could throw one for a generic stream but never for a ByteArrayStream.

Re: Stop mocking your system

#123

Post by lugged »

fragbait65 wrote: post #117
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 it's a failure to ever believe that unit tests provide any correctness proof. The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code. I think experience is needed to know when to unit test. Some code might not need any tests at all while other code might need quite a lot of tests. My personal experience, for the code bases I work on, shows that…

> The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code.

People love to ignore how fucking awful code is when you aren't forced to write unit tests.

Unit tests before you write code help you code, they provide a tight feedback loop, they force or at least encourage modularity to be testable.

Adding tests to my code after writing it forces me to challenge assumptions and frequently requires refactoring to improve the code along with testability. It also documents my intent better than comments can and often gives consumers valuable example usage code.

Yes it's a trade off and sometimes overkill but that's why 100% coverage is a stupid goal. You should always evaluate RoI of the tests you're writing.

Integration and end to end testing is much the same, they're simply different grain sizes, we need all of them to be effective.

The biggest mistake that happens with testing is assuming it's all about correctness, doing so is why we have 100% coverage people around, they're equating 100% coverage with 100% correct which is just a wrong conclusion.

Re: Stop mocking your system

#124

Post by spullara »

I have seen some very very bad tests written with mocks. The tests were written in such a way that you couldn't change the underlying implementation without completely rewriting them because they were testing underlying implementation behavior down to ensuring that certain methods were called on certain libraries used by the underlying implementation code. Please don't do this. It is a nightmare to improve the implementation.

Re: Stop mocking your system

#126

Post by dnrjdjxixi »

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…

Unit tests are for TDD. They make it difficult to write untestable code. They rarely catch bugs, they are your spec.

Re: Stop mocking your system

#127

Post by kazinator »

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.

Test the heck out of the external, documented contracts. Then the test suite helps you refactor: reshuffle the internals while maintaining the contracts.

Re: Stop mocking your system

#128

Post by lowbloodsugar »

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.

If unit tests are hindering your refactoring then you aren't writing SOLID code. The only time I find myself, e.g. splitting a class in two, and then having to deal with its shitty tests, are when I'm dealing with legacy classes that did five things at once. Oh, and their tests were just "did it crash?" tests, i.e. call a method but only check the happy path.

If you have reached the point where you feel tests hinder refactoring then you have two paths: a/ learn to write smaller, SOLID classes, or b/ meh unit tests are stoopid.

Re: Stop mocking your system

#129

Post by Aeolun »

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.

Lolwut? Unit tests are one of the few things that give me confidence in my refactored code.

Integration tests are nice, but they don’t give me enough confidence about the specific part of the system I’m altering.

Re: Stop mocking your system

#130

Post by Aeolun »

hamandcheese wrote: post #83
arkh wrote: post #73

Earlier quoted context omitted.

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.

If a test is in my way, I delete it.

Must be fun to work with you.
Post reply on HN