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

131–140 of 178 posts

Re: Stop mocking your system

#131

Post by ncrmro »

lugged wrote: post #123
fragbait65 wrote: post #117

Earlier quoted context omitted.

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

Quite iteration/feedback loop is a big plus for sure

Re: Stop mocking your system

#132

Post by bluGill »

Aeolun wrote: post #129
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.

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.

Until you realize that your api is wrong. So long as you got your api right up front unit tests make it easy to refactor. As soon as the api needs nontrivial changes you are sunk.

Re: Stop mocking your system

#133

Post by Aeolun »

yepthatsreality wrote: post #21
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…

I personally use mocks or stubs only in unit tests. Everything else should be live test or recorded network responses but always run through live code. Unless the service really depends on it, I do not reccommend setting up local swarm of services. This breaks down if you shift to distributed micro services and has little benefit for a single service app (ex crud + database app, no reason to test the database in the…

Persisting data for your test paths is much easier with a database though.

Re: Stop mocking your system

#134

Post by bluGill »

amw-zero wrote: post #125
booi wrote: post #119

Earlier quoted context omitted.

The point of what being there? There's nothing there.

What is the point of the initial test if you’re just going to delete it.

Depends on why it failed. Many times it fails because a requirement changed, so delete the no longer valid test

Re: Stop mocking your system

#135

Post by Aeolun »

bhawks wrote: post #61

Mocks make me sad. They are so often misused by people with the best of intentions. I have seen so many tests that literally only assert the mock expectations and say nothing about the code under test. I have watched upgrades and refactors take 5x longer because someone steps on a landmine of overmocking. It is so common to see people mocking dumb data objects, containers, and pure functions - creating Frankenstein w…

If you correctly use interfaces for your contracts, how can your mocks ever be out of date?

Your compilation step would fail.

Re: Stop mocking your system

#136

Post by fragbait65 »

lugged wrote: post #123
fragbait65 wrote: post #117

Earlier quoted context omitted.

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

I used to do TDD, I found that it didn't work that well for me.

I still think that the code base you work on dictates how you should be testing. It also dictates which testing strategy I use.

I test for different things when writing C than I do when I write Python for example. My testing strategy is different if I write a networked C application compared to if I write a Ruby on Rails app.

Also the tools I have available to me when writing the code dictates how I will test, which is tied into which language I write in.

And I really disagree that code has to be awful because you are not forced to write unit tests. I work with a team of 4 other experienced and responsible programmers. We actually don't have to have rules that force us to do anything. We are responsible enough and experienced enough to know what to do and when to do it.

40 - 50 % of our code base doesn't have a single unit test, because it doesn't have to have any. Are we infallible, no. Does mistakes happen? Yes. Do we sometimes go back and add unit tests to code that we thought didn't need any. Yes, it happens.

Would unit tests have saved us sometimes? Yes. If it would have, then we are responsible and go back and add that test.

Re: Stop mocking your system

#137

Post by grayclhn »

bluGill wrote: post #132
Aeolun wrote: post #129

Earlier quoted context omitted.

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.

Until you realize that your api is wrong. So long as you got your api right up front unit tests make it easy to refactor. As soon as the api needs nontrivial changes you are sunk.

Cool, but that’s not “refactoring.”

Re: Stop mocking your system

#138

Post by Aeolun »

bluGill wrote: post #132
Aeolun wrote: post #129

Earlier quoted context omitted.

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.

Until you realize that your api is wrong. So long as you got your api right up front unit tests make it easy to refactor. As soon as the api needs nontrivial changes you are sunk.

True, to some extend. But the number of times I need to do that is low compared to the number of times I need to do a much milder refactor.

Re: Stop mocking your system

#139

Post by bluGill »

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…

1 and 3 is the dogma, but mostly I find it false. My integration tests are fast because they deal with small data sets. A few dozen function calls adds a few ms, who cares.

I find it easy to find where an integration tests broke because I back out my last change.

Re: Stop mocking your system

#140

Post by mmastrac »

Sorry, this is bad advice. If you test against 3rd-party systems, eventually your system will grow to the point where you are spending a good deal of time dealing with your 3rd-party's random breakage (downtime or flakiness rather than API changes).

I learned this lesson twice the hard way: once with social media networks like Twitter and Facebook, and the other with Google Drive.

Post reply on HN