I have been writing unit test cases after writing the code. Not the other way around. I do not think this is TDD . Is it ATDD?
Should I keep going on with this?
Thoughts?

Just stop with the tests at all and grab a beer.

Then it's just testing? And if you require to name it accordingly with a "fancy" three-letter abbrevation, it would be Development-Driven Testing, DDT :/

Not everything needs a name. You're just "writing tests." TDD is strictly writing tests first, so it ain't that.

I feel like we're getting to a climax with all these test/behaviour/contract driven development acronyms. Feels like one of these silly bubbles that's soon going to burst.

Shu-ha-ri

Try TDD 100% first, then start bending the rules and in the end you make your own rules. If you've tried TDD faithfully but then started giving it your own spin, it's only natural.

IMO the most important aspect is learning to write testable code

Regression unit tests are still good. You don't have to be a member of TDD church to write code

@alexbrooklyn Yes. And train your nose to look at code and see if it smells

Our main logging library (used by nearly every app we have, and virtually unchanged for almost 9 years) only has 16% code coverage.

Today, I was just given the task to increase that coverage (one of our top 'offenders' in SonarQube), and looking at what I would do...think I'm going to punt. More tests adds no value and I'd rather write code that solves a problem, not feed a code-addiction.

TDD is great way to start a thought process and encourages fantastic 'muscle memory' to write code that doesn't suck. That said, TDD (or whatever testing acronym you use) is one tool in your toolbox to solve problems and provide solutions to your users. Don't let it (TDD/BDD/etc.) be the 'golden hammer' that every problem looks like a nail.

@PaperTrail amen.

Quality over Quantity.

Half assed or nonsense tests to push the test score are just technical debt