7 ms·

I've never written unit tests in my life, and my code works most of the time. There used to be times where I'd write code for an entire week in Java without com

by nikolay 11y ago

I've never written unit tests in my life, and my code works most of the time. There used to be times where I'd write code for an entire week in Java without compiling (because it was taking forever) and back then we used pretty basic IDEs that didn't help as much as they to today to help you prevent stupid errors. And, usually, my code compiled just fine and worked. Today's developer is a trial-and-error one, tweaking a few lines of code, refreshing the browser, and seeing if stuff works or not. Today's developer spends disproportional amounts of time writing unit tests and, yet, producing buggy code.

jbclements 11y ago
Are you suggesting that an increase in unit tests is correlated with a decline in code quality? That would be a surprising correlation.
- Ingon 11y ago
  I do think sometimes about TDD as Think less driven development. The problem is not that much in TDD itself, but how its usually implemented - as a safety net and excuse for producing all kinds of bad code.
- tracker1 11y ago
  Unit tests do not correlate to quality, and even at 100% coverage only guarantee that you've looked at every line of code twice (usually). Not only that, a lot of projects skip adding testing until well after a proof of concept is working... why? because we don't want to not ship features for two weeks while we backport in tests... Now you have less than optimal code and less than optimal tests. This persists, every suggestion to refactor structure rebuffed, and this persists until the code debt is so high, it takes 4-5x as long to add a feature as it should. Where, if you're lucky, you can make a new version using only 3-5 year old technology, instead of the decade old stuff you've been supporting for half a decade. Even then the 2-5yo stuff isn't as nice as it was sold, but it's "enforced" by the company powers that be (god I hate angular sometimes).
- cydonian_monk 11y ago
  While I wouldn't suggest that, I will say spending more time manipulating my code to work with the automated unit testing tool of the month has definitely lead to an occasional decrease in code reliability. Not all code can be unit tested [with every unit testing library], and being compelled to shape everything such that it works with all once and future automated tools often makes the mess worse.
- nikolay 11y ago
  That's what happens when you rely too much on something unreliable.
onion2k 11y ago
I've never written unit tests in my life, and my code works most of the time. How do you know? I agree with your point about taking more time to think about the way your code works, to design data structures, to use rigorous methods to make sure the code works, but ultimately you still have to check things. If you haven't automated those checks then either you're checking things manually or you're not checking them. On any significant project there's too much code to check manually.
- nikolay 11y ago
  How do I know? No bugs were reported. People take % of code coverage as some insurance and spend time writing stupid tests instead of writing robust code. People also don't think that unit tests are constant maintenance burden and a time waster - you change this and that and then you need to spend time entertaining the tests. Again, use your brain, not your fingers - it's that easy! Oh, and don't program using a dynamic language saving keystrokes, but wasting, even more, writing brainless unit tests! At least in my personal career, most, though, and real issues come from race conditions. But I've been fortunate to catch them quickly by using my brain. And that's what we lack today - developers who use their brains, who don't spend too much time on emoji reactions in Slack and finding the right GIF. There's plenty lots of code monkeys and code gluers today that can't even implement a bubble sort without googling it!
  - onion2k 11y ago
    People also don't think that unit tests are constant maintenance and time waster - you change this and then, you need to spend time tweaking tests. That's why you test interfaces, that you've spent time designing so they don't change often. You, or someone else who isn't as good as you, can change the internals of a block without updating the tests. Given the choice of working with a dev who knows how to write a bubble sort[1] and a dev doesn't but does write tests, I'd go for the latter. [1] To be honest, if someone in my team even considered writing their own sort function, from memory or by googling, I'd have a quiet word. Use a library. Preferably a well-tested one.
    - 11y ago
alien3d 11y ago
Never also, don't understand at all. Bugs usually visual and business process. If wanted to type all business process to unit test not sure client willingness to paid the time.
- nikolay 11y ago
  Unit tests are no silver bullet. This trend was started by consultancies that found more ways to milk customers - write unit tests and do inline code (!) documentation. Both are a real cash cow when the client doesn't know what they want and you need to constantly tweak code and respectively tests and documentation! I understand API documentation, but internal code that's obvious like what "width" and "height" parameters of a method are for is beyond stupid!
lmm 11y ago
> Today's developer spends disproportional amounts of time writing unit tests and, yet, producing buggy code. Unit testing make you a lot more efficient. You can choose whether to spend that efficiency producing less buggy code in the same time with the same functionality, equally buggy code quicker with the same functionality, or equally buggy code in the same time with more functionality. Most of the time businesses quite reasonably decide the second or third option is more valuable.
stillworks 11y ago
That's what I have come to call FDD, Feedback Driven Development. Try something... Google/Stackoverflow it... maybe find a tangential solution to the problem at hand, fit it in the context of the problem, try something... ad nauseum

by nikolay 11y ago

jbclements 11y ago

Are you suggesting that an increase in unit tests is correlated with a decline in code quality? That would be a surprising correlation.

Ingon 11y ago
I do think sometimes about TDD as Think less driven development. The problem is not that much in TDD itself, but how its usually implemented - as a safety net and excuse for producing all kinds of bad code.
tracker1 11y ago
Unit tests do not correlate to quality, and even at 100% coverage only guarantee that you've looked at every line of code twice (usually). Not only that, a lot of projects skip adding testing until well after a proof of concept is working... why? because we don't want to not ship features for two weeks while we backport in tests... Now you have less than optimal code and less than optimal tests. This persists, every suggestion to refactor structure rebuffed, and this persists until the code debt is so high, it takes 4-5x as long to add a feature as it should. Where, if you're lucky, you can make a new version using only 3-5 year old technology, instead of the decade old stuff you've been supporting for half a decade. Even then the 2-5yo stuff isn't as nice as it was sold, but it's "enforced" by the company powers that be (god I hate angular sometimes).
cydonian_monk 11y ago
While I wouldn't suggest that, I will say spending more time manipulating my code to work with the automated unit testing tool of the month has definitely lead to an occasional decrease in code reliability. Not all code can be unit tested [with every unit testing library], and being compelled to shape everything such that it works with all once and future automated tools often makes the mess worse.
nikolay 11y ago
That's what happens when you rely too much on something unreliable.

onion2k 11y ago

I've never written unit tests in my life, and my code works most of the time. How do you know? I agree with your point about taking more time to think about the way your code works, to design data structures, to use rigorous methods to make sure the code works, but ultimately you still have to check things. If you haven't automated those checks then either you're checking things manually or you're not checking them. On any significant project there's too much code to check manually.

nikolay 11y ago
How do I know? No bugs were reported. People take % of code coverage as some insurance and spend time writing stupid tests instead of writing robust code. People also don't think that unit tests are constant maintenance burden and a time waster - you change this and that and then you need to spend time entertaining the tests. Again, use your brain, not your fingers - it's that easy! Oh, and don't program using a dynamic language saving keystrokes, but wasting, even more, writing brainless unit tests! At least in my personal career, most, though, and real issues come from race conditions. But I've been fortunate to catch them quickly by using my brain. And that's what we lack today - developers who use their brains, who don't spend too much time on emoji reactions in Slack and finding the right GIF. There's plenty lots of code monkeys and code gluers today that can't even implement a bubble sort without googling it!
- onion2k 11y ago
  People also don't think that unit tests are constant maintenance and time waster - you change this and then, you need to spend time tweaking tests. That's why you test interfaces, that you've spent time designing so they don't change often. You, or someone else who isn't as good as you, can change the internals of a block without updating the tests. Given the choice of working with a dev who knows how to write a bubble sort[1] and a dev doesn't but does write tests, I'd go for the latter. [1] To be honest, if someone in my team even considered writing their own sort function, from memory or by googling, I'd have a quiet word. Use a library. Preferably a well-tested one.
  - 11y ago

alien3d 11y ago

Never also, don't understand at all. Bugs usually visual and business process. If wanted to type all business process to unit test not sure client willingness to paid the time.

nikolay 11y ago
Unit tests are no silver bullet. This trend was started by consultancies that found more ways to milk customers - write unit tests and do inline code (!) documentation. Both are a real cash cow when the client doesn't know what they want and you need to constantly tweak code and respectively tests and documentation! I understand API documentation, but internal code that's obvious like what "width" and "height" parameters of a method are for is beyond stupid!

lmm 11y ago

> Today's developer spends disproportional amounts of time writing unit tests and, yet, producing buggy code. Unit testing make you a lot more efficient. You can choose whether to spend that efficiency producing less buggy code in the same time with the same functionality, equally buggy code quicker with the same functionality, or equally buggy code in the same time with more functionality. Most of the time businesses quite reasonably decide the second or third option is more valuable.

stillworks 11y ago

That's what I have come to call FDD, Feedback Driven Development. Try something... Google/Stackoverflow it... maybe find a tangential solution to the problem at hand, fit it in the context of the problem, try something... ad nauseum