4 ms·

Unit tests can never give you "confidence". > you can watch as over time you get either increasing error rates or a massive slow down in team performance I he

by hbrn 4y ago

Unit tests can never give you "confidence". > you can watch as over time you get either increasing error rates or a massive slow down in team performance I hear this story repeated over and over and yet I consistently witness the opposite of what you're describing: teams start investing in unit testing and they noticeably slow down and ship more bugs at the same time. What can give you confidence is simplicity. Being able to fit the entire system in your head. Being able to say what are the side effects of your changes. If you feel like you're losing those, it's time to take a step back and rethink your architecture. But of course, nobody has the balls to take a step back and think, to admit that you failed at something. It's so much easier to just slap a bunch of unit tests on your big ball of mud and hope for the best.

Jtsummers 4y ago
I didn't mention unit tests, so maybe you meant to respond to someone else? Or you're just shouting into the wind about something that wasn't said for fun? I was writing about tests generally, in case you were wondering.
- hbrn 4y ago
  The comment you responded to says unit tests give confidence, you seem to agree. "Tests generally" and unit tests are pretty much the opposite camps in testing world.
  - Jtsummers 4y ago
    I agreed about the word "confidence" and the importance of testing for confidence. You read something into my comment that I did not write nor did I intend. Good for you, I guess.
turnsout 4y ago
If you can fit the entire system in your head, it's probably a relatively simple codebase. I've written a Photoshop file format parser twice, and trust me—between byte alignment changing constantly throughout the spec, at least three different string encodings, sub-formats and errors in the spec—it does not "fit in your head." Certainly not enough to confidently add features without worrying that you've broken the blend mode parser. And of course, if you can and do fit a complex system in your head when no one else on the team can, congratulations: you've made yourself into a bottleneck and flight risk.
- hbrn 4y ago
  > If you can fit the entire system in your head, it's probably a relatively simple codebase. Or it has good boundaries and I never have the need to load the whole system in my head. You're not loading the whole OS kernel in your head every time you call fopen(), do you? > Photoshop file format parser Would you say that PSD format is an example of good design? Is complexity inherent to the problem domain, or is it accidental? You are forced to replicate complexity created by other engineers. Woe is you. My bet is that Adobe also has a lot of unit tests, and contrary to what unit-testing advocates claim, it resulted in a terrible design you are dealing with.
  - turnsout 4y ago
    My friend, half of software engineering is handling complexity created by other developers. If you're implementing a Mastodon client, you don't get to just refuse to deal with OAuth because its design offends you on a philosophical level.
    - hbrn 4y ago
      But I get to refuse to turn OAuth into a cross-cutting concern in my application. You won't see refresh tokens referenced in the UI code. And I get to use a 3rd-party library that solves 90% of the pain for me. I strongly disagree on the ratio. If you're building Mastodon client, most of your effort should be spent on features and UX, not on OAuth and the like. If half of your time is spent on those, either you're at the beginning of the project, or you're at the beginning of your career. Or maybe you just care about engineering itself more than the end product.
      - turnsout 4y ago
        If you peek at that third party OAuth library, you will discover… it's complex. This is what I mean about pushing the complexity around on your plate. You can make it someone else's problem (and become dependent on them), but the complexity is still there. There is a minimum level of complexity that any OAuth system needs to have in order to function. QED

by hbrn 4y ago

Jtsummers 4y ago

I didn't mention unit tests, so maybe you meant to respond to someone else? Or you're just shouting into the wind about something that wasn't said for fun? I was writing about tests generally, in case you were wondering.

hbrn 4y ago
The comment you responded to says unit tests give confidence, you seem to agree. "Tests generally" and unit tests are pretty much the opposite camps in testing world.
- Jtsummers 4y ago
  I agreed about the word "confidence" and the importance of testing for confidence. You read something into my comment that I did not write nor did I intend. Good for you, I guess.

turnsout 4y ago

If you can fit the entire system in your head, it's probably a relatively simple codebase. I've written a Photoshop file format parser twice, and trust me—between byte alignment changing constantly throughout the spec, at least three different string encodings, sub-formats and errors in the spec—it does not "fit in your head." Certainly not enough to confidently add features without worrying that you've broken the blend mode parser. And of course, if you can and do fit a complex system in your head when no one else on the team can, congratulations: you've made yourself into a bottleneck and flight risk.

hbrn 4y ago
> If you can fit the entire system in your head, it's probably a relatively simple codebase. Or it has good boundaries and I never have the need to load the whole system in my head. You're not loading the whole OS kernel in your head every time you call fopen(), do you? > Photoshop file format parser Would you say that PSD format is an example of good design? Is complexity inherent to the problem domain, or is it accidental? You are forced to replicate complexity created by other engineers. Woe is you. My bet is that Adobe also has a lot of unit tests, and contrary to what unit-testing advocates claim, it resulted in a terrible design you are dealing with.
- turnsout 4y ago
  My friend, half of software engineering is handling complexity created by other developers. If you're implementing a Mastodon client, you don't get to just refuse to deal with OAuth because its design offends you on a philosophical level.
  - hbrn 4y ago
    But I get to refuse to turn OAuth into a cross-cutting concern in my application. You won't see refresh tokens referenced in the UI code. And I get to use a 3rd-party library that solves 90% of the pain for me. I strongly disagree on the ratio. If you're building Mastodon client, most of your effort should be spent on features and UX, not on OAuth and the like. If half of your time is spent on those, either you're at the beginning of the project, or you're at the beginning of your career. Or maybe you just care about engineering itself more than the end product.
    - turnsout 4y ago
      If you peek at that third party OAuth library, you will discover… it's complex. This is what I mean about pushing the complexity around on your plate. You can make it someone else's problem (and become dependent on them), but the complexity is still there. There is a minimum level of complexity that any OAuth system needs to have in order to function. QED