Have you ever stopped to think that one of the reasons that people evangelize TDD is because it has worked for them and they want to share that with you?
Here are things TDD gets me in my everyday work:
* I don't have to refresh the web page and re-fill in my forms to see if the record saves correctly this time.
* I don't have to log out and log in as a different user to see how things work
* I can plan an API much easier with tests that I write first.
* I know that my features are done when my tests pass
* I can write new tests to prove that bugs my users encounter are really bugs. (You can't get everything tested the first time, but fixing bugs is much easier with tests)
* I can upgrade to a new version of a framework or library because when stuff breaks, I have a roadmap of what I need to change. I can then give a customer an accurate estimate of what it will take to do the work cos I KNOW what I have to fix.
You're doing it wrong if you write ALL your tests first. You write one, and you only write enough test to cover the feature you're implementing. then you implement the code to make it pass. This iteration takes no significant time at all to an experienced programmer, and automated tools can run in the background, monitoring your code for changes and only running the tests your code impacts. Because we're programmers, and we know how to write code that does that.
You think this is a joke? Something to be ignored? Go ask a CPA (accountant) how they do the books.
They sure don't just do the math once and say "trust me I'm really just that good." They balance the books. Dual-entry accounting. They do this because they are disciplined professionals. And people pay big money to accountants to get that right. Your tests shouldn't exist to exist, they should prove your code does what you want. Checks and balances.
Of course the path to this is the same path one takes to learn a new language. It will be slow to start. It was for me, but really, it's such a huge win for my long-term productivity. I am happier, my clients are happier.
Here are things TDD gets me in my everyday work:
* I don't have to refresh the web page and re-fill in my forms to see if the record saves correctly this time.
* I don't have to log out and log in as a different user to see how things work
* I can plan an API much easier with tests that I write first.
* I know that my features are done when my tests pass
* I can write new tests to prove that bugs my users encounter are really bugs. (You can't get everything tested the first time, but fixing bugs is much easier with tests)
* I can upgrade to a new version of a framework or library because when stuff breaks, I have a roadmap of what I need to change. I can then give a customer an accurate estimate of what it will take to do the work cos I KNOW what I have to fix.
You're doing it wrong if you write ALL your tests first. You write one, and you only write enough test to cover the feature you're implementing. then you implement the code to make it pass. This iteration takes no significant time at all to an experienced programmer, and automated tools can run in the background, monitoring your code for changes and only running the tests your code impacts. Because we're programmers, and we know how to write code that does that.
You think this is a joke? Something to be ignored? Go ask a CPA (accountant) how they do the books.
They sure don't just do the math once and say "trust me I'm really just that good." They balance the books. Dual-entry accounting. They do this because they are disciplined professionals. And people pay big money to accountants to get that right. Your tests shouldn't exist to exist, they should prove your code does what you want. Checks and balances.
Of course the path to this is the same path one takes to learn a new language. It will be slow to start. It was for me, but really, it's such a huge win for my long-term productivity. I am happier, my clients are happier.
Really, what's not to like?