Timeline for How to ensure functionality is tested consistently?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2016 at 15:31 | vote | accept | GWed | ||
| Jul 29, 2016 at 14:49 | comment | added | GWed | I still don't understand how this fixes my statist tests. Each test under classical/statist TDD asserts the state of the system. In this case, the state of grandTotal. The tests would not allow a common authority to be used as one test would always be wrong. The tests allow us to refactor out similarities into one single authority. We should not be refactoring out production code to test are tests are correct!!! | |
| Jul 29, 2016 at 14:37 | comment | added | guillaume31 | By having a priorly agreed upon domain lexicon with a single authority for calculating prices in it | |
| Jul 29, 2016 at 14:33 | comment | added | GWed | cool - so its a problem in both classical and mockism approaches - how do we solve it then? | |
| Jul 29, 2016 at 14:29 | comment | added | guillaume31 | I fail to see how 'mockist' TDD would solve this any better. | |
| Jul 29, 2016 at 14:14 | comment | added | GWed | But we refactor out production code that is similar. In this situation, the code will not be similar as two pieces of production code define grand total in different ways. Refactoring while using 'classical' TDD does not solve the problem, as ultimately the tests dont care about our implementation details (i.e. refactoring out code). We wont actually be able to refactor out the code as the two tests define grand total differently so one will fail. You could argue in this trivial case we would spot this error while refactoring, but that cant be assume true for more complex areas | |
| Jul 29, 2016 at 14:05 | comment | added | guillaume31 | Note that it may not apply to this particular case (I see price calculation as a domain object, not a small specialized class you can extract) but it's a general rule of thumb. | |
| Jul 29, 2016 at 14:04 | comment | added | guillaume31 | Just because you refrain yourself from using mocks doesn't mean you can't create a small class dedicated to something. The Refactor step in TDD is the ideal moment to do extract that kind of class. | |
| Jul 29, 2016 at 14:00 | comment | added | GWed | @guillaume31 i have no idea what that means sorry | |
| Jul 29, 2016 at 13:55 | comment | added | guillaume31 | @Gaz_Edge you need to separate in your mind the style of TDD you're using from the design you come up with, they are not related. | |
| Jul 29, 2016 at 13:52 | comment | added | GWed | "If you're in the business of selling stuff, then price calculation is of such vital importance that having two (let alone more than that) places in your code for deciding it becomes a major liability." Totally agree and that is my question: how do I get it in one place?! I do need viewOrder and viewAllOrders (and viewCustomerOrders, viewLastTenOrders etc). Using classical/statist TDD I cant just create some CalculatePrice class and then mock it when testing viewOrder, viewAllOrders etc etc so what should i do? | |
| Jul 29, 2016 at 13:37 | history | answered | Frank | CC BY-SA 3.0 |