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

231–240 of 269 posts

Re: The day I started believing in unit tests

#231

Post by throwaway2037 »

jamesu wrote: post #77
donatj wrote: post #21

I was ambivalent on unit tests until I discovered how much the mere act of writing them was finding bugs. I very vividly remember writing a test for a ~40 loc class of pure functions. I started out thinking the exercise was a waste of time. This class is simple, has no mutable state, and should have no reason to change. Why bother testing it? By the time I was done writing the test I had found three major bugs in tha…

I bumped into so many corner case and dumb bugs on a recent python project that I'm even more of a unit testing enthusiast than before. Past a certain level of complexity they are definitely a net benefit.

You mentioned Python. I struggle with the weak(er) typing. It is a bottomless well of bugs. Did your unit tests find type issues or (business) logic / state issues?

Re: The day I started believing in unit tests

#232

Post by throwaway2037 »

fijiaarone wrote: post #230
_dain_ wrote: post #184

Earlier quoted context omitted.

>"this combination of preconditions yield a business logic edge case that wasn't accounted for". Static typing doesn't really help more than dynamic typing in these cases. Depends on the language and the business logic. Types are a way of specifying preconditions and postconditions; a more expressive type system lets you rule out more edge cases by making illegal states unrepresentable. In particular, I'm pretty sure…

It’s also not possible to write a non-trivial program in Rust.

"Servo is a web rendering engine written in Rust"

Is Servo non-trivial? I think yes.

Re: The day I started believing in unit tests

#233

Post by throwaway2037 »

kibwen wrote: post #140
throwaway290 wrote: post #118

Earlier quoted context omitted.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

Having static types is like having an automatic, exhaustively comprehensive, efficient unit test generator for the classes of bugs whose units tests are the most boring and annoying to write and maintain. Static types don't prevent you from needing unit tests, they free you up to focus on writing tests that are actually interesting.

I agree with your post. To be more specific, you can focus more on logic and state bugs.

Re: The day I started believing in unit tests

#234

Post by throwaway2037 »

pfdietz wrote: post #123
throwaway290 wrote: post #118

Earlier quoted context omitted.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

Why isn't the question "does adequate testing dramatically reduce the benefits of static typing" asked? Why is static typing privileged by default?

"[A]dequate testing": Woah, I love this term. It is judgmental right from the start. It's right up there with "convention over configuration" and "well, if you wear your face mask _correctly_..." I once saw a blog post from an embedded programmer talking about how difficult it is to write "adequate" unit tests for embedded code. If you are writing code that will run in a heart pace maker or aeroplane auto-pilot/lander, it needs to be insanely well tested.

Re: The day I started believing in unit tests

#235

Post by throwaway2037 »

diarrhea wrote: post #201
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…

Interesting take. I find structuring code to be testable to make the code much clearer: mainly, by making dependencies explicit via dependency injection. I do that even if I don’t end up testing the code.

I have an identical experience. What really made me understand dependency injection (in Java) was being forced to write 100% code coverage unit tests. To be clear: 100% code coverage was absolutely overkill for my domain, but it was a lesson about how to structure your code for dependency injection.

Re: The day I started believing in unit tests

#236

Post by AtlasBarfed »

teeray wrote: post #2

I still like one of the defining characteristics of Unit Tests (paraphrasing Michael Feathers from memory): they are fast and cheap to run. Sure, they might not perfectly simulate production like integration tests, but they also don’t take hours burning cash in cloud infrastructure while risking failure from unrelated races dealing with those dependencies. You can use Unit Tests to get to a place where you’re fairly…

THey are fast and cheap WHEN YOU FIRST WRITE THE CODE. Or, if you are the original author of the code.

The problem is, and there will be people that disagree with me, is that unit tests make refactoring of other people's code a lot harder.

STAY WITH ME!

If the unit tests were "good" and helped document what the code does, then they don't. You won't believe this, but in dogmatic high-breadth-coverage (low depth coverage), there are tons of test code that is SO TIED TO IMPLEMENTATION rather than interface than any monkeying of the presumed encapsulated logic breaks the unit tests, so you have double the things to fix.

You'll never believe what happens next. Some developer in some Agile thing that got assigned 2 unicorn shits for the task panics because the unit tests are SERIOUSLY slowing down his "velocity". So what does he do? Delete tests, change tests to make them work at any costs.

Re: The day I started believing in unit tests

#237

Post by throwaway2037 »

makeitdouble wrote: post #208
__MatrixMan__ wrote: post #29

Earlier quoted context omitted.

You should try switching it up. Write the tests and then ask the LLM to write the code that makes them pass. I find I'm more likely to learn something in this mode.

I'd argue having useable LLMs kind of brings out how problematic TDD is. Imagine the dumbest function you have to write: a product A and a street address as input, and the shipping cost as an output. How many test cases would you write to be absolutely sure that function actually does what you want it to do, and be confident it doesn't have weird exceptions that the LLM injected randomly ? I'd assume you'd still vet…

About the problems of TDD: Cedric Beust has a legendary blog post about it here: https://www.beust.com/weblog/the-pitfalls-of-test-driven-dev...

Re: The day I started believing in unit tests

#238

Post by throwaway2037 »

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.

3) Preventing reintroducing known bugs

When I was learning unit testing, my mentor taught me this strategy when fixing production bugs. First, write the unit test to demonstrate the bug. Second, fix the bug.

Re: The day I started believing in unit tests

#239

Post by throwaway290 »

kibwen wrote: post #140
throwaway290 wrote: post #118

Earlier quoted context omitted.

It matters enough that the question "does static typing dramatically reduce the benefits of unit testing" is an open question or at least seriously discussed in the industry. All other replies are about dynamic languages.

Having static types is like having an automatic, exhaustively comprehensive, efficient unit test generator for the classes of bugs whose units tests are the most boring and annoying to write and maintain. Static types don't prevent you from needing unit tests, they free you up to focus on writing tests that are actually interesting.

This, but depending on how good the type system is and how well it's used most remaining interesting tests may be integration aside from legit things like https://news.ycombinator.com/item?id=38692634

Re: The day I started believing in unit tests

#240

Post by linsomniac »

nerdponx wrote: post #221
linsomniac wrote: post #33

Earlier quoted context omitted.

That reminds me of this time I wrote some code to add a method to Python string objects. The first reply to my issue on it in the bug tracker was "We shouldn't accept this, it's trivial to implement in your own code, see: XXXX". The second reply was "You have a bug in your implementation in the first reply." It took a couple years to be accepted.

Sounds familiar. Was that str.removeprefix?

str.rsplit()
Post reply on HN