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

61–70 of 163 posts

Re: Programmers should never trust anyone, not even themselves

#61

Post by englishspot »

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 don't think I'll ever be able to convince anybody at my company about this though lol

especially if the company uses 100% code coverage as a metric for success

Re: Programmers should never trust anyone, not even themselves

#62

Post by blitzar »

eru wrote: post #58
blitzar wrote: post #45

Earlier quoted context omitted.

I trust the computer far more than the fellow humans. The computer will generally give a predictable output for a given input. "fellow humans in daily life" .... not so much.

I hope you never have to cross a street, or get anywhere near a car with a human behind the wheel.

Its terrifying; sometimes when I am crossing the street people accelerate, sometimes they slow down, sometimes they stop at red lights, sometimes they drive through them.

Re: Programmers should never trust anyone, not even themselves

#63

Post by fendy3002 »

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…

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.

Re: Programmers should never trust anyone, not even themselves

#64

Post by dartos »

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 been preaching this for a while.

When a codebase gets too big, and devs gets too clever with their tests, the whole test suite becomes complicated.

If your test suite is approaching the complexity of the actual codebase (what with layers of mocks and fixtures that are subtly interdependent,) how could you be expected to trust a test you wrote more than the code you wrote.

Re: Programmers should never trust anyone, not even themselves

#65

Post by dartos »

fendy3002 wrote: post #63
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…

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.

Re: Programmers should never trust anyone, not even themselves

#66

Post by jagged-chisel »

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…

> ... instances where tests are written too early ...

omg yes. However, reading this makes me wonder how the TDD people handle this.

Re: Programmers should never trust anyone, not even themselves

#67

Post by t_mahmood »

robertlagrant wrote: post #44
dncornholio wrote: post #34

Earlier quoted context omitted.

Has nothing to do with trust. I trust that you will give me the money. I also trust that you counted the right amount. But I still want to make sure you did not make a mistake.

I suppose the question is: why bother with trust? Why not just "verify"?

I trust you, about your intention and effort. But I verify because there are too many moving pieces in the world that can go wrong, that you may have no control over

Re: Programmers should never trust anyone, not even themselves

#68

Post by thfuran »

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.

Your units don't have some interface through which they interact with other units?

Re: Programmers should never trust anyone, not even themselves

#69

Post by matt_j »

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.

API doesn't imply integration. Consider any module or package to have an API exposed to the user of the package. Unit tests should assert that the package behaves as expected.

Re: Programmers should never trust anyone, not even themselves

#70

Post by HankB99 »

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 my experience. I found that unit tests let me get the pieces working properly so that when assembled, the chances that everything worked as expected were much improved.

Post reply on HN