Taking huge "leaps of faith" while coding
-
I typically do that too, but every once in awhile a solution has too many moving parts that all need to work together before you know if any of it works. A good example was my SVG renderer. Without actually seeing what it was rendering you couldn't easily test it. And for that to happen, a lot of things needed to go on under the covers - you had the parsing, the conversion to internal data structures suitable for rendering, and the actual rasterization process. All to make something visible at all. Otherwise, it's really difficult to figure out what your values should be when they're all based on multiple trig function outputs. Rock, meet hard place. Luckily it doesn't happen all that often, and also the thing that inspired my OP has now been implemented. Finally. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yes, I do encounter that too and I go first with smallest possible example - mock expected parsing results and compare actual parsing results, then mock that into expected internal data structure and compare actual results The last step would be a real pain, but still, mock that and compare actual results until they match (or you find out you were bad at mocking that part :laugh: ). Did something like this with ZPL graphics label export. Testing code for text to image is often painful.
-
Yes, I do encounter that too and I go first with smallest possible example - mock expected parsing results and compare actual parsing results, then mock that into expected internal data structure and compare actual results The last step would be a real pain, but still, mock that and compare actual results until they match (or you find out you were bad at mocking that part :laugh: ). Did something like this with ZPL graphics label export. Testing code for text to image is often painful.
I guess maybe part of it is I'm lazy? I can't fathom drilling down that much testing say, that SVG process. Some of it, like testing the parsing code, sure. But testing the data structures is very difficult without working with how they're actually used by the rasterizer engine. It would be very difficult, but not impossible to design the tests. However, is it more work than testing the whole and risking the possibility of a goose chase over the whole mess if it goes sideways? In some cases yes, I think. In this case, I guess if I'm being totally honest with myself, I *chose* not to validate the data structures and rendering process individually - or the parsing code for that matter, but testing that is not a huge deal and I did a little while making it). But it paid off in the end, in any case. Since it worked, it would have been wasted effort to implement those tests, even though knowing that beforehand is impossible. It was certainly a gamble.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I run(*). (*) Moderate distances, currently 4-5 miles three times a week. Seriously, I have this situation often. My stuff helps operate a 60-100 ft long printing press, so it's expensive and painful to debug. First, I have an emulator for the operational bits that manage the hardware. I can debug at my desk quite a lot. When I have to make an ascent on the mountain like you describe, I tend to walk the code in the debugger and verify things along the way. If I have a complicated new API, I'll write throwaway test drivers that concentrate on just operating the API so that I understand sequences and dependencies, which are often the most poorly-documented. This lets me understand the API with a fixed, easily repeated scenario.
Software Zen:
delete this; -
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I would believe you while coding you would know what each section is suppose to return. Been there I too get frustrated because I know what I want to happen. To reach that point I realize how many little pieces need to be implemented. Then realize that some parts could be reused for another section that has yet to be written. I try to test groups of code that work together. All trying to reach the goal of a functioning app. Take breaks after 20-30 minutes. Don't go 2-3 hours STR8. Wish you the best. Peace,
-
I guess maybe part of it is I'm lazy? I can't fathom drilling down that much testing say, that SVG process. Some of it, like testing the parsing code, sure. But testing the data structures is very difficult without working with how they're actually used by the rasterizer engine. It would be very difficult, but not impossible to design the tests. However, is it more work than testing the whole and risking the possibility of a goose chase over the whole mess if it goes sideways? In some cases yes, I think. In this case, I guess if I'm being totally honest with myself, I *chose* not to validate the data structures and rendering process individually - or the parsing code for that matter, but testing that is not a huge deal and I did a little while making it). But it paid off in the end, in any case. Since it worked, it would have been wasted effort to implement those tests, even though knowing that beforehand is impossible. It was certainly a gamble.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I am not so lucky with complex code, so I prefer not to gamble. But hey, no risk - no fun :laugh:
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Firstly, experience tells you how to develop systems that are testable. However, when push comes to shove, experience allows you to develop cognitive skills that can cope with lining up 5 or 6 ducks in order to get something working. Just so long as nobody interrupts you while you're juggling china ducks.
-
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it, because it's all interdependent. This often happens when I'm integrating something to an external API that itself is rather complicated, but it can come up in other situations as well. My SVG renderer for example - there are just so many moving interlocking parts that you're standing on a mountain of code before you even get to proof of life. So if you've ever been in that situation, I imagine you hate it as much as I do. It's stressful to me. I do not like coding a house of cards, and then having to go back and verify it after the fact. It feels shady. How do you deal with it? Some kind of process management? Some clever form of testing I'm not familiar with? Tai chi?
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Whenever that happens to me, I sit back and ponder, then realize a better design would have avoided the problem. CQ de W5ALT
Walt Fair, Jr.PhD P. E. Comport Computing Specializing in Technical Engineering Software
-
honey the codewitch wrote:
I can't be the only one that occasionally runs into a situation where I need to produce an awful lot of code before I can test any of it
Rarely, but it's a PITA and I get pretty stressed. Usually for nothing but occasionally it proves to be a can of worms and I have to go back and try to debug the code, which causes more frustration until I get to the point where I post a stupid question here on CP that makes no sense to anyone but me then I get away from it for a while and behold I figure it out.
If you can't find time to do it right the first time, how are you going to find time to do it again? PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com Latest Article: EventAggregator
1:Limit and validate input before attempting to process any further logic. 2:Handle any out of bounds input and/or dependency failures with effective error handling and comprehensive logging to allow forensics to show how and why the error was thrown and the inputs or dependency that caused it. 3:make sure the functionality of the new logic is well documented for allowable inputs, desired outputs, snf dependencies, with stakeholders responsible for the requirements well documented so there is no ambiguity about who wanted what, why, and when. If for whatever reason you can't do all of those in your work, something is very wrong with the overall approach and you are in deep doo-doo. I had to code "add-on" features and funcitonality to 3rd party business critical enterprise apps many times. 1,2, and 3 made it possible to do so with minimal stress because the proposed logic could be matched to what stakeholders agreed it was supposed to do (except for defects I created in the logic of course which is my own fault).
-
I don't have a debugger, so the debug sessions are .. interesting.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
On one Arduino project I did I tested some of my classes by writing a wrapper executable on the PC and using that as the "mock-Arduino" that drove the class so I could debug it, but I'm not sure with your stuff that would work too well.
-
On one Arduino project I did I tested some of my classes by writing a wrapper executable on the PC and using that as the "mock-Arduino" that drove the class so I could debug it, but I'm not sure with your stuff that would work too well.
Winduino: A Tool to Prototype Arduino Projects on the PC[^] :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Winduino: A Tool to Prototype Arduino Projects on the PC[^] :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Neat. I didn't go as far as you did, just some wrappers to source/sink stuff to prove out the logic.
-
Neat. I didn't go as far as you did, just some wrappers to source/sink stuff to prove out the logic.
It started out that way for me too, and then I got a bit obsessive about the project, as happens with me. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
