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

61–70 of 269 posts

Re: The day I started believing in unit tests

#61

Post by jkubicek »

HideousKojima wrote: post #19
the_sleaze9 wrote: post #5

Good story. I for one do not believe in Unit Tests and try to get LLM tooling to write them for me as much as possible. Integration Tests however, (which I would argue is what this story is actually praising) are _critical components of professional software. Cypress has been my constant companion and better half these last few years.

Unit tests are useful for: 1) Cases where you have some sort of predefined specification that your code needs to conform to 2) Weird edge cases 3) Preventing reintroducing known bugs In actual practice, about 99% of unit tests I see amount to "verifying that our code does what our code does" and are a useless waste of time and effort.

> In actual practice, about 99% of unit tests I see amount to "verifying that our code does what our code does" and are a useless waste of time and effort.

If you rephrase this as, "verifying that our code does what it did yesterday" these types of tests are useful. When I'm trying to add tests to previously untested code, this is usually how I start.

    1. Method outputs a big blob of JSON
    2. Write test to ensure that the output blob is always the same
    3. As you make changes, refine the test to be more focused and actionable

Re: The day I started believing in unit tests

#62

Post by Verdex »

bobthepanda wrote: post #46
bedobi wrote: post #31

Earlier quoted context omitted.

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

I believe the kind of scenario that bedobi is referring to is something like this (using your example):

Unit test exists, ExampleFactory only calls ExampleService once.

Hmm, it turns out that ExampleUIButton calls ExamplePoxyNavigator more than one time if the text in ExampleUIButton happens to be wider than the default width for the button.

What does ExampleProxyNavigator do? Oh, it calls ExampleFactory which calls ExampleService. But only when the whole system is wired up for deployment.

The unit tests indicate that the system should be functioning okay, but when you put everything together you find out that the system does not function okay.

Re: The day I started believing in unit tests

#63

Post by mrweasel »

It is a little sad to see so many be so dismissive of unit tests. They aren't a universal solution, which seems to be why they are written off in many cases, but they make your life so much easier in so many cases.

If you need to mock out 80% of a system to make your unit test work, then yes, it's potentially pointless. In that case I'd argue that you should consider rewriting the code so that it's more testable in isolation, that will also help you debug more easily.

What I like to do is write tests for anything that's just remotely complex, because it make writing the actual code easier. I can continuously find mistakes by just typing "tox" (or whatever tool you use). Or perhaps the thing I'm trying to write functionality for is buried fairly deep in an application, then it's nice to be reasonably sure about the functionality before testing it in the UI. Unit tests just makes the feedback loop much shorter.

Unlike others I'd argue that MOST projects are suited for unit testing, but there might be some edge cases where they'd provide no value at all.

On caveat is that some developers write pretty nasty unit tests. Their production code is nice and readable, but then they just went nuts in the unit tests and created a horrible unmaintainable mess, I don't get why you'd do that.

Re: The day I started believing in unit tests

#64

Post by bebop »

domano wrote: post #32
toenail wrote: post #13

Earlier quoted context omitted.

> 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.

Dont take this the wrong way, but this is the answer i would get from enterprise devs usually when pointing this out. Then i would realize that their definition of a real issue was completely removed from any business or user impact, but geared more towards their understanding of the process detail in question. I would argue that there certainly are some good places for unit tests, like if you have some domain-driven…

Not disagreeing with your points. One thing mocks can be good at is to simulate errors that would be difficult to reproduce in an actual stack. For example, maybe you want to try and handle transient network issues or db connection failures, a mock could throw the correct exception easily, making your full stack do this would be challenging.

Re: The day I started believing in unit tests

#65

Post by berkes »

lokar wrote: post #47
berkes wrote: post #43

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. 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

Indeed! It's one of the reasons I like the adapter pattern (aka hexagonal architecture) so much.

Data flowing through some 100 classes and 300 conditionals then into a `memory-payments` and back takes mere milliseconds. "Memory payments" is then some silly wrapper around a hashmap with the same API as the full-blown production payments-adapter that calls stripe over HTTP. Or the same api as the "production adapter" that wraps some RDBMS running on the other end of the data-center.

Re: The day I started believing in unit tests

#66

Post by bedobi »

bobthepanda wrote: post #46
bedobi wrote: post #31

Earlier quoted context omitted.

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

I understand your example and I agree that in that particular case, maybe a unit test to ensure a given service calls a dao once and only once or whatever is justified

but I don't think the hypothetical risk of someone needlessly calling the db ten times is a good reason to justify adding that style unit tests to everything by default - if it happens, sure, add one for that particular call and call it a day

Re: The day I started believing in unit tests

#67

Post by smrtinsert »

Said it before and will say it again. There is no replacement for unit test - it is the only thing that will give you flawless deployments. Not MIT degrees, not process, not managers - tests are the literally the only thing I've seen consistently produce flawless production deployments. It's not a discussion.

Re: The day I started believing in unit tests

#68

Post by rileymat2 »

randomdata wrote: post #25
cjfd wrote: post #10

Earlier quoted context omitted.

No. Or maybe only if you also consider 'village' and 'city' to be the same thing.

Implying that integration tests (or vice versa) are legally incorporated like cities, while unit tests are not? What value is there in recognizing a test as a legal entity? Does the, assuming US, legal system even allow incorporation of code? Frankly, I don't think your comparison works.

I think he is not implying a hard line legal standard but as connections and size increase different properties start to emerge humans start to differentiate things based on that, but there is a gradient so we can find examples that are hard to classify.

Re: The day I started believing in unit tests

#69

Post by mdgrech23 »

bicijay wrote: post #4

We can't even have a consensus on what "unit" tests really are... Every company i work for has a different meaning for it. Some places consider a test "unit" when all the dependencies are mocked, some places consider a whole feature a "unit".

I get the logic from the mocking camp e.g. we're not here to test this dependency we're just here to test this function/method whatever but when you mock you end up making assumptions about how that dependency works. This is how you end up w/ the case of all my tests are green and production is broke.

I think it's hard to beat e2e testing. The thing is e2e tests are expensive to write and maintain and in my opinion you really need a software engineer to write them and write them well. Now manual e2e testing is cheap and can be outsourced. All the companies I've worked for in the US have had testing departments and they did manage to write a few tests but they were developers and so to be frank they were really bad at writing them. They did probably 80 or 90% of their testing manually. At that point who we kidding. Just say you do manual testing, pay your people accordingly and move on.

Re: The day I started believing in unit tests

#70

Post by m3kw9 »

Unit tests is like buying insurance but you don’t know how much insurance has paid you if things go wrong. You spend a lot of time and effort to make your code testable, figure out what the useful test is and change the unit test when you do refactors in hope it speeds up your project, except you cannot really know if there was a net gain in speed/ reliability vs proper QA and other techniques
Post reply on HN