4 ms·

Usually I feel like the only person who doesn't unit test. I've heard all of the arguments and I like the theory, but practically I don't want to spend the tim

Usually I feel like the only person who doesn't unit test. I've heard all of the arguments and I like the theory, but practically I don't want to spend the time on it, and I maintain a large codebase. Regressions are easily spotted and corrected in a well structured code base. Could occational bugs be spotted before production with unit tests? Sure! But it isn't worth the time in my case.

capitalsigma 9y ago
How do you catch a regression without tests? Do you wait until it launches and crashes in production?
- jacob019 9y ago
  No unit tests. With good code structure regressions are minimal, most are caught with practical testing. Ocationally one slips through to production, is reported, and quickly patched. It's rare and something that I'm sure happens to everyone, even with unit tests. I don't tell people to do it my way, but it works for me and my company.
  - capitalsigma 9y ago
    What is a "practical test"?
    - jacob019 9y ago
      I just mean a manual test of application functionality. Maybe some manual function calls. Nothing automated or saved. BTW, the code is an ecommerce platform, not just a website but dozens of integrated applications that handle everything from product selection to order fulfillment, and everything inbetween. 11 years of code that dozens of people use daily to process hundreds of thousands of orders per year.
- deleted 9y ago
  [deleted]
valuearb 9y ago
I’ve tried to write unit tests. They just haven’t been worth the effort. 1) It takes more time. 2) In any complex application, unit testing requires creating mocks to separate the code you are testing from live subsystems. 3) That requires modifying your production code to be easily mockable in ways that don’t benefit the production code base. 4) Unit tests are by default artificial. They don’t test real world usage. 5) As you refactor production code, you have to rewrite unit tests, adding more overhead. A far better way to write tests is within your production code. Validate every parameter and every assumption. Raise errors when possible, log everything else. This is far easier to develop, and maintain. It runs when you testers, and customers use the applications. Now I write desktop and mobile apps. If I wrote APIs and servers unit tests would become far more useful. But on device most of my problems can only be caught by integration tests, not unit tests.
- zo7 9y ago
  > A far better way to write tests is within your production code. Validate every parameter and every assumption. Raise errors when possible, log everything else. > It runs when you testers, and customers use the applications. Do you rely on any sort of automated testing to catch errors before it gets to your customers? From a business standpoint it doesn't feel right to offload testing to your users, especially in more critical systems.
  - valuearb 9y ago
    Our testing is by hand, we have a QA lead and entire team helps. Verification isn’t offloading testing, it’s monotoring real world usage to find out where it differs from testing. The hard part is the logs can be a torrent of data, you need to have a process to monitor and escalate. i’d like to automate testing. But it has to be no more work than manual testing, and/or it has to be as effective or better than manual testing. And i can’t see either of those being true. Most of my bugs can’t be caught by unit tests. For example one common category is where previous devs made assumptions where code normally works fine, but fails in specific edge cases from multiple thread timing or view controllers being disposed. i don’t know how to automate those tests.
psyc 9y ago
You're not the only one, but it can be an unpopular opinion. Of course we wrote very large code bases with no unit tests for decades, before it became a blessed cult of sorts. I know when I've written a method that's so inherently tricky, that I need a unit test for peace of mind. It's rare, and I prefer not to write tricky methods, or complicated architectures. This is practically impossible to avoid on a large team of mixed skill and weak leadership. I prefer not to work on teams like that.

capitalsigma 9y ago

How do you catch a regression without tests? Do you wait until it launches and crashes in production?

jacob019 9y ago
No unit tests. With good code structure regressions are minimal, most are caught with practical testing. Ocationally one slips through to production, is reported, and quickly patched. It's rare and something that I'm sure happens to everyone, even with unit tests. I don't tell people to do it my way, but it works for me and my company.
- capitalsigma 9y ago
  What is a "practical test"?
  - jacob019 9y ago
    I just mean a manual test of application functionality. Maybe some manual function calls. Nothing automated or saved. BTW, the code is an ecommerce platform, not just a website but dozens of integrated applications that handle everything from product selection to order fulfillment, and everything inbetween. 11 years of code that dozens of people use daily to process hundreds of thousands of orders per year.
deleted 9y ago
[deleted]

valuearb 9y ago

I’ve tried to write unit tests. They just haven’t been worth the effort. 1) It takes more time. 2) In any complex application, unit testing requires creating mocks to separate the code you are testing from live subsystems. 3) That requires modifying your production code to be easily mockable in ways that don’t benefit the production code base. 4) Unit tests are by default artificial. They don’t test real world usage. 5) As you refactor production code, you have to rewrite unit tests, adding more overhead. A far better way to write tests is within your production code. Validate every parameter and every assumption. Raise errors when possible, log everything else. This is far easier to develop, and maintain. It runs when you testers, and customers use the applications. Now I write desktop and mobile apps. If I wrote APIs and servers unit tests would become far more useful. But on device most of my problems can only be caught by integration tests, not unit tests.

zo7 9y ago
> A far better way to write tests is within your production code. Validate every parameter and every assumption. Raise errors when possible, log everything else. > It runs when you testers, and customers use the applications. Do you rely on any sort of automated testing to catch errors before it gets to your customers? From a business standpoint it doesn't feel right to offload testing to your users, especially in more critical systems.
- valuearb 9y ago
  Our testing is by hand, we have a QA lead and entire team helps. Verification isn’t offloading testing, it’s monotoring real world usage to find out where it differs from testing. The hard part is the logs can be a torrent of data, you need to have a process to monitor and escalate. i’d like to automate testing. But it has to be no more work than manual testing, and/or it has to be as effective or better than manual testing. And i can’t see either of those being true. Most of my bugs can’t be caught by unit tests. For example one common category is where previous devs made assumptions where code normally works fine, but fails in specific edge cases from multiple thread timing or view controllers being disposed. i don’t know how to automate those tests.

psyc 9y ago

You're not the only one, but it can be an unpopular opinion. Of course we wrote very large code bases with no unit tests for decades, before it became a blessed cult of sorts. I know when I've written a method that's so inherently tricky, that I need a unit test for peace of mind. It's rare, and I prefer not to write tricky methods, or complicated architectures. This is practically impossible to avoid on a large team of mixed skill and weak leadership. I prefer not to work on teams like that.