5 ms·

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. This is an inte

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. This is an interesting one. I first took it to mean 'current testing practices are inadequate', which isn't an extreme opinion, and one I bet 99% of HN agrees with. It's 'common wisdom' that teams should be doing more testing, TDD, etc. But now that I read it again, it's specifically saying that current testing practices are 'ineffective', not 'inadequate', which would indicate we should be doing less or even none of it. 'ineffective' to me means worse than nothing, since testing, like anything, has a cost. (time wasted, more code to maintain, lower morale etc) I'm not sure which the author meant. But I do think the latter is a hot take, and I get the feeling I'm in the minority in agreeing with it. I'm reminded of this PG quote (obviously written a while ago): "Indeed, these statistics about Cobol or Java being the most popular language can be misleading. What we ought to look at, if we want to know what tools are best, is what hackers choose when they can choose freely-- that is, in projects of their own. When you ask that question, you find that open source operating systems already have a dominant market share, and the number one language is probably Perl." If I think about what I've written unit tests for at home, that'd be a bunch of maths-y stuff that I was having trouble debugging, and a few functions here and there that I consider 'tricky' and want a bit of extra peace of mind for. When I'm building web apps at home though, like I always do at work, how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is and what manual testing or browser testing I need to do to clarify it. If anyone on my team at work ever said that, everyone would look at them like they just took a shit on the carpet (including me, because I'm happy to smile and nod for the right salary). Then there's this, from the same essay: "One difference I've noticed between great hackers and smart people in general is that hackers are more politically incorrect. To the extent there is a secret handshake among good hackers, it's when they know one another well enough to express opinions that would get them stoned to death by the general public. And I can see why political incorrectness would be a useful quality in programming. Programs are very complex and, at least in the hands of good programmers, very fluid. In such situations it's helpful to have a habit of questioning assumptions." I definitely know a few coders I've worked with who I'd be comfortable raising my views on testing with. We might differ on the details (I quite like browser tests, don't find a lot of value in snapshot testing most of the time, we might unit test a different tiny subset of the app etc), but by and large we'd agree that most common testing is a crock. And coincidentally, they're all the devs that I think write fantastic code, and that I'd happily build a startup with. Anyway, that's my Thing I Believe About Software Engineering, with a bit more clarification than OP's ones.

skolsuper 7y ago
High test coverage is mainly useful for code that will be worked on by more than one person, so it makes sense that you wouldn't want to add it to your personal projects. Doesn't mean it's not worthwhile.
- bluGill 7y ago
  High test coverage is also more important for large projects than small, even when working alone. I never write unit tests for hello world - it would be a waste of time. I will write tests when I'm hacking on a large project even if I'm alone because I know eventually I will make a change that breaks something that used to work.
clappski 7y ago
> how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is Surely if you were, for example, writing an automated trading system, or something that handles money, or anything that actually impacts the running of a business in a bigger way than the website being down you would see the value in writing tests, right? Even in the situation that the website is the product, don't you see the value of having tests to make sure that future changes don't break existing behavior without having to run through an exponentially expanding manual test regime? For me tests are about catching regressions and verifying behavior, e.g.; * I can visually see by reading the code that if someone submits an order that breaches a risk limit, it's rejected. Still, I wouldn't feel comfortable letting that system trade until I had verified with both a unit test that handles the generic 'reject a number > risk limit' _and_ an integration test that verifies 'I send N different types of orders into the system, where N/2 are above the risk limit. Which orders pass the risk check?' * I've done some refactoring to some low level connection logic to handle some rare condition that last happened on Friday at 2300. I wouldn't release the code with the refactoring until I can verify with a test that both the new condition is handled, and all of expected unchanged behavior is unchanged. Without a test suite, I would have to spend a day setting up environments and testing each invariant, which is a waste of time for something that I can automate and have more confidence in. Also, without a test suite, how would I know that a change in the future wouldn't result in me having to come online at 2300 on a Friday because of a regression that someone didn't catch in their manual testing? * Someone has submitted a PR that modifies how often our log files get rolled - without a test suite to verify the failure modes, I would never let that get to production. Why would I want to risk losing log files, at the cost of spending 30 minutes writing a test for the failure modes (at least, the ones I know about, which is still better than none because testing isn't a zero-sum game)? Having the "it's going to fail anyway, and I already know where" attitude is a terrible way to approach risk management (which is, ultimately, what testing represents) IMO. It might be fine in certain domains, but in others its a quick way to tank a company. I definitely agree that it's not worth testing everything (e.g. CI scripts - if they work, they work!), but for actual business logic or infrastructure not writing tests is straight up negligent. Even if you're certain that the code does what it says and you can keep all of the failure modes in your head at once as you make changes, I guarantee that someone else on your team (this could be you in six months) doesn't, or can't.

skolsuper 7y ago

High test coverage is mainly useful for code that will be worked on by more than one person, so it makes sense that you wouldn't want to add it to your personal projects. Doesn't mean it's not worthwhile.

bluGill 7y ago
High test coverage is also more important for large projects than small, even when working alone. I never write unit tests for hello world - it would be a waste of time. I will write tests when I'm hacking on a large project even if I'm alone because I know eventually I will make a change that breaks something that used to work.

clappski 7y ago

> how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is Surely if you were, for example, writing an automated trading system, or something that handles money, or anything that actually impacts the running of a business in a bigger way than the website being down you would see the value in writing tests, right? Even in the situation that the website is the product, don't you see the value of having tests to make sure that future changes don't break existing behavior without having to run through an exponentially expanding manual test regime? For me tests are about catching regressions and verifying behavior, e.g.; * I can visually see by reading the code that if someone submits an order that breaches a risk limit, it's rejected. Still, I wouldn't feel comfortable letting that system trade until I had verified with both a unit test that handles the generic 'reject a number > risk limit' _and_ an integration test that verifies 'I send N different types of orders into the system, where N/2 are above the risk limit. Which orders pass the risk check?' * I've done some refactoring to some low level connection logic to handle some rare condition that last happened on Friday at 2300. I wouldn't release the code with the refactoring until I can verify with a test that both the new condition is handled, and all of expected unchanged behavior is unchanged. Without a test suite, I would have to spend a day setting up environments and testing each invariant, which is a waste of time for something that I can automate and have more confidence in. Also, without a test suite, how would I know that a change in the future wouldn't result in me having to come online at 2300 on a Friday because of a regression that someone didn't catch in their manual testing? * Someone has submitted a PR that modifies how often our log files get rolled - without a test suite to verify the failure modes, I would never let that get to production. Why would I want to risk losing log files, at the cost of spending 30 minutes writing a test for the failure modes (at least, the ones I know about, which is still better than none because testing isn't a zero-sum game)? Having the "it's going to fail anyway, and I already know where" attitude is a terrible way to approach risk management (which is, ultimately, what testing represents) IMO. It might be fine in certain domains, but in others its a quick way to tank a company. I definitely agree that it's not worth testing everything (e.g. CI scripts - if they work, they work!), but for actual business logic or infrastructure not writing tests is straight up negligent. Even if you're certain that the code does what it says and you can keep all of the failure modes in your head at once as you make changes, I guarantee that someone else on your team (this could be you in six months) doesn't, or can't.