... except seeing the test fail is how I know my test might be working.
It's trivial to write passing tests.
It's trivial to write passing tests.
No part of specs, TDD, BDD, etc., actually ever captures the reality of this, despite every Name Brand Workflow always claiming to.
This should only be the case while unfamiliar with the language or project at hand. In my experience, once you're familiar with the project and the language, mulling over a requirement for a short time should be enough to split it into smaller features which are simple to test in isolation.
It’s a function of requirements being ambiguous by design. Non-engineering stakeholders have a severe need for requirements and specs to be fungible and ambiguous, such that whether or not the state of the project satisfies requirements is fundamentally not codified in any objective document and no test can reflect useful objective measures of it. Tests can only loosely approximate it and the ways to do so are always shifting and changing and up to a subjective interpretation of some non-technical people.
Perhaps the only objective measure that non-tech people will agree to be specific about is financial cost, and even then usually only after it becomes a problem.
That’s every project in a product-oriented tech company period, and anyone claiming otherwise is full of it.
There can be isolated, tiny pockets of maintenance work or last stages dev work once you pass a point of no return when business people can no longer sustainable lobby for requirements to continue to be ambiguous and fungible, and finally you can start proving things with accurately scoped tests, but it’s so late in the game that the idea you could do something like TDD at that point is comical.
Instead, becoming a good product-oriented developer means in part learning how to write well factored tests on the fly at the same time you are writing the code to be tested, and keeping testing code clean and set up with fixtures and set up to run in highly automated ways, so that when you’re inevitably ripping stuff out of the implementation for the 18th time due to yet another priority pivot from sales, you can nimbly also update the tests as you go.
I’ve only ever seen non-engineers arguing about process crap and making claims like this, while engineers are forced to learn a bizarre skill set of how to actually solve problems despite this quarter’s latest and greatest new process thingy that’s going to fix it all.
I think the disconnect is that you're assuming the tests are about requirements, when in fact the tests people write with TDD are much more tightly focused.
This usually doesn’t help and sometimes hurts, because if the tests are tighlty scoped yet the requirements are ambiguous, it usually means the tests are very related to the current implementation details, which are going to rapidly change due to scope pivots.
TDD simply doesn’t work when you don’t know what tests to write or how to structure tests to accomodate scope and priority changes, which is all the time. Starting out by writing a test then coding to pass that test is baking in an assumption about that test which is almost surely already wrong, and just creates rework to undo a tightly focused test.
Being able to slice projects that way, in terms of functional behavior, is absolutely a skill that requires practice. You are already thinking about what your code needs to do: the practice is to get good at expressing that in terms the computer understand. Once you are in the habit, the tests make it easier to evolve the code rather than harder.
It is possible to be a good developer without that skill, but learning and practicing the skill will make you better.