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

81–90 of 269 posts

Re: The day I started believing in unit tests

#81

Post by Izkata »

BurningFrog wrote: post #55

The classic test rookie mindset is to test the functionality of the whole system, because that's what really matters. But in reality, unit testing every single function and method is where the vast majority of the benefit lies. Details really matter. It took me some time to learn this, even after being told. It's the same for most people. This little post will probably convince no one. But maybe remember it when you…

> every single function and method

Very much no, that's the bad kind of unit test that locks your code into a specific structure and makes it a pain to update because you also have to change all the related tests even if the actual interface used by the rest of the codebase didn't change. I would call this the rookie mistake of someone new to unit tests.

You want to encapsulate your code with some sort of interface that matches the problem space, then test to that interface. How its internals are broken down don't matter: it could be one big function, it could be a dozen functions, it could be a class, it as long as the inputs and outputs match what the test is looking for you can refactor and add/remove features without having to spend extra time changing the tests. Makes it much less of a pain to work with in general.

One way of looking at it I've used before with coworkers: For this new feature you're writing, imagine a library for it already exists. What is the simplest and most straightforward way to use that library? That's your interface, the thing you expose to the world and what you run your tests against.

This is what unit testing originally meant: semantic units, not code units.

It's like app Hungarian notation vs system Hungarian notation, the original idea got overtaken by people who didn't understand the idea and only mimicked the surface level appearance.

Re: The day I started believing in unit tests

#82

Post by troupo »

bedobi wrote: post #8
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".

Kent Beck (the originator of test-driven development) defines a unit test as "a test that runs in isolation from other tests". This is very different from the popular and completely misguided definition of a unit test as "a test that tests a class/method in isolation from other classes/methods". But it doesn't really matter if you want to call a given test an "integration" test or a "unit" test. The point of any test…

Kent Beck also said [0] "I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence"

[0] https://stackoverflow.com/a/153565

Re: The day I started believing in unit tests

#83

Post by erikpukinskis »

pfdietz wrote: post #73
agentultra wrote: post #39

It's all degrees. Unit tests are great at finding examples of errors or correct behaviours. However they prove nothing and they definitely do not demonstrate the absence of errors. They are often sufficient for a great deal of projects. If all it takes to convince you it's "good enough," are a handful of examples then that's it. As much as you need and no less. However I find we programmers tend to be a dogmatic bunc…

> they prove nothing If they fail, they prove there's a bug (in either the test or the code.) This is like literally any other kind of test.

A bug in test code is not a real bug. It’s just a test that’s not giving you useful information. Lots of tests don’t give you useful information. Some that fail and some that pass.

It’s easy to write a test that doesn’t provide useful information across time. Harder to write a test that does.

Re: The day I started believing in unit tests

#84

Post by mrweasel »

rileymat2 wrote: post #54
ejb999 wrote: post #41

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…

A sort of non-judgmental question, in your mind are you writing them to cover lines or exercise required behavior with an intent of proving the module is broken? I ask because it seems like requiring line coverage as a metric would have the effect you are describing.

I've seen the same thing with comments. My boss required us to add comments to our code, to make it easier to read. That was all he asked, please add comments. My co-worker added comments like "Increase variable i by 1", while completely ignoring the 8 lines of spaghetti business logic above.

Similarly I've seen people add tests that will ensure that code coverage doesn't go down, but it doesn't actually do anything to help anyone. I'd argue that the issue is that have random coverage goals is a problem on its own, but it's the only way to force some people to write even to most basic of tests.

Re: The day I started believing in unit tests

#86

Post by m3kw9 »

cfiggers wrote: post #48
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.

If you have worked in places where safety is critical, you wouldn’t say something so shallow. In those places they place human verification above all else. They have a thick book where you do a full run and is double checked, they don’t f around with unit tests and say this is good to go

Re: The day I started believing in unit tests

#87

Post by macshome »

m3kw9 wrote: post #74

How do you all feel about the need to rewrite a unit test when code gets refactored or business logic changes, isn’t that like a huge pita?

Generally refactoring is where I find tests to be super valuable. If it’s a pure refactor then the existing tests shouldn’t break. If they start failing, then you have done something that has changed the expected behavior.

For business logic I would change the tests first so that it represents the new expected result. Then you refactor the code until the tests pass.

Re: The day I started believing in unit tests

#88

Post by troupo »

BurningFrog wrote: post #55

The classic test rookie mindset is to test the functionality of the whole system, because that's what really matters. But in reality, unit testing every single function and method is where the vast majority of the benefit lies. Details really matter. It took me some time to learn this, even after being told. It's the same for most people. This little post will probably convince no one. But maybe remember it when you…

> But in reality, unit testing every single function and method is where the vast majority of the benefit lies. Details really matter.

To me, this is actual rookie mentality. You end up testing the same thing multiple times over different lines of code, mocking and providing various sets of testing data... When you could just test specified and/or observable behaviour of your system, and achieve the exactly same result with fewer tests.

Re: The day I started believing in unit tests

#89

Post by drittich »

I am troubled by the word belief, not just in the title, but in the comments here. Unit tests should not be doctrine, there is a time and a place. And, I feel that more often than not they are warranted.

We can argue about what granularity they should be, talk about functional programming, debate whether they should hit the database or not, but IMO all of those things miss the point. For me, in order of priority, unit tests provide the following benefits:

1) Make me write better, more decoupled code

2) Serve as documentation as to the intent of the code, and provide some expected use cases

3) Validate the code works as expected, (especially when "refactoring", which is basically how I write all my code even from the start)

4) Help you when deleting code by exposing unexpected dependencies

You can argue against all of those points, and I often will, myself. It depends on the scale, importance, and lifetime of the project as to whether I will write unit tests. But, as soon as I think someone else will work on the code, I will almost always provide unit tests. In that scenario, they:

- Provide a way to quickly validate setup and installation was correct and the application functions

- Signal that the code was "curated" in some way. Someone cared enough to setup the test environment and write some tests, and that gives me a certain comfort in proceeding to work on the code.

- Provide a gateway into understanding why the application exists, and what some of the implementation details are.

So, thinking about the advantages I've outlined above, for me it would be very hard to say I don't "believe" in unit tests. I just don't always use them.

Re: The day I started believing in unit tests

#90

Post by wharvle »

ejb999 wrote: post #41

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…

They’re way more useful in languages without static typing, where it’s easier to write or edit-in stupid bugs and not notice until the code runs. They’re not not useful in statically typed languages, just far less so.
Post reply on HN