There's a leaky reasoning about the abstraction hierarchy I think. Beyond, or until a certain layer - I know that I can trust the process. I'm fine baking, I trust the physical process.
Programmers should never trust anyone, not even themselves
81–90 of 163 posts
Re: Programmers should never trust anyone, not even themselves
#82Earlier quoted context omitted.
> 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.
By users I assume you mean other developers who use the API (including you next week). It would be better to use a different term as often user means "end user" or "customer" and not internal users.
Re: Programmers should never trust anyone, not even themselves
#83Earlier quoted context omitted.
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
#84> 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.
It is just the cost of good quality. This is like suggesting you shouldn't write error handling code, because the code might change and have different errors that need to be handled.
Also if the interface doesn't change but your unit tests fail on a data structure change then perhaps your tests are too coupled.
Re: Programmers should never trust anyone, not even themselves
#85> 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.
Most of the time I already know what I'm going to write. Thus most of the time I can start with a simple test and it isn't too early. It is rare to be presenting with a problem in code that you don't know if it is solvable or how to solve it and jump right into code (as opposed to research, or white board discussions), which then gets enough in place that it isn't too early.
Re: Programmers should never trust anyone, not even themselves
#86> 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.
This is why I'm not sure more languages don't instil the idea of "public" and "private" tests like Go does.
Your "public" tests should document the API for future programmers. This is the concrete contract that should never change, no matter what happens to the implementation. If these tests break, you've done something wrong.
Your "private" tests are experiments that future programmers know can be removed if they no longer fit the direction of the application.
Re: Programmers should never trust anyone, not even themselves
#87> 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 a…
The first box on the testing checklist states that the test should first fail. I wonder how they managed to not test anything while seeing the tests transition from failure to success.
Re: Programmers should never trust anyone, not even themselves
#88Earlier quoted context omitted.
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.
By users I assume you mean other developers who use the API (including you next week). It would be better to use a different term as often user means "end user" or "customer" and not internal users.
Yeah, I'm not sure what the better word is. As a programmer, I use APIs. "interact with", "code to/against". I think "user" is OK. We're all users at different levels of abstraction.
Re: Programmers should never trust anyone, not even themselves
#89> 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, but aren't that useful before that point
I disagree, but not entirely. I think there's a balance. Tests can be a great way to execute code in isolation with expected inputs/outputs and can help dramatically in absence of other ways to execute the code. But in general, I mostly agree. Tests are mostly valuable as a way of ensuring you don't break something that was previously working, but they are still valuable for validating assumptions as you go.
Re: Programmers should never trust anyone, not even themselves
#90Earlier quoted context omitted.
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.
https://www.youtube.com/watch?v=3mnG_Gbxf_w
If it is a tesla computer you can be certain it wont stop.