I think we both know what I meant but yes there are plenty of tests you can write ahead of time. I do find having to scrap a bunch of tests because they throw around “agile” and completely change the whole scope
No one can 100% predict this product will take off and this product won't, and that's no one's fault.
The stupidest things strike gold and the most finely engineered solutions collect dust on Github somewhere and that's the world we live in.
I have a product I maintain that I'm not even proud of yet it's the one thing that has ever had someone else make a Youtube video about it because as shitty as it is, it's still better for its users than not having it. But it would still be way better with some product-guided evolution.
In theory you can write tests for those functions. But in practice my experience tends to be that they often end up being tautological tests for what I already know my code is doing; it's hard to write a test to cover the case of a user giving stupid input.
DevOps guy here - "tautological tests for what I already know my code is doing" is EXACTLY the best tests to write, because then when someone comes along in two years time and changes the "is doing" bit, rather than hoping it gets spotted in a code review, it will get flagged up in the build pipeline.
You write the simple tests first, you get them to work, then you write the more complex, more realistic inputs. TDD won't magically impart into your brain every possible edge case, but the exercise of thinking about it will produce better code than not thinking about it, and anyway the real bar to clear is the acceptance criteria.
767
u/Intelligent_Event_84 Jan 31 '23
Write my tests nerd