4 ms·

The focus on automated unit/integrations tests is a relatively modern thing (late 90's?). There was some pretty large and extremely reliable software shipped be

by YZF 2y ago

The focus on automated unit/integrations tests is a relatively modern thing (late 90's?). There was some pretty large and extremely reliable software shipped before that focus. Random example is that the Linux kernel didn't have much tests (I think these days there is more testing). Unix likely didn't have a lot of "tests". Compilers tended to have them. Operating systems less so. Games (e.g. I'm sure Doom) didn't tend to have tests. You need to find a balance point. I think we know that (some) automated tests (unit, integration, end to end) can help build quality software. We also know good tests aren't always easy to write, bad tests make for harder refactoring and flaky tests can suck a lot of time on large projects. At the same time it's always interesting to try different things and find out what works, especially for you if you're a solo developers.

amluto 2y ago
> Random example is that the Linux kernel didn't have much tests (I think these days there is more testing). As the author of many of Linux’s x86 tests: many of those tests would fail on old kernels, and a decent number of those failures are related to very severe bugs. Linux has worked well for many years, but working well didn’t mean it wasn’t buggy.
- YZF 2y ago
  As was said in another comment, tests don't prove the lack of bugs. There is no software of enough complexity without bugs. Working is something ;) Lots of software barely does that and there is certainly plenty of software with tests that doesn't meet the no-test Linux quality bar. That said, tests certainly have their place in the world of software quality, so thanks for your work!
galaxyLogic 2y ago
"Unit-Testing" became popular about the time of Extreme Programming. The reason I think it became so popular was that its proponents programmed in dynamically typed languages like Smalltalk, and later JavaScript. It seems to me that synamic languages needs testing more than statically typed ones.
- Jtsummers 2y ago
  Beck's first xUnit framework was SUnit, for Smalltalk, but Beck's second take was JUnit, which is for Java. Java was and still is a statically typed language. Tests are there to detect logical correctness of the unit under test, very few type systems can catch errors like using - instead of + in a mathematical formula, for instance. You either need to go into dependently typed languages or languages that otherwise permit embedding proofs (SPARK/Ada).
  - YZF 2y ago
    In dynamic languages tests also tend to fill the role of the compiler is I think the parent's point. Dynamic/interpreted language code might have syntax errors or be otherwise incorrect (including type errors) and you often don't find those until they code is run.
    - dgb23 2y ago
      That’s a fair point. However dynamic languages tend to have very good linting that catch many basic type errors. They can also run way more often during development, down to the function/expression level.
    - igouy 2y ago
      When this buggy method is compiled (not run) with Smalltalk, errors and warnings are shown. The code cannot be run because it failed to compile. hnQuestion | list max | list := #(1 8 4 5 3). ! Syntax Error: Nothing more expected 1 to: list size do: [:i | max < (list at: i) ? Uses ifTrue:/ifFalse: instead of min: or max: ifTrue: [max := (list at: i)]. ifFalse: [max := max]. ].
      - Izkata 2y ago
        For future reference, indent with 2 spaces to get code formatting. https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc
dgb23 2y ago
My old man who will always gladly mention that „we did this already in the 80‘s and it was called frobniz“ whenever I bring up a technique, architecture etc. would beg to differ. When I asked him about TDD he said they did practically the same thing. Forgot how it was called though. One recent gem was when he shared a video where they explained the recent crowdstrike debacle: „Look they’re making the same mistakes as 40 years ago. I remember when we dynamically patched a kernel and it exploded haha…“. In any case, writing tests before writing the implementation was a thing during the 80‘s as well for certain projects.
RandomThoughts3 2y ago
Most video games have a full team of QA testers doing functional testing on the games as they go along. Same thing for the kernel, plus some versions are fully certified for various contexts so you can be sure fully formalised tests suites exists. And that’s on top of all the testing tools which are provided (Kunit, tests from user spaces, an array of dynamic and static testing tools). But I would like to thank all the people here who think testing is useless for their attitude. You make my job easier while hiring.
- scarygliders 2y ago
  > But I would like to thank all the people here who think testing is useless for their attitude. You make my job easier while hiring. That's fine. I've never written a test in my life. Have my programs ever had bugs? Sure. But I sleep very well at night knowing that I spent all my brain power and time writing actual code that Does Useful Work rather than have wasted significant lengths of my time on this planet on writing test code to test the code that does the Useful Work. You speak of attitude and smugly "thank" those who don't write tests as that acts as your hire-or-not filter. With an attitude like that, I'd 100% not work for anyone with that attitude anyway.
  - RandomThoughts3 2y ago
    > I've never written a test in my life. Have my programs ever had bugs? Sure. But I sleep very well at night knowing that I spent all my brain power and time writing actual code that Does Useful Work rather than have wasted significant lengths of my time on this planet on writing test code to test the code that does the Useful Work. And that’s why I never want to have to work with you on anything shipping to a user ever. Don’t get me wrong, the field is riddled with people who think testing is beside them and wash their hand with the quality of what they ship and what they put their users through. That’s an issue to fix not a situation we should tolerate.
    - scarygliders 2y ago
      > Don’t get me wrong, the field is riddled with people who think testing is beside them and wash their hand with the quality of what they ship and what they put their users through. That’s an issue to fix not a situation we should tolerate. See, this is my point. It's not that testing is beside me, it's that my stuff gets tested anyway. Here's the test: Does it fucking work or not? You do that by running the thing. If it explodes, find out why and fix it. Job done. No thought or line of code was wasted in writing tests, all brain power was used to initially write a piece of code - which initially had a bug of course - and then said bug was fixed. My code gets tested. By people using it. Or by me testing it as I write it ("does it fucking work"). There is really only one test. You can choose to expend your brainpower and time on this planet writing code that will never actually be run by an end-user, or you can just write the fucking code that the end-user will run. That's how I work. Write it and run it. That's the test. Test code written to test Useful Working Code is time wasted. It's like putting stabiliser wheels on bicycles - you're either gonna be stuck forever riding a bike with stabilisers, or you grow up and rip them off and have a few falls on the bike then become confident and competent enough to ride that bike without them. And have more freedom and time to experiment and go places you couldn't when they were put on. So yeah. I definitely wouldn't work with people who like wasting my and their time on this Earth. Write it. Run it. It either does what it's supposed to or not. If it doesn't, find out why and fix it. Or discover that your function/code abstraction/thought was shit in the first place then write it differently - oh and that's the worst part about writing code that tests the Code That Does The Work; say you discover that the function you're writing was a load of bollocks and needs to be highlighted and simply erased - there goes all that test code you spent brainpower and time, with it, too. And now you have to spend even more time writing new test code to test the Code That Actually Does Useful Work. No thanks. And goodbye.
Ma8ee 2y ago
Of course there were tests, just not automated tests! In better run organisations they had test protocols, that is, long lists of tests that had to be run by manual testers before any new version could be released. Your manager had to make sure these testers were scheduled well in advance before the bi-annual release date of your latest version of the software. So that listing old software and claim that they didn't have much tests is misleading, to say the least.
- YZF 2y ago
  I am talking specifically about automated tests. > automated unit/integrations tests Since that's what the blog is talking about. Formalized manual testing is a different topic, that also didn't universally exist in the 70's and 80's.
  - Ma8ee 2y ago
    Yes, but your comment gave the impression that you could create quality software without testing. No one is going to interpret your comment as a call for replacing automated tests with manual tests, but many might read it as “testing in itself isn’t very important.”

by YZF 2y ago

amluto 2y ago

> Random example is that the Linux kernel didn't have much tests (I think these days there is more testing). As the author of many of Linux’s x86 tests: many of those tests would fail on old kernels, and a decent number of those failures are related to very severe bugs. Linux has worked well for many years, but working well didn’t mean it wasn’t buggy.

YZF 2y ago
As was said in another comment, tests don't prove the lack of bugs. There is no software of enough complexity without bugs. Working is something ;) Lots of software barely does that and there is certainly plenty of software with tests that doesn't meet the no-test Linux quality bar. That said, tests certainly have their place in the world of software quality, so thanks for your work!

galaxyLogic 2y ago

"Unit-Testing" became popular about the time of Extreme Programming. The reason I think it became so popular was that its proponents programmed in dynamically typed languages like Smalltalk, and later JavaScript. It seems to me that synamic languages needs testing more than statically typed ones.

Jtsummers 2y ago
Beck's first xUnit framework was SUnit, for Smalltalk, but Beck's second take was JUnit, which is for Java. Java was and still is a statically typed language. Tests are there to detect logical correctness of the unit under test, very few type systems can catch errors like using - instead of + in a mathematical formula, for instance. You either need to go into dependently typed languages or languages that otherwise permit embedding proofs (SPARK/Ada).
- YZF 2y ago
  In dynamic languages tests also tend to fill the role of the compiler is I think the parent's point. Dynamic/interpreted language code might have syntax errors or be otherwise incorrect (including type errors) and you often don't find those until they code is run.
  - dgb23 2y ago
    That’s a fair point. However dynamic languages tend to have very good linting that catch many basic type errors. They can also run way more often during development, down to the function/expression level.
  - igouy 2y ago
    When this buggy method is compiled (not run) with Smalltalk, errors and warnings are shown. The code cannot be run because it failed to compile. hnQuestion | list max | list := #(1 8 4 5 3). ! Syntax Error: Nothing more expected 1 to: list size do: [:i | max < (list at: i) ? Uses ifTrue:/ifFalse: instead of min: or max: ifTrue: [max := (list at: i)]. ifFalse: [max := max]. ].
    - Izkata 2y ago
      For future reference, indent with 2 spaces to get code formatting. https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc

dgb23 2y ago

My old man who will always gladly mention that „we did this already in the 80‘s and it was called frobniz“ whenever I bring up a technique, architecture etc. would beg to differ. When I asked him about TDD he said they did practically the same thing. Forgot how it was called though. One recent gem was when he shared a video where they explained the recent crowdstrike debacle: „Look they’re making the same mistakes as 40 years ago. I remember when we dynamically patched a kernel and it exploded haha…“. In any case, writing tests before writing the implementation was a thing during the 80‘s as well for certain projects.

RandomThoughts3 2y ago

Most video games have a full team of QA testers doing functional testing on the games as they go along. Same thing for the kernel, plus some versions are fully certified for various contexts so you can be sure fully formalised tests suites exists. And that’s on top of all the testing tools which are provided (Kunit, tests from user spaces, an array of dynamic and static testing tools). But I would like to thank all the people here who think testing is useless for their attitude. You make my job easier while hiring.

scarygliders 2y ago
> But I would like to thank all the people here who think testing is useless for their attitude. You make my job easier while hiring. That's fine. I've never written a test in my life. Have my programs ever had bugs? Sure. But I sleep very well at night knowing that I spent all my brain power and time writing actual code that Does Useful Work rather than have wasted significant lengths of my time on this planet on writing test code to test the code that does the Useful Work. You speak of attitude and smugly "thank" those who don't write tests as that acts as your hire-or-not filter. With an attitude like that, I'd 100% not work for anyone with that attitude anyway.
- RandomThoughts3 2y ago
  > I've never written a test in my life. Have my programs ever had bugs? Sure. But I sleep very well at night knowing that I spent all my brain power and time writing actual code that Does Useful Work rather than have wasted significant lengths of my time on this planet on writing test code to test the code that does the Useful Work. And that’s why I never want to have to work with you on anything shipping to a user ever. Don’t get me wrong, the field is riddled with people who think testing is beside them and wash their hand with the quality of what they ship and what they put their users through. That’s an issue to fix not a situation we should tolerate.
  - scarygliders 2y ago
    > Don’t get me wrong, the field is riddled with people who think testing is beside them and wash their hand with the quality of what they ship and what they put their users through. That’s an issue to fix not a situation we should tolerate. See, this is my point. It's not that testing is beside me, it's that my stuff gets tested anyway. Here's the test: Does it fucking work or not? You do that by running the thing. If it explodes, find out why and fix it. Job done. No thought or line of code was wasted in writing tests, all brain power was used to initially write a piece of code - which initially had a bug of course - and then said bug was fixed. My code gets tested. By people using it. Or by me testing it as I write it ("does it fucking work"). There is really only one test. You can choose to expend your brainpower and time on this planet writing code that will never actually be run by an end-user, or you can just write the fucking code that the end-user will run. That's how I work. Write it and run it. That's the test. Test code written to test Useful Working Code is time wasted. It's like putting stabiliser wheels on bicycles - you're either gonna be stuck forever riding a bike with stabilisers, or you grow up and rip them off and have a few falls on the bike then become confident and competent enough to ride that bike without them. And have more freedom and time to experiment and go places you couldn't when they were put on. So yeah. I definitely wouldn't work with people who like wasting my and their time on this Earth. Write it. Run it. It either does what it's supposed to or not. If it doesn't, find out why and fix it. Or discover that your function/code abstraction/thought was shit in the first place then write it differently - oh and that's the worst part about writing code that tests the Code That Does The Work; say you discover that the function you're writing was a load of bollocks and needs to be highlighted and simply erased - there goes all that test code you spent brainpower and time, with it, too. And now you have to spend even more time writing new test code to test the Code That Actually Does Useful Work. No thanks. And goodbye.

Ma8ee 2y ago

Of course there were tests, just not automated tests! In better run organisations they had test protocols, that is, long lists of tests that had to be run by manual testers before any new version could be released. Your manager had to make sure these testers were scheduled well in advance before the bi-annual release date of your latest version of the software. So that listing old software and claim that they didn't have much tests is misleading, to say the least.

YZF 2y ago
I am talking specifically about automated tests. > automated unit/integrations tests Since that's what the blog is talking about. Formalized manual testing is a different topic, that also didn't universally exist in the 70's and 80's.
- Ma8ee 2y ago
  Yes, but your comment gave the impression that you could create quality software without testing. No one is going to interpret your comment as a call for replacing automated tests with manual tests, but many might read it as “testing in itself isn’t very important.”