Tackling Tough Parts Of Test Driven Development (TDD) With Michael Feathers & Dave Farley

Michael Feathers & Dave Farley offer advice to those struggling with TDD problems. Test Driven Development can put people off with its complexity, but it is an incredibly powerful way of working that both of these experienced software gurus have become zealots over!

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

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

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

🚨 MY TDD COURSE 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.

📧 Get a FREE "TDD Top Tips" guide by Dave Farley when you join our 📧 CD MAIL LIST 📧

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

🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS

[Immudzen]

When working with older code the policy we use now is based on boy scout rules. Leave the code cleaner than you found it. So if you go work on some old code add some unit tests to the part you are working oon. if you see some really bad code take the opportunity to clean it up a little, if reasonable, and add tests for it. Take that function that is 500 lines long and break it up into many functions with a much clearer interface for each one and then test them. I have found this actually ends up working quite rapidly to fix and older code base.

[pacifico]

In my experience, the second hardest thing on moving to TDD in a legacy system was writing the test fixtures. Those systems tend to have a lot of dependencies, so you'll be writing a ton of mocks to test a single class.
The hardest thing was getting developers on board. Even senior devs have trouble understanding how to approach the tests, and they are resistant to the initial productivity hit

[jimiscott]

My experience (of developing a middleware/integration platform) is...

1. You need integration tests if this is where the value of your system lies.
2. Edges to test in increasing difficulty are: File, database, simple REST Webservice; process spawning, sending Email; complex webservice; FTP/SSH; incoming email; ERPs/Business systems.
3. Dependent on your development framework, /language there may/may not be some test framework/addin which can help with the testing of the particular edge (mail, db, FTP, etc). Where there is, there will be varying degrees of maintenance. Database test frameworks generally are well maintained, mail testing less so. Where there isn't (for example FTP, SSH), you'll need to build your own.
4. Some systems are almost impossible to test 'properly'. ERP's and business systems with complex transactions can really only be tested by choosing a couple of key data points otherwise you're rebuilding the system's logic in your own test framework; the other fields/properties need to manually compared reviewed.
5. Your tests will evolve, become better and less brittle over time. Don't fret if they're a bit crap to begin with (at least you're doing something).

[PhoenixMoonbeam]

Seems like whether it's "glue code" vs something more computational/functional (in style not purpose) is that it tends to have side effects (an email, a DB transaction etc). You can still unit test these by using some mock framework as part of your unit testing. Maybe if you're actually testing for an email sent that's more of an e2e thing (I tend to forget the difference between e2e and integration testing).

[AssasinZorro]

I would love to see a discussion on applying TDD to game development.
It seems hard to do because so many things are glued to I/O of player interaction

[MatthewFerrin]

I’m of the opinion that there are 2 types of unit tests and that both are important. They are talking about BDD ones that give confidence that the code actually functions from the point of view of the interface and can drive development through TDD. BDD and TDD are great.

The type I think is omitted and wrongly demonized is tightly coupled unit tests of small units. I think these can be written quickly and maintained easily. That doing so encourages code to be broke up into more small, readable, reusable, and maintainable units. And honestly, I think tools to automatically generate and regenerate these tests should be written and executed in watch mode during development.

I essentially think we should be generating snapshots that are themselves tests that generate snapshots that display changes in execution results. It should form the extreme base of the testing pyramid and be entirely automated. Just press a key to accept the latest snapshots and they become part of source and can be reviewed in source control.

[Personal-M.I.S.]

Dave, since you've written a couple of books now, how would you contrast your experience as a writer with that of a developer, specifically in regards TDD? At least for me, as a bit of a writer and coder myself, I see significant parallels between writing and coding.

When we write, sometimes we start with one thought, but end up on some other tangent, that has to get put elsewhere. A lot of times we just have a vague idea and no clue where that will take us. We still have to go back and clean it up, so it's not a meandering mess (refactor). But the key thing is, we don't always know what the end result is going to be and we juggle ideas as we go.

TDD seems to ask us to know what the end result of our writing is going to be in advance and that we need to stick to one and only one idea at a time and link them together in a very logical fashion. But this would seem to very much constrain the whole creative process of both coding and writing a like.

There's of course the time to put on our editor's hat, but that doesn't tend to happen until we've written a fair bit. And of the writing advice I've gleaned is that one shouldn't wear both the writer and editor hats at the same time.

Maybe this would be an interesting subject for one of the weekly short videos? How does TDD fit into the creative process?

[francis_n]

Great video Dave. I am the weirdo in my job who actually enjoys writing unit tests and believes in TDD. I find a lot of developers I meet, especially my fellow UI developers, don't see the point of unit tests or at least do it because it is a chore and in order to get their PRs approved. Why in your opinion do you think a lot of developers dislike or don't believe in writing unit tests?

[yqweqwun]

in this era where youth are popular celebs, and driving innovation and tech, whilst old people are seen as boring and without passion.

Great to see a programmer of your age, wearing cool TShirts that youth wear. Imo cool fancy TShirts that young programmers wear make young people think programming is cool, and since I am young I can be a programmer like them.

Hope old people will get inspired by you and your cool shirts. Not to mention that instead of boring scholarly style that old people have, I as a young person liked your informal-ish style. Love the thumbnails too, lol some are quite funny.

[nedames]

I find tests introduce too much friction when prototyping. Creating and discarding different interfaces and base implementations constantly changes the tests when I just want to understand how the interfaces will fit together. Once I nail that down I want my tests. Thoughts?

[therealjordiano]

Its fine being a fan of TDD but i think this channel tends to promote it like it's the "obvious best choice", maybe it is a lot of the time but in my experience it would've made things a lot more difficult, so i see it as a situational benefit

[deanschulze]

"test as you need to change things"

That isn't TDD, though. TDD requires that you write the tests first. Maybe TDD should be less dogmatic.