The Most Common Test Driven Development Mistakes

What are the common test driven development mistakes? and how can you fix them? TDD is one of the most effective approaches to improving the quality of our code and the efficiency with which we can build it, but it is challenging, There are lots of common TDD problems, and traps, that people fall into all of the time. TDD is not innate, it takes time and practice to get good at it, but it is a fantastic tool for improving the design of our code.

In this episode, Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering” describes some of the common problems that people face, and gives his top tips for avoiding them.

_____________________________________________________

🚨 My "TDD & BDD: DESIGN THROUGH TESTING" Course is Available NOW! 🚨

Learn to write great tests, and how to use those tests to improve the design of your software: with step-by-step guidance and demos by Dave Farley, and practical exercises for you to learn TDD and BDD. Available to start now!

_____________________________________________________

📚 BOOKS:

In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-------------------------------------------------------------------------------------

📧 ⭐️NEW⭐️ FREE TDD TOP TIPS GUIDE 📧

Sign up for the CD mail list and get Dave’s free guide with top tips for TDD

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[joeldpalmer]

Beware of videos, blogs and courses on TDD. Most add steps that don't belong or miss important points. This results in TDD not being adopted. Test-Driven Development by Kent Beck is the original text and the source of truth on TDD. This video and other videos on this channel seem to be consistent with Beck's original teachings. So, that is wonderful! Great channel!

[MSMR]

I have started to use TDD for every line of code I write in 2022 and it truly changed everything! I can recommend the book "Test Driven Developement by Example" from Kent Beck, it is a great way to learn TDD.

[wuilliam]

Great video! I'm a big fan of TDD, I'm a big promoter on my company, some of my partners are now TDD fans, and their code looks great, very professional. We really need more videos like this one.

[MatthewChaplain]

5:00 I've had a number of components that have gone through a redesign. My TDD'd unit tests have helped me here because, at the end of the day, I usually want the same overall behaviours. What this means is that I can comment my tests out and re-enable them one by one, rewriting as necessary in the new design. In this way, because I have already specified the complete behaviour before, I find that I get much higher quality re-designs where I can be sure that I have not accidentally introduced regressions. As a side-effect, if it suddenly becomes hard to express an old behaviour in the new design, I get to re-think whether the new design really is better and make a proper decision about that.

[florianfanderl]

I was a little worried before this video. Now I definitely know that I have solid basics. Still some nice nuances, especially the part at the end, which says that sometimes you have to change your tests.

[purdysanchez]

11:00, this is the heart of TDD. If you cant replace the code and still have the tests pass, you're not doing TDD. TDD is inherently bound to interfaces and design.

[StephenMoreira]

Still my biggest weakness as a developer. Every time I have a bug I'm like....a good test could have gotten that way before it got to production.

[Mr_Bob]

One of the important things I have learned about test driven development is that even if you can't adopt it for some reasons (oh, there are always plenty of them), you must at least be "test aware". If you're not completely "test driven", but "test aware", just asking yourself or developers you work with a question "how will we test it? And if not by hand?" can influence dramatic changes in the design of code.

[madmanX]

I actually liked the video before even watching it.

[christianschafer]

Dave, you mention that it is a mistake to use TDD on legacy code. I think dealing with legacy code and tests is a major part of most developers work. Can you elaborate a bit more on what exactly do you see as the problem? Could you produce a video on how to improve legacy code and especially it's tests?

Many thanks for this great channel! There is almost too much excellent content here.

[DiogoMudo]

Dave, I tried to promote TDD on the company I work for, and the seniors Al roll their eyes, saying that "it's a fad", "it's a waste of time", etc.
Do you have a solid example of a company that benefits from it with testimonials from the devs?

[johnwellbelove]

As a library writer, I feel there are certain times (though not very often) when knowledge of the implementation must be taken into account when the test is written.

For example, I wrote a deque (double ended queue) that used a fixed sized contiguous buffer.
It was very important that I tested the various boundary conditions where I *knew* that the data would wrap around the ends of the buffer. The tests were specifically written to set up to create these boundary conditions.

[BorGyn]

Thank you for the informative video. I have a question about retrofitting tests: What would be a good form of tests to retrofit to existing untested code?
A while back I added unit test style tests to some existing module, with a far from ideal separation of units along the existing classes. Now I think a different style of tests could have given the same confidence with the change I needed to make while at the same time paving the way for refactoring.

[-Jason-L]

Chasing coverage - this is a Test Last phenomenon.
Writing tests to pass - this is a Test Last phenomenon.

[denisitskovich]

What is so bad in component tests? Component tests allow testing the integration of all the subcomponents within the component, while isolating it from the outer world. These kinds of tests are not supposed to be a replacement to more granular unit tests, they also should not be avoided. Because if you avoid them - the first time you will find inner integration problems will be only in full system integration tests, which are much more complex to debug

[HKCS-ynnc]

If I understand correctly, TDD is a good design tool for the ports, while CRC cards are a good design tool for the corresponding adapters.

[hypenage]

Dave, you mention that tests should still make sense even after changing the implementation code. This makes sense. But When it comes to changing functionality even slightly, doesnt this mean the test also has to change? Some tests are extremely simple with one or two assertions, does the need of changing a test go against the goal of TDD? To better word my question, how does one manage and use TDD for updating existing code to add functionality?

(I am a huge fan and advocate of TDD, just curious to hear thoughts from you on this)

[RU-qvjl]

I’d be interested to hear your thoughts on unit testing DBs and the best approach to it. I find that testing causes me to write smaller and easier stored procedures. However, I just test for the behaviour that I expect to see and rarely try and get down to individual statements. I don’t see the benefit of testing each statement and all the extra tests I would need to write. Like I say, your thoughts would be most welcome.

[mateuszszczecinski]

How do you deal with extract class refactoring? Do create test for new class behaviour, and change test of previous to verify that it called new collabolator? Or you test whole behaviour only by interface of first class?,

[oscareriksson]

One problem I can't really grasp yet is what is the purpose of TDD? I mean you can test interfaces and make tests pass but it does not say anything about if the code will actually work. I am trying to learn and I just think sometimes it feels like you do the test, not testing implementation, and then the program crashes when running it. According to what you guys are saying, my test was good because it still worked when I fixed implementation, but I just felt it was completely useless.

So my question is really, is TDD testing not actually ment to test the actual code but to give a hint at how you can sovle a problem in a certain style of programming?

Another question is but what if I really need to test implementation of some critical points in the program? I mean I need to know if the program really does the things when it is running, and some times using unit testing to run some methods is very comfortable and useful to me. Are you suggesting that is all together a bad practise ? I think you should also REALLY test your program no matter how many unit tests you do. Especially if you are not testing implementation at all.

I have a difficult time seing what is what with TDD. Only trying to learn I am not trying to argue against TDD.

Good videos.