Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, alth

Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, although automated testing somewhat got very popular only a few years before TDD). I too became a big fan of TDD when I was introduced to it by rspec, then a brand new testing tool. But those latest years, I grew tired of keeping fixing my tests despite having no regression in my codebase - just because implementation changed. I quit doing TDD, but mainly because I quit doing unit testing. Nowadays, I only do integration testing. I've made a chrome devtool extension to generate capybara tests while I'm browsing, so that I can write my feature, then generate a test for it while doing visual QA in literally 5 minutes (this was something selenium IDE was doing in its time, I just made something a bit more modern to replace it). And since this is integration testing, my test won't break as often if I change the underlying implementation to do the same thing. I would even argue it makes my refactoring more pleasant : if I refactor correctly and end result is not altered, I don't even have to edit my tests (if it breaks, it may actually be a regression). That being said, what matters is what makes you more productive. Don't take our word for it, it may not apply to you. Just keep wondering how you could make things better.