3 ms·

Does your opinion only apply to unit testing or to automatic testing in general? I can't imagine the kind of software that wouldn't benefit from automatic test

by bhaak 5y ago

Does your opinion only apply to unit testing or to automatic testing in general? I can't imagine the kind of software that wouldn't benefit from automatic testing (unless you would be writing the simplest of CRUD web apps or doing it completely wrong). From personal experience I see both better code design from being forced to make the code testable and less bugs due to writing tests revealing bugs I wouldn't have found with manual testing before they go into production.

astrange 5y ago
> Does your opinion only apply to unit testing or to automatic testing in general? In my experience once people learn about tests, they want to see 1. tests per commit and 2. high code coverage. This leads to unit tests, which don't really test much of anything, and what they do test (the layers under you like the compiler) is by accident. The most useful testing would be integration tests on the side, and then regression tests because they're guaranteed to have already found at least one bug.
- sidlls 5y ago
  This, exactly.
spc476 5y ago
I agree, automatic testing would be nice. Unfortunately, I'm the one at work having to do write the said automatic testing of a component that makes parallel DNS requests [1] in an event driven server [2] and need to test that we cover the case where A returns, then B, and B returns, then A, A returns, B returns after our timeout [3], B returns, A returns after our timeout, A returns, B never does, B returns, A never does, while at the same time, making sure the ping tests (the components send a known query to each server to ensure each server is still available [4]) go through because if they don't that particular server will be taken out of rotation. God, I would love to have that automatically tested. What I don't like is having to automate such tests. [1] To different servers that return different information for a given query. The protocol happens to be DNS. [2] Based upon poll(), epoll() or kqueue(), depending upon the platform. [3] We're under some pretty tight time constraints for our product. [4] DNS, over UDP.

by bhaak 5y ago

astrange 5y ago

> Does your opinion only apply to unit testing or to automatic testing in general? In my experience once people learn about tests, they want to see 1. tests per commit and 2. high code coverage. This leads to unit tests, which don't really test much of anything, and what they do test (the layers under you like the compiler) is by accident. The most useful testing would be integration tests on the side, and then regression tests because they're guaranteed to have already found at least one bug.

sidlls 5y ago
This, exactly.

spc476 5y ago

I agree, automatic testing would be nice. Unfortunately, I'm the one at work having to do write the said automatic testing of a component that makes parallel DNS requests [1] in an event driven server [2] and need to test that we cover the case where A returns, then B, and B returns, then A, A returns, B returns after our timeout [3], B returns, A returns after our timeout, A returns, B never does, B returns, A never does, while at the same time, making sure the ping tests (the components send a known query to each server to ensure each server is still available [4]) go through because if they don't that particular server will be taken out of rotation. God, I would love to have that automatically tested. What I don't like is having to automate such tests. [1] To different servers that return different information for a given query. The protocol happens to be DNS. [2] Based upon poll(), epoll() or kqueue(), depending upon the platform. [3] We're under some pretty tight time constraints for our product. [4] DNS, over UDP.