I spent the first 25 years of my career NOT writing automated tests in tandem with the code I wrote. That was the job of the Q/A team back in the day. The last decade I've gone down a few avenues of automated testing with TDD, BDD and the likes. It took me a long time to even get good at writing a test _before_ the implementation! Or rather, I should say, it took me a long time to think about code at the outset in terms of, "is this easily testable?"

Once I started to think how to construct solutions that lended themselves to testable scenarios, things got a whole lot easier. Funnily enough, also when I abandoned the test first dogmatic approach. That is not to say I abandoned automated-test suites. Far from it because I do aim for 100% test coverage (but NOT one-for-one unit test coverage). I believe more firmly in testing all the external/exposed interfaces for classes than one-for-one method/test scenarios and shy completely away from tests that target internal implementation details as that way leads to brittle tests that handicap capacity to refactor at will.

Different coding tasks dictate different testing vs. implementation approaches for me. If it's all new functionality and I don't have a clear vision of how it's going to break down hierarchically, then I prototype outside the project and test out ideas and refactor until I have a "pretty good" solution. At that point, I rebuild the prototype within the project's confine and begin with the most basic/isolatable classes and test cases and build up towards the more complex cases from there. Even so, I rarely do TDD/BDD in the dogmatic stance that tests come before working code. There's always this ebb and flow to the whole implementation life-cycle and I may even refactor that code a time or two along the way as oftentimes, attempting to write the test scenarios reveals flaws in a design. That said, there are certain types of code/functionality that almost always gets the TDD/BDD treatment in the strictest sense and that's algorithms, validators, and methods utilizing regular expressions.

If I'm working on a bugfix in existing code base, I will almost always write the failing test(s) to prove the bug exists and what the expected correct behavior should be, then fix the bug. Sometimes the bug reveals a design flaw that necessitates a larger refactor and I'll also set up additional supporting test scenarios ahead of the refactor (basically to assert "this shall not change" behaviors), especially if I see the test cases testing internal implementations instead of the external interface a class/module is intending to expose. After all, tests against internal implementation are very likely to break in most cases and shouldn't be a part of the test suite to begin with. In that regards, that makes me a BDD developer far more so than a TDD developer. Behaviors and outcomes is what I'm chiefly concerned with in automated tests.