I don’t have tests for these small utility scripts and they work perfectly well. Tests also don’t pinpoint the error.
I’d never choose to have myself do more work if it’s not needed and the computer can do it.
Those automated refactorings would Not have helped in the situation I mentioned above.
Re:Practical Python Programming
by CraigJPerry on Sunday June 21, 2020 @09:10AM
(#23591820)
Testing isn’t solely about whether code works today - you’re unlikely to checkin something completely broken. In fact i advocate NO tests for throwaway code, move fast.
It’s whether it continues to work tomorrow after you’ve added or removed a behaviour. Tests are the secret sauce that keep the cost of change low.
Refactoring (a commit with zero changes to test code) is the other key pillar of long term codebase health.
Typing isn't a strong enough tool to combat that class of problem; you can fix the type signatures while introducing a semantic break. You need tests and if you have tests, what does typing bring? Keep your tests fast, measure and maintain a speed of >250 tests per second and remember to test behaviour not implementation - you won't go far wrong.
IDEs have been performing refactoring changes on our behalf in dynamic languages for years at this point. Don't manually edit when we've never had such powerful tooling available to us
Even concepts that i'd say are strictly the domain of static typying, like automatically pruning dead code behind retired feature flags, make headway today: https://github.com/jendrikseipp/vultureTyping has a time and a place, that is without a doubt but the world is better viewed without the static typing lens permanently affixed in place, your efficacy will increase.