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

Programmers should never trust anyone, not even themselves

carbon-steel.github.io

Post reply on HN
Print view View original

71–80 of 163 posts

Re: Programmers should never trust anyone, not even themselves

#71

Post by randomdata »

dartos wrote: post #65
fendy3002 wrote: post #63

Earlier quoted context omitted.

Unpopular opinion, but I always say that unit tests are contracts for the API. If you don't want / don't need to make contract, don't do unit tests. Unit tests main purpose is not to improve code or reduce bug, it's main purpose is to verify the code to work against the contract that's defined in unit tests. Code improvement or bug reduction are added benefit, if any.

> Unpopular opinion, but I always say that unit tests are contracts for the API You’re talking about integration tests or e2e tests. Those don’t sound like unit tests.

That's exactly what Beck described when he originally coined the term.

Re: Programmers should never trust anyone, not even themselves

#73

Post by [deleted] »

atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

[deleted]

Re: Programmers should never trust anyone, not even themselves

#76

Post by bluGill »

dartos wrote: post #65
fendy3002 wrote: post #63

Earlier quoted context omitted.

Unpopular opinion, but I always say that unit tests are contracts for the API. If you don't want / don't need to make contract, don't do unit tests. Unit tests main purpose is not to improve code or reduce bug, it's main purpose is to verify the code to work against the contract that's defined in unit tests. Code improvement or bug reduction are added benefit, if any.

> Unpopular opinion, but I always say that unit tests are contracts for the API You’re talking about integration tests or e2e tests. Those don’t sound like unit tests.

Unit tests testing the API - if there is no API there then the level of unit it probably too low. The purposes of all tests is to say "No matter what this will never change" - while never is a bit to strong as you are allowed to make changes any API that your unit tests covers will be painful to change, both because the tests will also have to change and so you have nothing to guide you, and also because odds are you don't have good coverage from other tests (integration tests would catch issues, but you rarely have all cases covered).

Or to put it a different way, your unit tests should cover units that have a good boundary to the rest of the system. This should sound like a module, but there is reason to have module as a larger thing than your unit (most of the time there shouldn't be, but once in a while this is useful), and so while there is overlap it is often useful to consider them different.

Integration tests cover the API, but they do not test the API (well they often use some API as well, but the won't cover all your internal APIs.)

Re: Programmers should never trust anyone, not even themselves

#77

Post by nullserver »

atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

I inherited an ancient project that had literally tens of thousands of test.

I reviewed hundreds of them, tried rewriting dozens of them. Eventually, realize that essentially all of the tests were just testing that mock data being manually manipulated by the test gave the result of test expected.

Absolutely nothing useful was actually being tested.

Some team spent a couple of years writing an unholy number of tests as a complete waste of time. Basically just checking off a box that code had tests.

Re: Programmers should never trust anyone, not even themselves

#78

Post by willcipriano »

HankB99 wrote: post #70
atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

> something that the developer didn't think to test at all. Raising hand, guilty as charged. I test for things based in my concept of how the system works, but those darn users may have other ideas! Actually, when I found a user who seemed to have a knack for finding bugs, they were gold and I let them know I appreciated their efforts. > unit tests should be used to baseline something after it ships That has not been…

> those darn users may have other ideas

Getting those ideas in front of you is the job of the product team.

It isn't your fault if the guy writing the ticket refuses to talk to the users/and or/you.

"Ticket meets acceptance criteria, please submit a new request for this new feature."

Re: Programmers should never trust anyone, not even themselves

#79

Post by gchamonlive »

atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

Tests are akin to scientific experiments. They test hypothesis and try to falsify claims. They shouldn't be seen as ground truth, but ways to gain information about what the system claims to be doing. In this sense it makes sense that tests will become obsolete or evolve with the system, because the model and domain upon which the system is based also evolves and changes with time.

Re: Programmers should never trust anyone, not even themselves

#80

Post by randomdata »

atribecalledqst wrote: post #60

> Failing tests indicate the presence of bugs, but passing tests do not promise their absence. As somebody who primarily lives on the testing side of the house, I've definitely run into cases where the developer promises that their unit tests will make a new feature less buggy, then about 5 minutes later I either find a mistake in the test or I find a bug in something that the developer didn't think to test at all. I…

> I've generally come to think that unit tests should be used to baseline something after it ships

In theory, but I've never seen anyone successfully write tests after something ships. By that time much of the context that should be documented in tests is forgotten.

Post reply on HN