Can you elaborate a bit on what we're talking about in regards to timing? 5ms, 100ms etc?
Can you also explain in a bit more detail the nature of what is being tested? No need to go to extremes here, just enough so we have a better idea of the why regarding such time-sensitive (and non-additive-to-codebase) testing.
Is mocking out pieces of specific tests an option? Do you store data externally so that you can test against it so timing isn't so critical?
| [reply] |
( Oh you have internet on your boat in the wild??? ;-P )
No I can't.
Communication is hard and I had to come up with a self contained example.
Enough to tell that these are extensive ETL operations shuffling and transforming trillions of data sets each night.
And I'm not going to tell my client that his code base of the last 20 years is "horse shit". *
The case is still interesting as such: What is the best approach for deep unit testing?
*) at least not on a daily basis ;-)
| [reply] |
"Oh you have internet on your boat in the wild?"
No. Definitely not. Weird thing is that I'm oddly outside (ie. underneath) most radio waves, so it's hard for us to reach out and 'see'. Actually, even on the "FM" dial, we can only get a few stations in our 'bowl', oftentimes only after sunset. (Most of my finds are AM or other).
Rockin' Bon Jovi out of Alaska while in Somewhere BC Canada is somewhat entertaining... more or less we listen to the solar powered radio(s) after the sun goes down, and write in my book what frequency occurs when, and from where. For what it's worth, I can tell by accent anymore where a radio station is positioned.
| [reply] |