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

The day I started believing in unit tests

mental-reverb.com

Post reply on HN
Print view View original

41–50 of 269 posts

Re: The day I started believing in unit tests

#41

Post by ejb999 »

I hate unit tests, though I am forced to write them to have my CI process not fail (I need 75% coverage or it won't build) - so I have written thousands and thousands of them in the last few years - the problem I have: not a single time that I had a unit test fail that resulted in me finding a bug in my code - all I ever find are bugs in my unit test code - so pretty much seems like a waste of time to me.

Either I am writing really good code so there are no bugs, or I am really bad a writing unit testing code to find those bugs.

Re: The day I started believing in unit tests

#42

Post by bobthepanda »

domano wrote: post #24
bobthepanda wrote: post #11

Earlier quoted context omitted.

The point of unit tests is not to CYA during refactors, but to confirm that the implementation is consistent between small changes without weird side effects. A coworker once thought unit tests were dumb, and ended up writing code that repeated the call to an application 10x for the same info. This didn’t result in a changed UI because it was a read, but it’s not good to just suddenly 10x your reads for no good reaso…

Using mockserver etc. you can cover for these things in component-test cases even more easily through your whole application while being more flexible with bigger code changes than unit tests allow.

A lot of places on the internet treat component testing and unit testing as synonyms. I’ve never heard of the former and it basically sounds like the unit tests as we write.

Re: The day I started believing in unit tests

#43

Post by berkes »

atticora wrote: post #38
gbacon wrote: post #30

Earlier quoted context omitted.

From Working Effectively With Legacy Code by Feathers, p. 14[0]: Unit tests run fast. If they don’t run fast, they aren’t unit tests. Other kinds of tests often masquerade as unit tests. A test is not a unit test if: 1. It talks to a database. 2. It communicates across a network. 3. It touches the file system. 4. You have to do special things to your environment (such as editing configuration files) to run it. Tests…

My "unit tests" do hit the database and file system, and I have found and fixed many many problems during testing by doing so. I have found many other problems with those calls in production when I didn't do so. Yes, they make testing a lot slower. Our main app takes around 40 minutes to build which isn't good. I'd like it to be faster. But writing a bunch of separate integration tests to cover those functions would…

> My "unit tests" do hit the database and file system, and I have found and fixed many many problems during testing by doing so. I have found many other problems with those calls in production when I didn't do so.

No-one said that integration tests can't also be very valuable.

From the little context I get that you write integration tests, and that is fine. They are useful, valuable! But they are not unit-tests.

edit: on re-reading, I get the feeling that for you "integration tests" are a synonym for "end to end tests". But -at least in most literature- end-to-end tests are a kind of integration-test. But not all integration tests are end-to-end tests. In my software, I'll often have integration tests that swap out some adapter (e.g. the postgres-users-repository, for the memory-users-repository, or fake-users-repository. Or the test-payment for the stripe-payment) but that still test a lot of stuff stacked on top of each-other. Integration tests, just not integration tests that test the entire integration.

Re: The day I started believing in unit tests

#44

Post by corey »

davnicwil wrote: post #28

I think about unit tests being useful for getting more confidence that some deterministic, pure (mathematically speaking) and stateless piece of code that's data in data out actually works, particularly when you change it. If any of those conditions doesn't hold the cost/benefit certainly and even sometimes the absolute utility goes way down. If I have to mock anything, in particular, or more generally care at all ab…

I agree that mocks are brittle and nearly useless.

If you follow SOLID principles to the extreme, you'll find that your code is separated into logic code that is pure and easy to unit test, and IO code that is very simple and can be tested by a relatively few number of integration tests.

Re: The day I started believing in unit tests

#45

Post by jve »

toenail wrote: post #13
EZ-E wrote: post #7

I barely ever have unit tests flagging real issues. It's always a chore to update them. Feature/end to end tests though... Plenty of real issue flagged.

> I barely ever have unit tests flagging real issues That sounds like you work alone and haven't worked for a long time on a code base with unit tests. Or the unit tests are bad.

> It's always a chore to update them

Or he is actually not realizing unit tests bring to attention code that is impacted by the change... Or his tests just do for dynamically typed language whatever static tying does on compilation :)

Re: The day I started believing in unit tests

#46

Post by bobthepanda »

bedobi wrote: post #31
bobthepanda wrote: post #11

Earlier quoted context omitted.

The point of unit tests is not to CYA during refactors, but to confirm that the implementation is consistent between small changes without weird side effects. A coworker once thought unit tests were dumb, and ended up writing code that repeated the call to an application 10x for the same info. This didn’t result in a changed UI because it was a read, but it’s not good to just suddenly 10x your reads for no good reaso…

> confirm that the implementation is consistent between small changes without weird side effects not sure what this is referring to, but I'll give an example say you have a requirement that says if you call POST /user with a non-existing user, a user should be created and you should get a 2xx response with some basic details back you could test this by actually hitting the endpoint with randomly generated user data k…

I literally gave examples in my example.

As a general example, a unit test is great for things like:

Your ExampleFactory calls your ExampleSerivce exactly once, not more, not less, so you can check that side effects don’t result in unnecessary extra calls in more load.

This is particularly relevant in a language like Java; modern Java style is functional, but the old style relied heavily on side effects, and they’re still possible to write unintentionally.

Re: The day I started believing in unit tests

#47

Post by lokar »

berkes wrote: post #43
atticora wrote: post #38

Earlier quoted context omitted.

My "unit tests" do hit the database and file system, and I have found and fixed many many problems during testing by doing so. I have found many other problems with those calls in production when I didn't do so. Yes, they make testing a lot slower. Our main app takes around 40 minutes to build which isn't good. I'd like it to be faster. But writing a bunch of separate integration tests to cover those functions would…

> My "unit tests" do hit the database and file system, and I have found and fixed many many problems during testing by doing so. I have found many other problems with those calls in production when I didn't do so. No-one said that integration tests can't also be very valuable. From the little context I get that you write integration tests, and that is fine. They are useful, valuable! But they are not unit-tests. edit…

And integration tests can also be fast

Re: The day I started believing in unit tests

#48

Post by cfiggers »

corndoge wrote: post #34

I started believing in unit tests the day I finished my patch, ran the program and watched it work perfectly. I then grudgingly wrote a test, ran it and immediately observed it fail. One of the test inputs was some garbage input and that exposed a poorly written error handling path. Humbling! I still hate writing them and it grates on my aesthetic sense to structure code with consideration to making it testable, but…

> if we want to call ourselves engineers we need to hold ourselves to engineering standards. Bridge builders do not get to skip tests.

Bravo. We need more of this mindset in the world, and also more collective will to encourage it in one another.

YOU are the kind of engineer I want writing the code that goes in my Dad's pacemaker or the cruise control in my wife's car.

Re: The day I started believing in unit tests

#49

Post by fesc »

atticora wrote: post #38
gbacon wrote: post #30

Earlier quoted context omitted.

From Working Effectively With Legacy Code by Feathers, p. 14[0]: Unit tests run fast. If they don’t run fast, they aren’t unit tests. Other kinds of tests often masquerade as unit tests. A test is not a unit test if: 1. It talks to a database. 2. It communicates across a network. 3. It touches the file system. 4. You have to do special things to your environment (such as editing configuration files) to run it. Tests…

My "unit tests" do hit the database and file system, and I have found and fixed many many problems during testing by doing so. I have found many other problems with those calls in production when I didn't do so. Yes, they make testing a lot slower. Our main app takes around 40 minutes to build which isn't good. I'd like it to be faster. But writing a bunch of separate integration tests to cover those functions would…

What would "integration tests" (that you don't write) look then in your opinion?

I ask because in my team we also a long time made the destinction between unit/integration based on a stupid technicality in the framework we are using.

We stopped doing that and now we mostly write integration tests (which in reality we did for a long time).

Of course this all arguing over definitions and kind of stupid but I do agree with the definition of the parent commenter.

Re: The day I started believing in unit tests

#50

Post by Steltek »

baz00 wrote: post #9

I believe in them. But unit tests are useless around useless humans. And there’s lots of those. A fine example is that time I wrote a test suite for a domain specific language parser. Someone wanted to break the language so they deleted the tests. New stuff was added without tests. They confidently broke everything historically and looking forward. Then blamed it on me because it was my test suite that didn’t catch i…

Whenever I read, "when my code breaks the tests, I delete the tests", this is what I picture in my head.

Their code changed behavior and good unit tests catch change in behavior. Someone somewhere is probably depending on that behavior.

Post reply on HN