3 ms·

I think most unit testing is a waste because it duplicates what a good type checker would do for you. I'm using TypeScript now, and after a break from using typ

I think most unit testing is a waste because it duplicates what a good type checker would do for you. I'm using TypeScript now, and after a break from using typed languages, it's a huge breath of fresh air. Much of the code I write doesn't get unit tests at all, because it's simple enough that it won't ever fail. Refactoring major blocks of code is safe, even without unit tests, because the type checker ensures that everything is wired up in a sane manner when you're done. Good design can obviate the need for many unit tests. When people talk about test code coverage in JavaScript/Ruby/Python, I think the main reason they want close to 100% coverage is that many runtime failures in those languages occur because some line of code somewhere is accessing a type incorrectly. That doesn't happen if you're using static typing. If you've got some complex logic, making sure it works using unit tests is fine. I still do that with anything I consider non-trivial. But if you've got a really simple function that obviously works, and TypeScript ensures the function will always get the types it's expecting, writing tests to ensure it will keep working forever is just a waste of time, unless it's to verify for your own sake that the "obvious" function does what you think it should. But in that "TDD" case, keeping the test around just makes the code base more brittle, since if you decide you need to change the way the function works you now have two functions to maintain instead of just one.

aprdm 10y ago
TDD "got mainstream" with Java which is a compiled language. Therefore I don't think you're correct. It's usually the most simple functions that hide the most subtle bugs.
- thatswrong0 10y ago
  And subtle bugs often arise out of edge cases, and edge case issues aren't caught by most type systems.
- SomeCallMeTim 10y ago
  Really? I saw it mostly in the Ruby community first, followed by Python and JavaScript. Looking at the WikiPedia page, it looks like it came from Extreme Programming and the C3 project [1], which was SmallTalk. And in case you aren't sure, SmallTalk is dynamically typed. [2] Java has a huge enterprise presence as well, so I'm not too surprised that it's popular in Java circles. Enterprise developers aren't famously top-notch developers in general. >It's usually the most simple functions that hide the most subtle bugs. I can't remember the last time a type-checked simple function I wrote hid a subtle bug. But I'm admittedly a few sigmas above average, so my experience is probably not typical. In studies, TDD is a wash: It neither improves overall programmer throughput nor makes it worse. So use it if it's what makes you happy. I've used it for more complex goals myself, so I understand the draw. I just usually don't need it. [1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... [2] https://en.wikipedia.org/wiki/Smalltalk-80 https://en.wikipedia.org/wiki/Smalltalk-80
  - aprdm 10y ago
    You're funny in the "Enterprise developers aren't famously top-notch developers in general." and "But I'm admittedly a few sigmas above average, so my experience is probably not typical." I strongly suggest you get off your high horse :) I also suggest that you read some of the Kent Beck books! Mainly on TDD, he also wrote the JUnit for Java. He considers himself as an average developer who follows good processes... perhaps you're above him as well.
    - SomeCallMeTim 10y ago
      >I strongly suggest you get off your high horse :) :P My "a few sigmas above average" comment was to just point out that I'm not typical. It's literally true, though. I really am that good. At least when I'm not writing comments on HN. ;) Relative to Kent Beck: I've never met him, much less worked with him. But being famous doesn't automatically make you a top 0.1% developer. A great manager and process person? Sure, I'd buy that, based on his books. But based on the relative skill of developers who I've encountered through my career, I'm at least top 1%, and maybe 0.1%. I've met hundreds of developers, and only a very few were in the same league. I did read Extreme Programming when it first came out. I actually feel that many of the practices in XP, including test-first and pair programming, are actually far more important for average to below-average developers. I think Kent Beck himself said that XP was best for broad-but-shallow problems (things like accounting software with a million simple rules). Broad-but-shallow just doesn't require the same strength of programmer to conquer -- though it does require good process, especially if your team size (and breadth) is large, which is Beck's strength.

aprdm 10y ago

TDD "got mainstream" with Java which is a compiled language. Therefore I don't think you're correct. It's usually the most simple functions that hide the most subtle bugs.

thatswrong0 10y ago
And subtle bugs often arise out of edge cases, and edge case issues aren't caught by most type systems.
SomeCallMeTim 10y ago
Really? I saw it mostly in the Ruby community first, followed by Python and JavaScript. Looking at the WikiPedia page, it looks like it came from Extreme Programming and the C3 project [1], which was SmallTalk. And in case you aren't sure, SmallTalk is dynamically typed. [2] Java has a huge enterprise presence as well, so I'm not too surprised that it's popular in Java circles. Enterprise developers aren't famously top-notch developers in general. >It's usually the most simple functions that hide the most subtle bugs. I can't remember the last time a type-checked simple function I wrote hid a subtle bug. But I'm admittedly a few sigmas above average, so my experience is probably not typical. In studies, TDD is a wash: It neither improves overall programmer throughput nor makes it worse. So use it if it's what makes you happy. I've used it for more complex goals myself, so I understand the draw. I just usually don't need it. [1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... [2] https://en.wikipedia.org/wiki/Smalltalk-80 https://en.wikipedia.org/wiki/Smalltalk-80
- aprdm 10y ago
  You're funny in the "Enterprise developers aren't famously top-notch developers in general." and "But I'm admittedly a few sigmas above average, so my experience is probably not typical." I strongly suggest you get off your high horse :) I also suggest that you read some of the Kent Beck books! Mainly on TDD, he also wrote the JUnit for Java. He considers himself as an average developer who follows good processes... perhaps you're above him as well.
  - SomeCallMeTim 10y ago
    >I strongly suggest you get off your high horse :) :P My "a few sigmas above average" comment was to just point out that I'm not typical. It's literally true, though. I really am that good. At least when I'm not writing comments on HN. ;) Relative to Kent Beck: I've never met him, much less worked with him. But being famous doesn't automatically make you a top 0.1% developer. A great manager and process person? Sure, I'd buy that, based on his books. But based on the relative skill of developers who I've encountered through my career, I'm at least top 1%, and maybe 0.1%. I've met hundreds of developers, and only a very few were in the same league. I did read Extreme Programming when it first came out. I actually feel that many of the practices in XP, including test-first and pair programming, are actually far more important for average to below-average developers. I think Kent Beck himself said that XP was best for broad-but-shallow problems (things like accounting software with a million simple rules). Broad-but-shallow just doesn't require the same strength of programmer to conquer -- though it does require good process, especially if your team size (and breadth) is large, which is Beck's strength.