Timeline for How to do unit testing with complex business logic with lots of different code paths?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 22, 2021 at 10:47 | answer | added | Flater | timeline score: 4 | |
| Nov 21, 2021 at 12:00 | history | tweeted | twitter.com/StackSoftEng/status/1462390344511799300 | ||
| Nov 20, 2021 at 16:48 | answer | added | gnasher729 | timeline score: 3 | |
| Nov 19, 2021 at 14:13 | comment | added | pjc50 | If all the codepaths are critical .. you have to test all the codepaths. That's just how it is. You can reduce the workload somewhat by not trying to test each path entirely independently, but it does a lot of stuff so it needs a lot of tests. | |
| Nov 19, 2021 at 9:27 | comment | added | David Arno | @gnasher729, indeed. And my 1,000,000 line app has but a single responsibility: fulfil a set of user requirements. So I've put it all in one function... | |
| Nov 19, 2021 at 8:05 | comment | added | gnasher729 | Philipp, it quite obviously has the single responsibility to validate the item. | |
| Nov 19, 2021 at 7:56 | comment | added | amon | There is SO MUCH opportunity in this code to do better. Quite some duplication, or code that could be easily extracted into helper functions. For example, there's this code for filling in defaults from Item2, the code for choosing prop1 or prop2 (in which the "prop1 AND prop2" branch is redundant), the code for determining an ItemState if correctPropData is available. When faced with lots of steps, people typically test that each step is correct in all circumstances, and that the steps work together – but not that all paths through the entire code base are covered. | |
| Nov 19, 2021 at 2:02 | comment | added | Filip Milovanović | Well, it's no more insane than refactoring without tests. But, I didn't necessarily mean literally - refactoring is just deleting the old code slowly; what I'm saying is that you shouldn't leave this as is, it will come back to bite you (and is already biting you). Also, you completely missed my point about how changing the design can make testing more manageable. You say you want to know how people manage testing code with lots of codepaths - divide and conquer, and re-express your code, until you find a better design that removes and/or merges some codepaths, & removes test redundancies. | |
| Nov 19, 2021 at 1:09 | comment | added | Magnus | Philip, it depends on what you think is a single responsability. This function validates an item of some kind (it's obfuscated of course) and part of that validation includes loading data from some other table into the item. To the people who define the requirements, it's a single piece of functionality, but that piece of functionality includes multiple steps. It doesn't matter if it does a single thing or not, all I want to know is how people manage testing algorithms with lots of codepaths. | |
| Nov 19, 2021 at 1:00 | comment | added | Magnus | I do have confidence that this function works, since it's been tested manually and put into production. Deleting this and starting over is insane. It should be refactored, but I want to know if there is a way to automate part of writing tests so I don't have to write hundreds of tests for each function or class. | |
| Nov 19, 2021 at 0:28 | comment | added | Filip Milovanović | Then use those within ValidateItem, by combining them into some sort of a mostly linear chain. You should have very few or no if-s. You might want some other function to accept this chain or validation rules, and produce and return ValidateItem (as a lambda, or an object); test if the right chain of functions is passed, and if they are actually called. 2/2 | |
| Nov 19, 2021 at 0:28 | comment | added | Filip Milovanović | Since "90% of the codepaths for each function are critical" and you don't have tests, you don't actually have much confidence that this works. So you might as well delete it, and start over by implementing small, focused functions - a function, or an object, for each rule, like your "validateProperty", and write tests for those. Then maybe write some functions/objects for simple combination of rules, test those. Maybe you pass a callback to be executed if the check passes. 1/2 | |
| Nov 18, 2021 at 23:21 | answer | added | Karl Bielefeldt | timeline score: 7 | |
| Nov 18, 2021 at 23:03 | answer | added | VoiceOfUnreason | timeline score: 6 | |
| Nov 18, 2021 at 23:00 | comment | added | Philip Kendall | I find it very hard to believe that a function of that complexity actually has a single responsibility. (I'm hoping that you've just obfuscated the variable names for this example, but if not that's an even bigger problem). | |
| S Nov 18, 2021 at 22:53 | review | First questions | |||
| Nov 18, 2021 at 23:25 | |||||
| S Nov 18, 2021 at 22:53 | history | asked | Magnus | CC BY-SA 4.0 |