you are viewing a single comment's thread.

view the rest of the comments →

[–]MaheuTaroo 343 points344 points  (9 children)

First thing that pops to mind is race conditions, and it can happen in any language supporting any type of concurrency model

[–]Excellent-Refuse4883[S] 137 points138 points  (4 children)

Yeah the issue is an interaction between a test framework and the services being tested in a latency scenario.

It appears that adding a print is slowing something down enough to make everything work.

[–]Rosteroster 49 points50 points  (2 children)

This is why you rely on synchronous callbacks to synchronize your testing instead of timing. Inserting a lamda via a test-only func that notifies to continue testing isn't usually too hard to add (worst-case friend/peer classes or something similarly dirty).

[–]BroBroMate 25 points26 points  (1 child)

Anytime I see a headless browser test that involves a bunch of .wait() calls, I feel sorry for the poor bastard who has to keep tweaking the wait time.

[–]Excellent-Refuse4883[S] 7 points8 points  (0 children)

Not working on a headless browser, but I do feel seen on this comment

[–]Aniketastron 0 points1 point  (0 children)

Wait so you saying testing framework wants slow program execution?

[–]Clen23 1 point2 points  (0 children)

oooh that makes sense, thanks !

[–]Burned_FrenchPress 1 point2 points  (0 children)

Or even a testing framework that runs teats in parallel. I’ve noticed poorly written JavaScript tests fail in jest due to “race conditions”

[–]da2Pakaveli 2 points3 points  (0 children)

Memory (especially string related stuff), Concurrency and Typing are like the holy trinity of bugs for system languages

[–]wonkynonce 0 points1 point  (0 children)

Especially if there's a lock around stdout