"TDD is not an option" and yet,at the same breath ".. unit tested.."? I'm puzzled, care to elaborate the logic behind your statements?
I am a big believer in unit tests, but don't like TDD much. I think it fosters the belief that you can test quality into a product. Testing should be a verification that the rest of your process has resulted in a high quality product. It shouldn't be the means of getting quality into the product.
FWIW, most people shouldn't be unit testing at all. They should be writing high level automated integration tests.
I find where it works poorly it tends to just mean you have poor testing tools at your disposal.
Plus, people have a tendency to test things at far too low a level.
That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...
"Some have seen this solution to the shallow test problem and suggested that the ideal scope for our tests to target is the user interface, and to execute all the code in each test including framework and external components like the UI and the database.
Unfortunately the RoI of system testing is too low to do much of this. They’re slow, they’re brittle, they require careful environment setup and teardown, and they’re much more difficult to write and maintain than unit tests."
Slow is okay. It's better to be realistic than fast. You can also throw computing power (which is cheap) at slow. You can't throw computing power at unrealistic.
Brittle means either you have bugs which your test helpfully uncovered for you (e.g. race conditions) or you wrote a buggy test.
"Moreover, testing through the UI for every scenario in your code is just unnecessary"
It's almost always better to loosely couple your tests. It makes it easier to refactor the code that they test.
One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.
That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.
As far as I know, TDD suggests that the software is planned and driven by many failing test that are coded initially. A cautious developer may prefer building a feature on top of a failed (later to be satisfied) test but we worry that documenting the target product with all the necessary server and client tests may consume too much time initially. Some features that are likely to be postponed for later releases should not allocate our precious time and in the beginning, we may lack necessary wisdom to foresee it.
The other worry is that TDD in its most basic form is still a coding framework which may leave less freedom for the developer to express his/her preferred productive approach. We prefer to apply a framework on how we communicate, keep track of changes and measure our performance. The rest is left for the developer to experiment and find the most effective style for herself.
The way TDD is usually done is that the developer writes the tests for the feature she's currently working on, before actually working on the feature.
Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.
So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)
Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories).
Once the tools are there the process becomes fairly natural and the upsides become obvious.
Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.
It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out?
The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations).
Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.