4 ms·

Unit testing is a very very expensive operation. Consider the following: The developers add unit testing at beginning for specific results. Later on, after prod

by k2xl 14y ago

Unit testing is a very very expensive operation. Consider the following: The developers add unit testing at beginning for specific results. Later on, after product is released a new design or feature change happens. Often times unit tests will have to be rewritten else they will fail. This can be very expensive and take developers and QA engineers extra time when they try and figure out what's wrong... "Is the test failing because the test is out of date? Or is our program causing a bug?" I know for a fact HP deals with this issue constantly. Not saying unit testing is bad (I think it's usually good) but I don't think it's always good.

antrix 14y ago
> "Is the test failing because the test is out of date? Or is our program causing a bug?" IMO, when you change code (extensively), you'd still have to invariably answer those questions. But in the absence of tests, it becomes much harder to find the answers.
- justincormack 14y ago
  Indeed. The tests tell you that you are breaking a contract that you once thought was important. It might not be any more, but good tests reflect good contracts. Removing the test requires you to think whether any other code expects this contract.
jtreminio 14y ago
Lowly PHP dev here, so take my words with a grain of sakt, but if you go with TDD, any future refactoring should also follow TDD - write the test first (or modify existing tests) to what the expected behavior should be, then modify the actual app code.
ollysb 14y ago
Unit tests take a little time to write, sure. But look what you get for your investment: (for the sake of this discussion I'll avoid subjective issues such as improved design) 1) Faster feedback cycle - if you're developing new code you can run a single test and check inputs/outputs very quickly. If you're testing by refreshing a page, or shudder, restarting your java server, you're going to have to wait far longer to find out if your code changes work as expected. 2) Reduced risk when making changes to the code base - the risk increases the closer you get to your data store as the amount of dependent code increases. The only way to reduce risk without unit tests in place is to not change any code i.e. you have to keep building on top (see the open/closed principle). This inevitably means that your code is going to introduce duplication as you can't refactor it out where appropriate. The other option of course is that you just risk it and hope to god that your manual QA testing will catch any problems before your users do. It's also worth noting that the cost of adding unit tests isn't fixed, it's dependent on a) experience b) the tooling available for your language From personal experience I find adding unit tests in ruby takes very little time. This means that benefit 1 in particular kicks in far sooner. Currently I feel it's faster for me to write a piece of code with a unit test than without.
bryanlarsen 14y ago
That's the major problem with system tests, but it shouldn't be a big problem for unit tests. In my experience system tests are so fragile that the cost of upkeep is larger than the benefit gained except in a few cases. Unit tests on the other hand are much more stable.
- rwallace 14y ago
  My experience is precisely the reverse. System tests are stable because they only need to change when the observable behavior of the entire system changes. Unit tests are intimately coupled to the internal structure, so if you use them, you have to change them every time you refactor so much as a single function.

by k2xl 14y ago

antrix 14y ago

> "Is the test failing because the test is out of date? Or is our program causing a bug?" IMO, when you change code (extensively), you'd still have to invariably answer those questions. But in the absence of tests, it becomes much harder to find the answers.

justincormack 14y ago
Indeed. The tests tell you that you are breaking a contract that you once thought was important. It might not be any more, but good tests reflect good contracts. Removing the test requires you to think whether any other code expects this contract.

jtreminio 14y ago

Lowly PHP dev here, so take my words with a grain of sakt, but if you go with TDD, any future refactoring should also follow TDD - write the test first (or modify existing tests) to what the expected behavior should be, then modify the actual app code.

ollysb 14y ago

Unit tests take a little time to write, sure. But look what you get for your investment: (for the sake of this discussion I'll avoid subjective issues such as improved design) 1) Faster feedback cycle - if you're developing new code you can run a single test and check inputs/outputs very quickly. If you're testing by refreshing a page, or shudder, restarting your java server, you're going to have to wait far longer to find out if your code changes work as expected. 2) Reduced risk when making changes to the code base - the risk increases the closer you get to your data store as the amount of dependent code increases. The only way to reduce risk without unit tests in place is to not change any code i.e. you have to keep building on top (see the open/closed principle). This inevitably means that your code is going to introduce duplication as you can't refactor it out where appropriate. The other option of course is that you just risk it and hope to god that your manual QA testing will catch any problems before your users do. It's also worth noting that the cost of adding unit tests isn't fixed, it's dependent on a) experience b) the tooling available for your language From personal experience I find adding unit tests in ruby takes very little time. This means that benefit 1 in particular kicks in far sooner. Currently I feel it's faster for me to write a piece of code with a unit test than without.

bryanlarsen 14y ago

That's the major problem with system tests, but it shouldn't be a big problem for unit tests. In my experience system tests are so fragile that the cost of upkeep is larger than the benefit gained except in a few cases. Unit tests on the other hand are much more stable.

rwallace 14y ago
My experience is precisely the reverse. System tests are stable because they only need to change when the observable behavior of the entire system changes. Unit tests are intimately coupled to the internal structure, so if you use them, you have to change them every time you refactor so much as a single function.