- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What exactly is the purpose of a wait if you can't rely on it being correct in at least one direction? At that point it's basically just yield.
Edit Admin
If you ask me to pick a language to develop something timing-sensitive you'd have to beat me repeatedly with a stick before I agree to use TS/JS.
Admin
Fixed that for you.
Admin
Also, apparently ~~ does not work in quote tags. Great. I miss BBCode.
Admin
To be fair... The code itself may well be sane, it's stuff in tests. I've had times where I want to load data into the database and then run code that queries it in a test harness (yeah, you can stub out most of the DB side of tests - tradeoffs...), and if you're looking at some sort of eventually-consistent DB then you may need to wait for a bit before querying. You rarely want to do too much of that in unit tests, but an integration test or two (particularly during deploy in CI/CD) to sanity test things can catch weird bugs
Or you could be testing network timeouts or watchdog code - but that's hopefully a library rather than your general code
Admin
No it's not. A better solution would be to not use a 1 ms timeout but use the remaining difference to the target. You start with the desired timeout. If the timeout is triggered after that time, great, you only have one timeout call instead of possibly hundreds. If it gets triggered X ms too soon, you use a timeout of X. Continue until X <= 0.
Admin
I'd probably use mocked timers and advance the clock instead, if that's an option. Otherwise I'd poll for the expected state with a timeout instead of sleeping a fixed duration. Most testing frameworks support this, and it also avoids waiting for long timeouts in CI. The original approach feels like we're testing the nodejs internals, but we haven't seen the actual test.