Sadly that sort of thing got so common where I work that I’ll run the tests three times before considering looking into the error message to see if it is something I broke.
From time to time we take some days just to fix tests with inconsistent results, but there’s always more popping up.
Just create a al Inter rule that rejects Any types and a pre-commit hook that refuses the commit if the linter fails. Sometimes the brute force approach is the best way to teach
That’s why I kinda don’t like Python and JavaScript anymore. Every time I want types for a library it’s gonna take me time to get it working. For every serious project I do, I use a strongly typed language.
I am currently teaching python and JavaScript devs Typescript. Everytime they hit a problem they switch to any
Sigh
Must be the same people who just comment out failing unit tests.
“Your crappy tests are failing again on my branch. I’ve commented them out until you fix them.”
Sadly that sort of thing got so common where I work that I’ll run the tests three times before considering looking into the error message to see if it is something I broke.
From time to time we take some days just to fix tests with inconsistent results, but there’s always more popping up.
Yeah, we have a team whose job is to make sure all our tests run well and fixing them if they don’t
Serious answer: You can’t write tests for untestable code. Your code needs to be pure if you want reliable tests: https://en.m.wikipedia.org/wiki/Pure_function
For integration tests, they should handle retries themselves
…or skip em
the beatings will continue until typing improves
Eslint is your friend :)
Just create a al Inter rule that rejects Any types and a pre-commit hook that refuses the commit if the linter fails. Sometimes the brute force approach is the best way to teach
That’s why I kinda don’t like Python and JavaScript anymore. Every time I want types for a library it’s gonna take me time to get it working. For every serious project I do, I use a strongly typed language.