3 ms·
I literally gave examples in my example. As a general example, a unit test is great for things like: Your ExampleFactory calls your ExampleSerivce exactly onc
by bobthepanda 3y ago
I literally gave examples in my example.
As a general example, a unit test is great for things like:
Your ExampleFactory calls your ExampleSerivce exactly once, not more, not less, so you can check that side effects don’t result in unnecessary extra calls in more load.
This is particularly relevant in a language like Java; modern Java style is functional, but the old style relied heavily on side effects, and they’re still possible to write unintentionally.
- Verdex 3y agoI believe the kind of scenario that bedobi is referring to is something like this (using your example): Unit test exists, ExampleFactory only calls ExampleService once. Hmm, it turns out that ExampleUIButton calls ExamplePoxyNavigator more than one time if the text in ExampleUIButton happens to be wider than the default width for the button. What does ExampleProxyNavigator do? Oh, it calls ExampleFactory which calls ExampleService. But only when the whole system is wired up for deployment. The unit tests indicate that the system should be functioning okay, but when you put everything together you find out that the system does not function okay.
- bedobi 3y agoI understand your example and I agree that in that particular case, maybe a unit test to ensure a given service calls a dao once and only once or whatever is justified but I don't think the hypothetical risk of someone needlessly calling the db ten times is a good reason to justify adding that style unit tests to everything by default - if it happens, sure, add one for that particular call and call it a day