5 ms·

"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over tes

"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my personal experience but in general it seems to be true for teams). But you'll plateau quickly and then at iteration 1+n you'll just come to a screeching halt because you introduce bugs or the new engineer isn't confident that they didn't break downstream things and needs to manually test everything. Testing early will cause you to go slower earlier (again, not my personal experience but seems to be generally true of teams) but you'll be significantly faster at iteration 1+n. I usually summarize this as: testing early will on average make your development faster over the life of your codebase. Knowing this you can make trade-offs. Not testing early is probably better called prototyping. It's OK to prototype in production if you need to. But know what you're getting yourself into.

codeulike 7y ago
> how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? Because software development did exist before the invention of JUnit et al. The old fashioned way is 'user acceptance tests' and of course thats not perfect but its easily understandable, and nearly anyone can sit there and do it. And they might miss things or whatever yadda yadda but at the end of the day in an environment where everyone is short of time and time is money a bit of user testing can often be 'good enough'.
- lukejduncan 7y ago
  I’m not saying you need 100% code coverage, or 80%. Just some level of deliberate automation. In my personal experience, user testing as your only or primary form of testing gets painful fast.
arvinsim 7y ago
There are some programs that are not designed to last. It doesn't make sense to put in time in that regard.
noobiemcfoob 7y ago
A workflow using the code is a itself a type of test. If something breaks, the users will tell you. A lot of code ends up in that space because it was never asked for as an actual project, but now a team relies on it but no developer can be officially assigned to it.
- colpabar 7y ago
  "I don't always test my code, but when I do, I do it in production."
scarface74 7y ago
You are making the assumption that most people care about n+1 where the code gets so bad it’s hard to maintain. - the average tenure for a software developer at a company is 1.5 - 3 years, by the time things get that bad, its someone else’s problem. - the business folks at a startup just care about throwing something together long enough to get their next round of funding or the exit. - no one gets promoted by having code that is easy to maintain over the long term. They get promoted by releasing the new and shiny - not maintenance work. See Google.
jayd16 7y ago
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing. I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests. Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.
- ramraj07 7y ago
  I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.
  - gonzo41 7y ago
    Depends on how you define a unit and what you're willing to mock. I treat a 'unit' as a piece of functionality. So one method on an API is a unit. if it does complex stuff then there may be more targeted tests down below. and depending on what sort of work it does i may not bother with unit tests because mocking a DB transaction isn't worth it. In java land when I'm writing stuff i use unit tests mostly as a place where i can run code without having to compile the whole app. And any tests that come out of it just end up being a bit of regression protection. But there's always a bigger slightly more complex unit test i write which tests the bigger unit of function. And those really straddle the line between unit and integration testing but i find i get the most value from them because one you lock in and publish functionality you have a contract you have to honor.
silveroriole 7y ago
Having lived through the screeching halt, I agree. There reaches a point where you genuinely cannot make a change without breaking something on the live system, or taking five times as long as is reasonable. You no longer have any idea what the real behaviour of the system or why (doco is NEVER up to date). Not having tests was part of the reason I changed jobs. I don’t know why people assume that tests hold you back from changes. If they do, they were just bad tests which were testing implementation details rather than businsss logic. That’s an argument to not write useless/stupid tests, not an argument to not write any tests at all. It just seems to be far more difficult for developers to decide what a good test should look like than to decide what any other good code should look like.

codeulike 7y ago

> how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? Because software development did exist before the invention of JUnit et al. The old fashioned way is 'user acceptance tests' and of course thats not perfect but its easily understandable, and nearly anyone can sit there and do it. And they might miss things or whatever yadda yadda but at the end of the day in an environment where everyone is short of time and time is money a bit of user testing can often be 'good enough'.

lukejduncan 7y ago
I’m not saying you need 100% code coverage, or 80%. Just some level of deliberate automation. In my personal experience, user testing as your only or primary form of testing gets painful fast.

arvinsim 7y ago

There are some programs that are not designed to last. It doesn't make sense to put in time in that regard.

noobiemcfoob 7y ago

A workflow using the code is a itself a type of test. If something breaks, the users will tell you. A lot of code ends up in that space because it was never asked for as an actual project, but now a team relies on it but no developer can be officially assigned to it.

colpabar 7y ago
"I don't always test my code, but when I do, I do it in production."

scarface74 7y ago

You are making the assumption that most people care about n+1 where the code gets so bad it’s hard to maintain. - the average tenure for a software developer at a company is 1.5 - 3 years, by the time things get that bad, its someone else’s problem. - the business folks at a startup just care about throwing something together long enough to get their next round of funding or the exit. - no one gets promoted by having code that is easy to maintain over the long term. They get promoted by releasing the new and shiny - not maintenance work. See Google.

jayd16 7y ago

Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing. I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests. Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.

ramraj07 7y ago
I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.
- gonzo41 7y ago
  Depends on how you define a unit and what you're willing to mock. I treat a 'unit' as a piece of functionality. So one method on an API is a unit. if it does complex stuff then there may be more targeted tests down below. and depending on what sort of work it does i may not bother with unit tests because mocking a DB transaction isn't worth it. In java land when I'm writing stuff i use unit tests mostly as a place where i can run code without having to compile the whole app. And any tests that come out of it just end up being a bit of regression protection. But there's always a bigger slightly more complex unit test i write which tests the bigger unit of function. And those really straddle the line between unit and integration testing but i find i get the most value from them because one you lock in and publish functionality you have a contract you have to honor.

silveroriole 7y ago

Having lived through the screeching halt, I agree. There reaches a point where you genuinely cannot make a change without breaking something on the live system, or taking five times as long as is reasonable. You no longer have any idea what the real behaviour of the system or why (doco is NEVER up to date). Not having tests was part of the reason I changed jobs. I don’t know why people assume that tests hold you back from changes. If they do, they were just bad tests which were testing implementation details rather than businsss logic. That’s an argument to not write useless/stupid tests, not an argument to not write any tests at all. It just seems to be far more difficult for developers to decide what a good test should look like than to decide what any other good code should look like.