Timeline for How to test business logic in isolation when it depends on input validation logic
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 6, 2019 at 21:27 | comment | added | Flater |
@BartvanIngenSchenau: I don't see a statement that the caller is responsible for the validation of parameters to be a sign of bad design It inhibits reusability of the assembly by other consumers. You're effectively forcing consumers to do half of the work for you. If that's elective validation, that's okay. If it makes the difference between things working or undefined behavior, that's not desirable.
|
|
| Jul 6, 2019 at 12:46 | comment | added | Bart van Ingen Schenau | @Flater: For me, proper design includes that at some point you start trusting your inputs and stop re-validating them. Those internal function might then show unpredictable behaviour when called with invalid inputs because they intentionally don't re-validate. I don't see a statement that the caller is responsible for the validation of parameters to be a sign of bad design. | |
| Jul 5, 2019 at 18:21 | comment | added | Flater |
@BartvanIngenSchenau: My comment was in response to then the Core project can just state that passing in an invalid Age value will result in undefined behaviour. Properly designing/improving the behavior is flatout better than just documenting its undefined behavior.
|
|
| Jul 5, 2019 at 15:36 | comment | added | Bart van Ingen Schenau | @Flater: Your analogy is flawed. What I am saying is that you don't need to put physical protection against over-revving your engine in place if the rest of the system is designed such that it will never turn that fast. You need to check somewhere that an age input isn't negative, but it doesn't have to be in every single function that receives that same value. | |
| Jul 5, 2019 at 13:08 | comment | added | Flater | What you say isn't wrong, but it's the equivalent of having your mechanic put an "warning: vehicle may explode" sign on your car instead of making sure it doesn't explode. It fixes the liability issue but it should be a last resort when the issue has proven to be unavoidable. It makes a lot more sense for OP to improve the issues rather than document the flaws. | |
| Jul 5, 2019 at 11:10 | comment | added | Bart van Ingen Schenau |
@Corcus: Adding such tests to the Api project can indeed help building that trust. And don't forget tests for silly stuff like Age = "twenty" if you are receiving requests over a protocol that allows such things (like HTTP).
|
|
| Jul 5, 2019 at 10:47 | comment | added | Corcus |
My issue with this approach is the "trust" in "trust the api project to catch all attempts at invalid data". Does this mean that there should be other tests in place, testing the api project's validations and the Age = -1 case should be tested there?
|
|
| Jul 5, 2019 at 10:32 | history | answered | Bart van Ingen Schenau | CC BY-SA 4.0 |