4 ms·

If your requirement changes so that the price break is at 11 rather than 10, then I expect the process to go: * Change the (or shared test code) that has the p

If your requirement changes so that the price break is at 11 rather than 10, then I expect the process to go: * Change the (or shared test code) that has the price break specification from 10 to 11 * Run it, see the failures * Update the source code appropriately The updated source code is the same in both our cases. In my case the changed test code is testing the ShoppingCart interface and in yours it's a unit test of something lower down. There's not extra cost, it's just in a different place. Or are you suggesting that your tests don't know about 10 vs 11 at all? There's a reasonable architecture where such data comes from outside your system, and the spec for your system is 'price breaks should reflect this data input' and then you mock that data input and test it, but that's a different thing.

bluGill 6y ago
I'm saying the discount code tests have the change from 10 to 11. this entire thread isn't about the discount code tests though it is about the shopping cart. There is a lot more to calculating price than just discount codes, tax rates for example. The cart needs to show regular price, the discount, the tax, shipping costs, and then total. Each of those is tested for multiple edge cases, so if we do it all in the shopping carts there are potentially hundreds of unrelated tests that need to change when the discount factor changes just because they happen to check the total.
- rkangel 6y ago
  What it does is show up something that is true anyway for unit tests: automated tests are software and they should be designed like it. It might affect multiple tests, but all you should have to change is one or two places in some shared code pulled in by those tests. Too many tests have too much repeated code, and so become expensive to maintain, exactly like normal code. Refactor, think about shared functions etc. exactly as you would do with your production code.

bluGill 6y ago

I'm saying the discount code tests have the change from 10 to 11. this entire thread isn't about the discount code tests though it is about the shopping cart. There is a lot more to calculating price than just discount codes, tax rates for example. The cart needs to show regular price, the discount, the tax, shipping costs, and then total. Each of those is tested for multiple edge cases, so if we do it all in the shopping carts there are potentially hundreds of unrelated tests that need to change when the discount factor changes just because they happen to check the total.

rkangel 6y ago
What it does is show up something that is true anyway for unit tests: automated tests are software and they should be designed like it. It might affect multiple tests, but all you should have to change is one or two places in some shared code pulled in by those tests. Too many tests have too much repeated code, and so become expensive to maintain, exactly like normal code. Refactor, think about shared functions etc. exactly as you would do with your production code.