C++ works hard to thwart the "write test, run failing test, implement, run passing test, refactor, check-in" one-minute cycle, when the edit-build-run cycle is 30 minutes long.
Some version control systems are not very amenable to TDD.
TFS/TFVC, Perforce, Source Depot. Basically any version control system that is used by the business for administor purposes rather than for developer purposes.
If you can't change a line of code and check-in on a minute-by-minute basis -- even for a change that will (temporarily, I hope!) make for broken code -- the version control system is greatly inhibiting development.
Close second is cultural.
Some team cultures bear strong resistance to TDD.
Because change is painful (stressful). Learning new coding habits (such as TDD) is like trying to learn a Dvorak keyboard layout... all of a sudden 90 wpm turns into 5 wpm.
Some management sees no value to TDD.
So that management either does not support it, or actively opposes it. Especially command-and-control style management... if they're not onboard, TDD is doomed.
Thirdly, TDD done wrong.
I've seen way too many "unit tests" that were really integration tests.
I've seen way too many unit tests that were written in arrears. Which isn't TDD. And short-circuits the key benefit to TDD: tests guiding implementation design.
TDD puts positive pressure on a developer to abide by several of the SOLID principles, DRY principle, KISS principle, YAGNI principle, and Clean Code. If you've done a lot of TDD, you probably have noticed that most of your TDD methods are functionally pure with all the benefits that confers... and that's no accident.
But if the unit tests are written in arrears, all of that goes out the window.
In the real world, what did work?
When I worked with a team that was TDD savvy, and used C#, Visual Studio, NUnit and NCrunch... it was like magic. The right language, with mostly the right environment, with a reasonable unit testing framework, and the magic pixie dust of NCrunch was worth its weight in gold.
What was wrong with the environment? I would switched from TFS/TFVC to TFS/Git.
What was wrong with the unit testing framework? I would have preferred xUnit.net over NUnit, but such is life. NUnit is okay.
What was wrong with the language? It was a .NET project, so C# was very suitable. I would have preferred F#, but that's because I've tasted the functional programming flavorade and I like it.
Outside of that project, I would strongly consider D because of its core language support for unit tests and design-by-contract programming. Having design-by-contract as part of the core language can go a great way to needing less unit tests. Having unit test as part of the core language means you can change unit tests runners at will without all the unit tests needing to be re-written because each unit test framework has a different syntax and facilities.
Hi Eljay,
Thanks for the great feedback.
I agree that tooling is an important point. I'm happy, that I can use C# and NUnit for my daily work. Even if I, just like you, would prefer xUnit.NET.
And a really critical part is the team. If your team is not willing to try TDD or, even worse, doesn't like unit tests at all, you're lost.
I haven't seen a lot of managers who would actively forbid writing unit tests. Most of the managers I have worked with, would not tell you to write unit tests, but they would not punish you, if you do AND get your stuff done.
I can totally see your point with "TDD done wrong", but in most cases I would state that integration tests are better than having no tests at all. :-)
I like your recommendation for using D. I have never really thought about using D as a programming language. But with your points in mind, I will get a closer look at that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My problem for doing real-world TDD?
Well, foremost is tooling.
Some languages are not very amenable to TDD.
C++ works hard to thwart the "write test, run failing test, implement, run passing test, refactor, check-in" one-minute cycle, when the edit-build-run cycle is 30 minutes long.
Some version control systems are not very amenable to TDD.
TFS/TFVC, Perforce, Source Depot. Basically any version control system that is used by the business for administor purposes rather than for developer purposes.
If you can't change a line of code and check-in on a minute-by-minute basis -- even for a change that will (temporarily, I hope!) make for broken code -- the version control system is greatly inhibiting development.
Close second is cultural.
Some team cultures bear strong resistance to TDD.
Because change is painful (stressful). Learning new coding habits (such as TDD) is like trying to learn a Dvorak keyboard layout... all of a sudden 90 wpm turns into 5 wpm.
Some management sees no value to TDD.
So that management either does not support it, or actively opposes it. Especially command-and-control style management... if they're not onboard, TDD is doomed.
Thirdly, TDD done wrong.
I've seen way too many "unit tests" that were really integration tests.
I've seen way too many unit tests that were written in arrears. Which isn't TDD. And short-circuits the key benefit to TDD: tests guiding implementation design.
TDD puts positive pressure on a developer to abide by several of the SOLID principles, DRY principle, KISS principle, YAGNI principle, and Clean Code. If you've done a lot of TDD, you probably have noticed that most of your TDD methods are functionally pure with all the benefits that confers... and that's no accident.
But if the unit tests are written in arrears, all of that goes out the window.
In the real world, what did work?
When I worked with a team that was TDD savvy, and used C#, Visual Studio, NUnit and NCrunch... it was like magic. The right language, with mostly the right environment, with a reasonable unit testing framework, and the magic pixie dust of NCrunch was worth its weight in gold.
What was wrong with the environment? I would switched from TFS/TFVC to TFS/Git.
What was wrong with the unit testing framework? I would have preferred xUnit.net over NUnit, but such is life. NUnit is okay.
What was wrong with the language? It was a .NET project, so C# was very suitable. I would have preferred F#, but that's because I've tasted the functional programming flavorade and I like it.
Outside of that project, I would strongly consider D because of its core language support for unit tests and design-by-contract programming. Having design-by-contract as part of the core language can go a great way to needing less unit tests. Having unit test as part of the core language means you can change unit tests runners at will without all the unit tests needing to be re-written because each unit test framework has a different syntax and facilities.
Well, that my 2¢ worth. :-)
Hi Eljay,
Thanks for the great feedback.
I agree that tooling is an important point. I'm happy, that I can use C# and NUnit for my daily work. Even if I, just like you, would prefer xUnit.NET.
And a really critical part is the team. If your team is not willing to try TDD or, even worse, doesn't like unit tests at all, you're lost.
I haven't seen a lot of managers who would actively forbid writing unit tests. Most of the managers I have worked with, would not tell you to write unit tests, but they would not punish you, if you do AND get your stuff done.
I can totally see your point with "TDD done wrong", but in most cases I would state that integration tests are better than having no tests at all. :-)
I like your recommendation for using D. I have never really thought about using D as a programming language. But with your points in mind, I will get a closer look at that.