3 ms·
Yes you're right. But then you're doing that by analyzing the implementation, not treating it as a black box. Personally I think we (software developers) shoul
by injb 3y ago
Yes you're right. But then you're doing that by analyzing the implementation, not treating it as a black box.
Personally I think we (software developers) should do more of that - i.e. take implementation details into account when designing tests, instead of treating components as black boxes, and when we change those implementation details, examine the tests to see what assumptions were made that now need to change. It's harder but it's closer to really proving something general about the code.
- kazinator 3y agoThat's where TDD falls down, iin fact. In TDD you first write a black-box test which fails, and then make it pass by fiddling with the interior of the white box. So, good, you then have a nice white-box test. The problem is with the refactoring step. Refactoring keeps the tests working, but some of them turn into blackbox tests which no longer relate to the internals. Like say you develop a function by adding cases, TDD style. Then you see there is a generality there and refactor so the individual cases go away. The tests probing those cases still have validity, but no value.