4 ms·

I spent some time in Web Apps between video game jobs. I got into some tense conversations where I, as manager, recommended against the abstraction layers the S

I spent some time in Web Apps between video game jobs. I got into some tense conversations where I, as manager, recommended against the abstraction layers the Senior Developer was trying to explain to the team on a whiteboard. He said something like "Why do all the game developers write code like that?". He handed me Uncle Bob's Clean Architecture. Uncle Bob is something of a meme to me. I read the book and couldn't figure out how to explain how I thought this style was inferior to what I had done in games before. Ive been thinking about that ever since it happened. How could I explain to this guy my programming philosophy? Last night, back in games, after refactoring the same piece of layout code for several hours, I finally arrived at the irreducible, simple, clean result that I wanted. I slotted it into our code base, and mentally noted how I would onboard the team to it on Monday, and how they would instantly understand because the resultant code is so simple. Then it came to me: "Unit Tests are like pouring concrete on your code base." Same goes for using "the wrong abstraction". Sometimes you want concrete to encase your precious technology. The problem is when people are writing sub par code, then they pour all this concrete on it via Unit Tests, Inheritance and Abstraction Patterns. It can become harder to improve the core logic of the system if it's distributed across many files, and enshrined in Unit Tests. I've dedicated over 10 years to coding, and only now do I think I can write clean code that is worth encasing in concrete. I think there might be a general flaw in the idea that everyone should be writing tests. I'm not certain about this, it's just my general intuition based on my experience. They are pros and cons to every design decision. I acknowledge that they are many pros to these kinds of designs, I'm just enumerating some cons that have arisen from my experience.

villasv 6y ago
> "Unit Tests are like pouring concrete on your code base." My experience is the exact opposite. Tests make me feel safe to perform code changes a bit more aggressively than simple refactors. If behavior coverage is slow, I spend more time double checking I'm not breaking stuff along the way. Sometimes changing implementation will mean changing tests too which might seem to be defeating the point, but this is because the test isn't good yet so it's an opportunity to improve the test and stop leaking implementation details. To me, it pays off handsomely in the long run.
- legulere 6y ago
  If you have real unit tests then refactoring code also means refactoring unit tests, as they just test small units like functions in isolation. When refactoring you will need to replace units or delete them to be able to change units that are higher up in the abstraction. You may end up testing a lot of implementation details and keep them from changing. If you only write tests of the higher abstracted units while also using the lower abstraction ones, you are not really doing unit testing anymore but what some people call integration testing. In my opinion they both have their place. Most of the code we write is relatively throw-away code that will be used in one project/occasion and is prone to be changed because of changing requirements. You should test your requirements and functionality with integration tests, unit tests will cost too much time and will stand in your way. In rare cases we write code that is really reusable in a bigger scope and acts like a foundation set in stone that rarely changes and is widely reused. In general you should put way more effort in those and also use unit tests there.
  - villasv 6y ago
    I guess what you consider unit testing I consider useless testing, what you call integration testing I call unit testing, and maybe what I call integration testing you would consider end-to-end testing?
SideburnsOfDoom 6y ago
> "Unit Tests are like pouring concrete on your code base." If they're very closely coupled to your code, yes. I'll just say there's a reason why they're called "unit tests" not "class tests": because a "unit" is not necessarily a "class". You get to choose how big a unit is, and if it impedes change - like pouring concrete - choose differently.
- nightowl_games 6y ago
  Ya. I agree. If you can write good tests, they are very useful. I guess I'm thinking that for a lot of shops, for alot of features, the tests are doing more harm than good. Perhaps by merely sucking up so much developer time that the devs take longer to develop the intuitive feel for good code vs bad code. I've always felt that "good code" is far superior to mediocre code with tests. I'm sure a lot of this is because I've never been impressed with the "testing culture" at any place where I have worked, it's always just a tacked on bullet point on some sprint board check list. I guess for me, I feel like I have developed an intuitive sense for good code that has mostly come through real, lived, expensive, mistakes. I know it makes no sense as a programmer philosophy, but I truly think I care way more about every line of code because I have no unit tests. There is no safety net. I've been writing code like this for a very long time, and I think I've developed a certain skill that has been empowered by these high stakes. Pushing bad code and having GitHub tell you about a failed test before it ever hits prod is not nearly as powerful of a feedback loop as watching a crash rate sky rocket, having the Google Play store ranking tank and ultimately cost an unknown, large amount of revenue. I'll never forget that merge. I guess I'm not against "unit tests", I'm just speaking about the kinds of lessons I've had and how they influence literally every line of code I write or read. Ultimately, yes, I've made big mistakes, but at this point I think I write better code, at a faster pace, than my peers who haven't had these "trial by fire" experiences. I know it's not for everyone, but I feel as though it has made me stronger.
  - SideburnsOfDoom 6y ago
    > I guess I'm thinking that for a lot of shops, for alot of features, the tests are doing more harm than good. Yes. Let me say that the conclusion that reached above about "unit != class" is one that I was forced to reach recently, by team members assuming the opposite. In a lot of shops, the tests are done by rote, doing the opposite of what I said above: closely-coupled class tests on each public method. "pouring concrete" is a good description of the outcome.

villasv 6y ago

> "Unit Tests are like pouring concrete on your code base." My experience is the exact opposite. Tests make me feel safe to perform code changes a bit more aggressively than simple refactors. If behavior coverage is slow, I spend more time double checking I'm not breaking stuff along the way. Sometimes changing implementation will mean changing tests too which might seem to be defeating the point, but this is because the test isn't good yet so it's an opportunity to improve the test and stop leaking implementation details. To me, it pays off handsomely in the long run.

legulere 6y ago
If you have real unit tests then refactoring code also means refactoring unit tests, as they just test small units like functions in isolation. When refactoring you will need to replace units or delete them to be able to change units that are higher up in the abstraction. You may end up testing a lot of implementation details and keep them from changing. If you only write tests of the higher abstracted units while also using the lower abstraction ones, you are not really doing unit testing anymore but what some people call integration testing. In my opinion they both have their place. Most of the code we write is relatively throw-away code that will be used in one project/occasion and is prone to be changed because of changing requirements. You should test your requirements and functionality with integration tests, unit tests will cost too much time and will stand in your way. In rare cases we write code that is really reusable in a bigger scope and acts like a foundation set in stone that rarely changes and is widely reused. In general you should put way more effort in those and also use unit tests there.
- villasv 6y ago
  I guess what you consider unit testing I consider useless testing, what you call integration testing I call unit testing, and maybe what I call integration testing you would consider end-to-end testing?

SideburnsOfDoom 6y ago

> "Unit Tests are like pouring concrete on your code base." If they're very closely coupled to your code, yes. I'll just say there's a reason why they're called "unit tests" not "class tests": because a "unit" is not necessarily a "class". You get to choose how big a unit is, and if it impedes change - like pouring concrete - choose differently.

nightowl_games 6y ago
Ya. I agree. If you can write good tests, they are very useful. I guess I'm thinking that for a lot of shops, for alot of features, the tests are doing more harm than good. Perhaps by merely sucking up so much developer time that the devs take longer to develop the intuitive feel for good code vs bad code. I've always felt that "good code" is far superior to mediocre code with tests. I'm sure a lot of this is because I've never been impressed with the "testing culture" at any place where I have worked, it's always just a tacked on bullet point on some sprint board check list. I guess for me, I feel like I have developed an intuitive sense for good code that has mostly come through real, lived, expensive, mistakes. I know it makes no sense as a programmer philosophy, but I truly think I care way more about every line of code because I have no unit tests. There is no safety net. I've been writing code like this for a very long time, and I think I've developed a certain skill that has been empowered by these high stakes. Pushing bad code and having GitHub tell you about a failed test before it ever hits prod is not nearly as powerful of a feedback loop as watching a crash rate sky rocket, having the Google Play store ranking tank and ultimately cost an unknown, large amount of revenue. I'll never forget that merge. I guess I'm not against "unit tests", I'm just speaking about the kinds of lessons I've had and how they influence literally every line of code I write or read. Ultimately, yes, I've made big mistakes, but at this point I think I write better code, at a faster pace, than my peers who haven't had these "trial by fire" experiences. I know it's not for everyone, but I feel as though it has made me stronger.
- SideburnsOfDoom 6y ago
  > I guess I'm thinking that for a lot of shops, for alot of features, the tests are doing more harm than good. Yes. Let me say that the conclusion that reached above about "unit != class" is one that I was forced to reach recently, by team members assuming the opposite. In a lot of shops, the tests are done by rote, doing the opposite of what I said above: closely-coupled class tests on each public method. "pouring concrete" is a good description of the outcome.