3 ms·

While I agree that this is hard to implement with a type system, I never want to see this implemented as a unit test. What you describe is a real use case that

by seppel 7y ago

While I agree that this is hard to implement with a type system, I never want to see this implemented as a unit test. What you describe is a real use case that I personally want to have tested on a real system with all the stuff in place (but test database instead of the real one). It has nothing to do with one unit you can test on its own. And the crucial problem here is that you tie your testing code on the inner workings of transferFunds, when you are mocking stuff. > and verify that the warning is triggered when the value being transferred is over 95% of the amount in the account. Please also note that you cannot verify this property using testing. You can only verify that this works for one particular set of values (or a big but finite set of values). Testing never can verify that something always works. That's the wrong tool for this job.

floriol 7y ago
With TDD, writing unit tests accompanies writing code - which in itself necessities thinking in terms of testability, which is a good thing making the program's components more separable. Regarding the former example, mocking only a single part where it connects to other parts of the system (for example some interface through which it sends warnings to users) is easy and makes the resulting code better (eg, easy to replace the notification manager).
- seppel 7y ago
  > With TDD, writing unit tests accompanies writing code - which in itself necessities thinking in terms of testability I, as a user of your software, only care about the feature, and that the feature works. I don't care about testability, whatever that means. And since I case about features, I think this entails that features have to be tested end to end, and not some unrelated classes ("mocks") that are not even used in the final product. > is easy and makes the resulting code better (eg, easy to replace the notification manager). It might or it might not. I have seen too much code which was written way too complex which a lot of unnecessary classes and interfaces, just for the sake of "testability". However, some features did not work every once in a while. If you have the need for different notification backends, go ahead. Even if you need a notification manager (whatever this is) for this. But don't make code more complicated (sometimes called "test-induced design damage") without need.

by seppel 7y ago

floriol 7y ago

With TDD, writing unit tests accompanies writing code - which in itself necessities thinking in terms of testability, which is a good thing making the program's components more separable. Regarding the former example, mocking only a single part where it connects to other parts of the system (for example some interface through which it sends warnings to users) is easy and makes the resulting code better (eg, easy to replace the notification manager).

seppel 7y ago
> With TDD, writing unit tests accompanies writing code - which in itself necessities thinking in terms of testability I, as a user of your software, only care about the feature, and that the feature works. I don't care about testability, whatever that means. And since I case about features, I think this entails that features have to be tested end to end, and not some unrelated classes ("mocks") that are not even used in the final product. > is easy and makes the resulting code better (eg, easy to replace the notification manager). It might or it might not. I have seen too much code which was written way too complex which a lot of unnecessary classes and interfaces, just for the sake of "testability". However, some features did not work every once in a while. If you have the need for different notification backends, go ahead. Even if you need a notification manager (whatever this is) for this. But don't make code more complicated (sometimes called "test-induced design damage") without need.