You actually do TDD all the time? Sometimes? When fixing bugs? When doing APIs, when doing UIs, when?
Or you do DDT, development driven testing?
Ok, I just made up the last one.
I find it an amazing approach, I rarely do it. When I know exactly what I'm gonna code yes it just works.
Most of the time though I reiterate so much on my code that it just does not feel right. I prefer to finish my code and then add tests to them.
This obviously need some forward thinking.
So I'd say: I think in TDD, I don't do TDD.
What about you people?
Top comments (9)
In my development teams we must follow TDD. When I do a code review for a new feature the first thing I do is checking the test suite for that new feature and ensure edge cases are tested. Then I continue watching the code an so on. I don't know if they code first and then they create the test. The important thing is tests must be there.
It depends. Mostly I create tests when I create an API. Also I create tests when I fixed a big so then I will be sure that this won't be occur anymore. I think that is not enough, but it saves me some time when develop some new things.
We are working with C# and use NCrunch which runs all tests automatically and before you actually save your changes (pretty cool!), which really helps in keeping the morale in the team in my opinion.
I usually try to TDD most of the time. The big exception is when things get rather experimental, either to figure out how something could be done and testing different things along the way, or when working on the GUI (mostly WPF), where I try a lot of different approaches and things are hard to test. When it comes to the ViewModel, I'm back to TDD.
Often when chasing a bug I get carried away in the analysis and start changing and fixing things without having a test first, but I try to avoid that as I enjoy the safety net of a solid test suite.
It's a tool like anything else. It's great for proving out certain kinds of things but not as well suited for others, and shipping is more important than 100% test coverage.
Agreed :)
I sometimes write code and when I want to test it later I find that testing it can be hard. I end up refactoring to get nice, small methods to test. When I do write the tests upfront I feel like the code ends up much more user-friendly.
Above practice helps you to switch your design mentality naturally to writing small testable methods. That design mentality switch is where I think most of the win comes from when writing automated tests. Ironically, less from the actual tests.
It's a great habit to get into, provided it doesn't get in your way.
The tragedy of 100% code coverage
Dan Lebrero
Ah, good article really! Thanks!
Pointless tests, you have a point :P
The point is, like you say, TDD IF it doesn't get your way.
And I keep asking myself, especially when I'm experimenting, if TDD is the way to go in these cases.
There's definitely room for both practices: test first, test after.
I'm trying to understand from the community if this is broadly accepted, as opposed to: if you're writing unit tests later, then you're doing it wrong.
Mostly I follow TDD (meaning, i write test code before writing production code), but I rarely have 100% coverage.
I hardly do any integration testing and rarely test front-end. Sometimes I skip tests, if code is very trivial and never insist on full coverage from any of peers I work with.
But I do expect anyone fixing a bug to write a test first that reproduces it. It would look highly unprofessional if a bug will reappear or have to be fixed twice. :)