4 ms·

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

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.

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.