You ONLY Get Code LIKE THIS With TDD

[@ContinuousDelivery]

Try our Free TDD Tutorial: courses.cd.training/courses/tdd-tutorial

[@tongobong1]

Great explanation why we should use the TDD. TDD is really a great tool. Now it would be great to hear when we should NOT use the TDD. You should ask Martin Fowler why he is not using TDD every time he is writing code.

[@arnoudt]

To add to @Ton Bong's comment. What cases would you not use TDD? Are there any? Soon I will start coding an app in Flutter for a startup. It seems the most optimal route is to jump into coding without writing any tests. This allows for rapid iterations. Flutter seems to allow for prototyping so well that you can create the first 'sketches' in it, without going first into wireframing tools. However, I see this as part of the 'design' process, and not the 'development' process. My expectation is that I will rewrite essentially the entire codebase once we have a UI and basic functionality we like. @Continuous Delivery, would you argue against such an approach? Do you think even in such a case it is better to use TDD from the start?

[@stamatispsarras]

Can we get more examples? This is one of the best tutorials I've seen, especially compared to various simple examples in YT. I think it would be interesting to see mistakes, rather than a perfect run of TDD (which yours have) maybe a bit of debate regarding possible solutions in the context of pair programming. It would be also cool to see the example in TDD Vs a non TDD method! :)

[@ContinuousDelivery]

@@arnoudt I think that not using TDD can work for very simple apps, thinks that you write in a day, and TDD works better for most other things. I disagree that it is "most optimal to jump into coding" it just feels like that. As soon as you need to change something, TDD saves you time, not only because you wrote the tests, but also because you code is better designed and so is easier to change, because you are pretty much forced to design for testability, and testable code is more modular, cohesive, has better separation of concerns, better lines of abstraction and is looser-coupled.

[@ContinuousDelivery]

@@tongobong1 You don't need TDD for very simple bits of code that don't matter too much, I'd use it for most other things.

[@LeoOrientis]

Whenever I've been writing any fragment of a programme for any more than a twenty-minute stretch without running a test cycle, I get a searing feeling in the pit of my stomach. It's telling me that I've been working without a net for too long. And I'll soon be spending a frustrating hour down in the debugger, pondering this and that, until I manage to corner a problem that ought to have been blindingly obvious to me.

[@richbuilds_com]

I like to describe TDD as "Interface first" development to those who don't get it. You first write the code that will interface with your code. That code is your Test. Then you fill out the code to fulfil the test. I like this way of thinking about your code because very early on you make decisions like "Should it be a fluid interface? / Does it work with a fluid interface?" before you actually write any working code. (Most none TDD coders work like this anyway: they are working through a problem, the realise this bit is getting complex so they turn it into a function / method and the code they just remove is replaced by a call (or test) - they don't change the test to make it work - they change the code being called. They are just too proud to admit it. I know I was ;-) )

[@marikselazemaj3428]

Abstraction first, then tests, then implementation

[@markhathaway9456]

@@marikselazemaj3428 That is the way I was taught in the 1980s, though it was with simple imperative Pascal (in the books) and with several languages on the computer. OOP had yet to become prevalent in the schools and probably business back then. My experience programming indicated there were some difficulties in practice and I don't really know whether more recent languages solve all of them. Adding OOP and Functional Programming techniques and capabilities certainly complicates, but probably doesn't change the fundamental issues. The things Farley mentions: separation of concerns, cohesion, etc. come from studies done long ago which led to Modula and C++ and so on (SmallTalk didn't even have all that) and yet problems persist. Look for videos "OOPS is Bad". They're out there and explain issues well enough. I've been studying Scala a lot recently and it does Imperative, OOP, and FP and automatically there is "lack of transparency". When you look at code it's not so clear what's happening. The ergonomics issue arises and isn't so easily dismissed. Programming well is difficult and languages present some problems as well as solutions.

[@nivoset]

This is what i am pushing for more.

[@arnoudt]

​@@marikselazemaj3428 Putting it like that seems very clarifying. I'm starting out in software engineering. And TDD seems in ways more complicated than actual coding through the problem. However, I would always start with abstraction, clearly thinking through the problem and clarifying what input should produce what output. My question: is it mandatory to start with writing the actual code for the tests, or is it sufficient to specify the abstraction of the tests only? It seems helpful to improve the test (requirements) while working through the code itself. E.g., you may realize additional ways the code could fail while writing the code. This seems analogous to the concepts in (the philosophy of) science of validation vs falsification. Avoid writing code that you 'validate' through tests (hypotheses). Instead seek to falsify the code (hypotheses). Some philosophers of science argue it is essential to describe the experiment and the conditions under which it fails/succeeds before doing the experiment, this includes defining the range of values you could expect and what each (range of) value(s) means for your hypotheses. However, the reality of doing science is that it is a process where new insights often come throughout the process. I have the sense that the same is true in programming. In short: should TDD always involve writing the test out in code before writing the software itself? Or is it justifiable to go through the three stages: from abstraction, to defining the test (without writing the test as code), then to coding the software itself. While actively revising the earlier stage as needed. And then to finish with writing the test out in code. Or am I missing an essential understanding of TDD?

[@marikselazemaj3428]

@@arnoudt I am feeling too lazy to write the full response, but in essence think of a set of inputs, a set of outputs and a mapping between the two sets. This mapping represents the abstractions. Then you have to write the implementations that does the actual algorithmic processing to transform the input into the output. The tests' role is to make sure that the implementation is following the abstraction. e.g. We have the functions ADD that adds two numbers mathematically, the abstraction is the mapping between the set of all possible two integer tuples to a set of integers that is the sum of those tuples. To make sure that the implementation is following the abstraction we write some tests. How do we write the tests and what do we test can be a bit tricky and depends on the situation, but in essence you start with some input and see if it matches the correct output, we can't write an exhaustive test that checks all the possible inputs, but that's not necessarily the goal here, at this point you have to think more like an engineer rather than a mathematician, where you try to check inputs that give you enough confidence that the implementation is correct. You should test the abstraction and not the implementation. Keep the test simple and binary.

[@sasukesarutobi3862]

I've seen a bit of a trend of people seeming to think that TDD replaces debugging, as if they're two diametrically opposed approaches, but I've found that when I've had to debug testable code, it makes the process vastly simpler. Many IDEs that provide in-built support for test runners will also support things like debugging individual tests, which I found to be a revelation in troubleshooting testable code. You can write or extend a test to cover an edge case that's cropped up, drop a few breakpoints in, then debug it, and you're not having to try and find an entry point or litter your code with test variables; you can put all that in the test and then exercise the area directly, and you not only get a more precise way to debug, but also a free regression test for that edge case when you're done!

[@uome2k7]

I think people resist TDD because all means of learning to code just teach a person how to code using very basic examples. Unit testing is something picked up later. (writting worthwhile tests is another gap in learning on its own but thats another discussion) There is not really anybody teaching code development while using TDD practices. Having the practical examples would greatly accelerate adoption because it can be difficult to wrap your head around what TDD looks like in practice. This is especially true for people still in their early stages of learning to code at a professional level.

[@Immudzen]

Over the last year my experience with TDD has been extremely positive. I stared working on a project that merged about once per year and had many bugs so changes where rare and it was difficult to work on. I started adding tests to the project and slowing fixed it. We are now able to merge multiple times per week and have not had anything major break in over half a year. We have had a few minor problems that where quickly sorted out and new tests added to catch them. I am not saying the code base is completely tested at this point but as we continue to add more tests development just keeps getter faster. Probably the biggest change is that by having to write tests for the code it has forced some of the code to be rewritten to be more functional and easy to test. This also had the side effect of making software composition easier to do and a GREAT deal of code was removed.

[@e2e23e]

"I started adding tests to the project and slowing fixed it." That's not TDD, so the speed of merging of you got was from the unit tests.

[@Immudzen]

@@e2e23e Technically it was a combination of TDD and unit tests. For most of the new changes the tests where written at least partially first. Unittests where also added for older code in order to refactor the code. Tests for the newer functions to be created where often written first.

[@craigharris480]

I have seen developers having problems applying TDD due to other decisions in the architecture. This has been most common with developers attempting to learn TDD by testing a "Fat Controller". The perception of TDD being overly complicated and leading to "mocking hell" is not caused by TDD itself, but rather the lack of a well layered architecture with controlled dependencies. Developers whose first introduction to TDD is with a more functionally defined library usually understand the value far more often and quickly.

[@gzoechi]

If you stick with TDD anyway you will inevitably change your code structure eventually, to make it easier to test. That will probably be the most important step in every developers career.

[@jimhumelsine9187]

"Fat Controller" ... I love it! When the test is messy or complicated, it means that the implementation is probably messy and complicated. It's an indication that refactoring may be needed.

[@TinBryn]

I think the key aspect of TDD is the rapid switching between writing tests and writing implementations. While we all know it's easy to write difficult to test code if we don't write tests for it, it's also easy to write difficult to implement tests if we aren't implementing them. What TDD does for me is lead to easy to test code and easy to implement tests.

[@pompiuses]

One of the big problems I see is that most developers write tests which are coupled too hard to the production code. Usually by testing class by class, method by method with lots of mocks. This makes the codebase very fragile and rigid as the suite of tests grows as small refactorings of the production code will break lots of tests even though no functional changes are made. Robert Martin calls this the fragile test problem. What's a good way to avoid this?

[@ContinuousDelivery]

Write the test before you have code to couple to. That is one important reason why TDD is better than only, after the fact, unit testing. Part if learning TDD is learning how to separate the goal of the test, from how the code works. Good tests express a need that the code fulfulls and say NOTHING about the internal workings of the code.

[@pompiuses]

@@ContinuousDelivery Yes, I agree. The problem is that most developers I've worked with just pretend to be doing TDD and write the tests after the production code. This is what causes all the problems with coupling. In that case I'd argue that not having any tests may acually be better. Delete the test after you're done to avoid a maintenance burden in the future.

[@tongobong1]

Yes those class tests are "London" style unit tests where you should mock every call outside the class under test. They are just terrible. You should use the classical style unit tests instead.

[@georgehelyar]

Sometimes I write test first, sometimes I write test after. It really depends on how exploratory the code I'm writing is. At the extremes, if I'm writing code to explore several approaches to see which one to go with I generally don't write tests first because most of it will be thrown away immediately, but I'll pick an approach and ensure it covers everything it needs to cover by writing tests. I'm really just writing prototype code at this point to think through the problem and what the possible solutions might be. You can do that test first but really only with very high level tests, because the scope of the refactoring is so large. On the other end of the spectrum, if I'm fixing a bug I will always repro the bug in a test first and then fix it. Just use whatever tool makes you most productive at the time.

[@presbiteroo]

I really enjoyed learning to use tdd through this channel. It really changed how I write code. However I see it as a tool that I don't use all the time. I still test my graphical interfaces by hand and I trust enough error raising code for being simple enough not to write a test before. So use tdd mostly for helping with the logic and design.

[@gammalgris2497]

If you don't do TDD or unit testing you have a higher manual testing effort. If you start prioritizing manual tests you'll end up having to spend more time with 3rd level support. If you don't document adequately (on various levels of abstraction as needed) your future you and others will need more time to understand the software/ solution. Whatever you do, if you are skipping half the work it will come back like a boomerang, but with massive interest. The most important currency: time. Time will always be scarce. It's no fun maintaining a collaborative mess.

[@brintmontgomery8323]

Exactly right, @gammalgris2497. It's really about investing in "future me", so that future me doesn't think past/current me is an idiot for cutting corners by going off and "Cowboy coding" w/o using otherwise trustworthy TDD methods.

[@guysherman]

+1 for the "bookmark in the code" benefit, I often sketch out the next few things I need to do as failing tests (or todos in platforms like jest), that way as I encounter things that need expansion (like maybe handling failure cases) I put the test in and keep focused on what I'm doing

[@chaoslab]

Started using a primitive version of TDD last year during a sizable refactor (my xml parser can now be easily back ported to ANSI C). Was like having a back up, told you when and where things went wrong, easy to remember where in the process you are thanks to what ever test is failing, could get through the more difficult challenges with less stress as TDD makes chipping away at a large intricate problem easier with incremental progress being simpler. I like to write IDE's as a past time and have done so for decades (now onto #3). Code that writes code that generates code (from models and generates into existing source, persistence and parser solutions) is in itself a good test case as things break and need to be fixed when things are wrong. Refactoring that was not straight forward, it was allot of complexity and that is where TDD shone.

[@davemasters]

I must admit I struggled to move to TDD. It's just hard to change your routine behaviour after years of not doing it - even when I had accepted it's clear and obvious benefits. I think if we were all taught it from the start and it was somehow the only way of programming there would be few arguments against it. One of the biggest benefits I get from TDD is that it forces me to work in small steps. Prior, I would try building something in it's entirety in one long step and often get in a muddle. Working in tiny incremental steps really helps my mental model and I've found I make progress much quicker overall.

[@HemalVarambhia]

Thank you for the mention, Dave. I'm told I'm a celebrity of sorts now. 😂❤.

[@techforserious60]

Agree or disagree, I appreciate that this video is something that provides a bridge between the person making the video and the audience, its more of a conversation and less of a podcast, which to me a step against dogma, which i'm always in favor of

[@ybumbu]

I think the actual reason why some people are struggling with TDD is they are not reading books or trying to follow good tutorials about TDD

[@markky212]

Hi! Can you list a good tutorial/book about how to work with TDD in web frondend development. And please let it be not "TODO APP" but real world project with examples. I read Vladimir Khorikov "unit testing" book and I love it, and agree 100%, but it's not about TDD.

[@cheetah100]

This is the No True Scotsman fallacy. Aka, nobody who knows TDD can have difficulty. Sometimes there isn't a one size fits all solution. For those who use and love TDD all the best, go at it. Others might have a different path, for their own reasons, specific to the domain they are working in. That said, professional developers should understand the philosophy behind TDD, and be acquainted with it, along with a variety of other design philosophies.

[@tylerkropp4380]

@@cheetah100 It's indeed fallacious as an absolute statement. But there is truth to the idea that some people aren't going to resources on how to use it, like they're not even trying. Consider all the people who say they use TDD and always "test-drive" their changes after writing the implementation. TDD wouldn't seem so amazing if that's what I thought it was. So maybe there's a little bit of equivocation going on in those cases.

[@ilovepickles7427]

I'm totally sold on TDD and practice it wherever I can. However I can sympathize with it taking some of the creativity out of it. I work in mobile and we are mostly focussed on providing a beautiful and fun UI (we are working in music production). To be sure, our services have a comprehensive suite of tests, but we always start with the UI first. We have found that we work best when it's our UI that guides our design, not the other way around. Imagine trying to design a musical instrument with tests! Our problem essential *is* the UI. The practice that has worked best for me is to write the UI first and then extract a use case and put that under test. It's definitely not TDD in the traditional sense, unless you consider the UI the test. Great video as always. Thanks, Dave.

[@gJonii]

How I view it, TDD is a special application of more general principle, "only write code you need". In case of TDD, you write a test that requires a particular functionality to exist, and writing it in the shape of unit test has some extra benefits, like documenting the code, and verifying the code works as intended automatically, but still, the main point is, you write implementation as a result of needing/wanting that implementation to achieve something larger. UI to me is similar source of need, to prompt writing implementation. You don't get repeatable tests or the documentation tho, unless you have extra workflow for that. So if it's possible to have UI manual testing and TDD style testing with similar effort, I think it's clear TDD wins because of the extra benefits. But if TDD benefits can't be realized with reasonable effort for some parts of the problem, going for something different seems well within the spirit of TDD or "need first" driven development.

[@cod3r1337]

I get the concept intellectually and try to implement it anywhere I can, and also encourage junior devs to do so. BUT the elephant in the room always seems to get conspicuously omitted in basically every discussion or textbook on TDD: UI development. Because that's what many devs out there do a lot, if not all of their time. And despite all the advances in tooling in the past decade, useful UI tests are still really hard to write, and even harder to write in a way that abstracts away from the implementation you end up with - which is a must for the tiny-steps-incremental-TDD approach. While we have had *some* success writing what Dave calls *unit tests* for UI code - with great effort, mind you - that probably helped us save cost in the long run by avoiding regression bugs, we almost always failed miserably applying the test-first approach to UI code. And not for lack of trying. Or are we just too stupid to "get it"? Sometimes I wonder. But if so, who is TDD for - an elite core of 10x devs?

[@moodynoob]

Lol I might add, Kent Beck worked at Facebook where they barely did any unit testing and were extremely successful at it - the podcast of his experience there is very interesting and worth reading/listening. Facebook uses advanced monitoring and rollbacks to test changes in prod in a controlled roll out. But different teams (such as infra I believe) use a lot of automated testing though most don't. It lines up with my experience, use TDD where it helps and makes sense. If you've never done it, it's worth forcing yourself to try it. But I would never enforce it as a rule, and caution those against blindly joining the TDD cult.

[@serdarcoskun8367]

yeah thats something always keeps me at the gateway. i really like to get into tdd but i really don't understand how to implement them with ui or elements related to them. all documentations that i stumble upon only shows extremely basic implementations. really frastuating

[@НиколайТарбаев-к1к]

You can abstract the UI code away (e.g. using MVVM pattern) and develop the rest in TDD. Then optionally write some UI acceptance tests. Surely some bugs can be introduced in the UI binding code, but from my experience they happen in 1% of cases or so, as this code should not contain any logic.

[@serdarcoskun8367]

@@НиколайТарбаев-к1к yeah i always abstract controller logic from ui but there still are things that i cannot wrap my head around to develop with tdd approach. and also i really want to learn if there are ways to implement tdd into ui layer too

[@НиколайТарбаев-к1к]

​@@serdarcoskun8367 the problem is UI is for humans. To test UI we need to mock a human, but humans are too complex objects to mock reliably. Also UI is very volatile. That's why IMO it's just not worth the effort to do TDD of the UI layer. But you can treat your model/controller as an abstraction to UI. That's why I like MVVM where the view-model represents a complete state of the UI, which can be thoroughly tested and the UI layer only defines how the state should be rendered but does not contain any logic.

[@MrCalyho]

One of the barriers with teams adopting TDD is the big discussion about how TDD should be done. A lot of people think that you should focus on writing tests for every class and every function which has the effect that it takes a lot of time to do and when you refactor you must change the tests as well which IMO makes it not worth doing. Working in this way also limits updating the architecture of the application because the tests are intertwined with the architecture. Unfortunately this view on TDD is the prevelant one and in my experience the biggest hurdle in adopting TDD. I introduced TDD in my last two projects by getting the devs to do acceptance tests only - but make them first - and only if it gets really complicated make more fine grained tests. And also completely ignore the discussion of what is a 'unit test' because these discussions are not helpful. Focus on the discussion 'does the test garantee my feature works'.

[@larsmielke9400]

One of the main issues I have with tdd is my inability to think far enough ahead, at the required level of detail. I also believe that this is what stops most people from using pure tdd. There is nothing more frustrating than spending some time writing tests just to realize after writing 5 lines of code, that you have to slightly change your approach to the problem and possibly throw away all the tests. Personally I even prefer to write the entire thing twice and use tdd only for second round.

[@bernhardkrickl5197]

That is a valid approach. Eg. if you have a new library or framework you want to use and you are not familiar with it yet. You can just play around with it, not bothering about tests. Write some prototype code to learn about this new thing and how it works. Then throw it away and think about the tests. That doesn't contradict TDD as long as the code you end up keeping was designed test-first.

[@Mozartenhimer]

Having joined the TDD cult, I will say I spend so much less time confused and stressed about the code I'm writing. On the handful of occasions I've strayed, and said "nah I got this", I wind up confused as to my objectives a few hours later and regret my poor decision making.

[@brintmontgomery8323]

Here here, Mozartenhimer! I've paid the same price for my "nah I got this" actions; yet, I've never done so when I stuck to TDD.

[@lierdakil]

I've seen projects where applying TDD with wild abandon resulted in extremely convoluted, strongly coupled, hard to understand design that exposed way too much of its own internals as public API "because we need that for testing", but those internals inevitably leaked into other code. Now, I'm not to argue against the fact that TDD works when it works, but whether it does depends on what you're trying to do exactly, and one needs to decide whether the tradeoffs are worth it on a case by case basis. For example, TDD doesn't work so well when you need to make a non-trivial change to some API (usually extending it with a new non-trivial behaviour or make it more flexible) and you don't have an exact concept of how that would look like. You could envision the most simple, beautiful API at the concept stage and write your tests to reflect that, only to hit a brick wall of refactoring half your code base to support exactly what you envisioned. Then you make some reasonable compromises, but you'll have to rewrite your tests, and pray it's not from scratch. IOW, TDD, at least in the form it's usually presented, doesn't work well with design space exploration.

[@slotos]

I’ve noticed that primary drive against TDD in Rails shops is the boot time creep. At some point the wait part of testing loop becomes so long, that it breaks focus. There are two solutions: drop TDD or break up and decouple the system. Many go for the first one.

[@ContinuousDelivery]

Clearly I think the choice is a big mistake. My personal approach is to do everything that I can to make TDD work, and if I can't find a different language/framework/environment to work in. Not just me saying that, here is Brian Liles saying "Test all the F*^%ing Time" at Ruby conference: kzbin.info/www/bejne/gpfQcq2CdrB-pcU

[@campbellmellor]

How do you recommend implementing TDD for data engineering projects primarily utilising cloud PaaS services such as Azure Data Factory?

[@timseguine2]

Even when I am not writing "test first"(I still feel like I can prototype faster without it), I still almost always think about my interface first. If you strive to make a good interface, normally the code is better for it. And TDD pretty much forces you to make a good interface if you don't want to drive yourself crazy.

[@rentefald]

Being a developer since 1998, I can tell you that I use TDD. First I fiddle around with code and specifications, then after some deep thinking and meditation just staring into the screen, it suddenly makes sense, and then I write my TDD with all the edge cases etc. Could I start the process with TDD? Sure thing.... but this ancient technique I use, is actually pretty working surprisingly good. Programming is often considered a creative endeavor, and C# developers use their skills and knowledge to craft solutions to complex problems in unique and elegant ways. Like artists, C# developers must be able to think outside the box and use their creativity to develop innovative solutions. They must also be able to balance form and function, crafting code that is not only functional but also efficient, readable, and maintainable.

[@bernhardkrickl5197]

My guess is that many developers that struggle with TDD are working on a (legacy) code base that is not very suitable for TDD. Getting an existing code base into the shape were you can easily do TDD is a lot of work. But it doesn't have to be done all at once. One can chip away at the code base piece by piece and make the TDD-controlled area larger and larger over time. TBH, I also only do TDD when the amount of work to get the code under test is somewhat balanced with the amount of work I will spend on the production code. If I know pretty well which few lines of code I need to change in some tangled, thoroughly untested part of the code then most of the times I'll just do some manual testing and leave it at that.

[@vladinosky]

I am currently experimenting with tdd in my day job as an embedded software engineer. The first impression is that it is not obviously adding value I can leverage, at least in the short term. It might also be due to the nature of working at the interface with the hardware because I cannot really test until it is actually running.

[@qj0n]

We integrate with many external systems, so we also can't be sure before running the system live. However, unit testing (we practice tdd, but it applies to all UTs) turned out to be great help, especially during bug fixing or refactoring. We create simple simulators in code with recorded communication from external systems and run our code against it. In case of defect, we add new test with real production code. In case of refactoring, we can check behavior on hundreds of real prod communication recordings

[@jimiscott]

We have a middleware solution, and have adopted a very similar approach. You will find that your tests will evolve until it feels 'right'. Some of those initial tests will be flaky - this is ok and part of the process. Refactor and find the level of abstraction to enable testing.

[@ContinuousDelivery]

Many other people do use TDD for embedded systems, Tesla and SpaceX for example. I have worked with many teams building embedded systems, and TDD works well, but it is a change. TDD should change the shape of your design. By making your code more easily testable, it should help you to better structure your code. In particular to isolate the part of the code that talks to the hardware, so that you can simulate it for example.

[@lkyuvsad]

In that situation, depending on how long I’m going to be spending in the codebase, I might: - write a contract (test suite) for a low-ish level api close to the hardware - run that test suite against the real hardware to check I’ve characterised its behaviour correctly - write a test double that matches the contract - use the test double to test the functionality of my system when integrating with the hardware It’s a bit of work, and of course you still need to test against the real thing in case the api contract is not compete. But the faster feedback cycles really add up if you’re working on something for a few months. The alternative of record-and-playback test doubles is also fine, and cheaper to implement. But sometimes it’s nice to be able to drive a stateful, contract-tested test double when setting up test preconditions.

[@nivoset]

I essentially did tdd in embedded back... before i knew really about tests, let alone tdd. Im sure it is greatly improved now. They didnt stay around in the repo, but i used to validate a lot of stuff.

[@thomasking9573]

Your comment on your viewers being self selecting. I kept asking about the advantages of TDD in interviews, with the misbelief that it'd provide insight and an interesting discussion. Maybe some thoughts I'd not heard before. But the primary response is always "the code is tested", with little beyond that. I am completely sold into TDD, and I hate it when a platform makes it difficult (see much IaC). But I am becoming more aware that what seems like the prevalent practice might not be, and the benefits aren't as widely known as you might think. I'd be interested in what, outside of our bubbles, the general feeling towards TDD actually is. Seems like it needs more promotion, when there seems to be so much of it already.

[@MMarbleroller]

I find the statement about "projects" that fail adopting TDD weird. "Projects"? I see TDD as something you adopt personally. I am not sure how one adopts it on a project level without getting weird. I much prefer using TDD. I have a difficult time understanding how one responsibly builds production ready code without it. When I look at code written without TDD, I typically see code that is factored in ways that are very hard to change, very hard to safely change without tons of anxiety. When someone has adopted TDD, then the "how do I write a check for this?" is already right there with the code. The structure is built around having started with testing, so adding more checks is easy and obvious. If you make a change that fails an existing test, you know you broke a prior assumption. I like getting that information. It gives me so much more peace of mind than the haunting silence I get from no tests being there.

[@adambickford8720]

It helps me manage tech debt when the reality of deadlines loom. If I see an implementation that could be better (internal coupling, some poor algorithm/data structure) i can let it slide knowing reimplementing it is relatively low risk.

[@laszlo3547]

I could never quite practice TDD as I usually work on code where automatic testing is not practical, however I did independently realize that all effective coding does involve testing very frequently during production. Examples where I couldn't use automatic tests: -the purpose of the code is to produce something that looks or feels right eg animating something -doing things like saving a file or getting data where I find the code required to test it is far more complicated than the code itself. Would you say I would still benefit if I tried using TDD in these cases?

[@tylerkropp4380]

I have found that when you have difficult-to-test dependencies like the file system, it's best to abstract the file system out and then maybe writing barebones automated tests for the file system provider (or whatever you'll call it) if at all. This allows the vast majority of your code to not have to deal with those dependencies. When doing this, it's best to keep it as low-level as possible, so that there is very little implementation that you have to do in the provider, which reduces the chance of messing it up. This is what we want because it's not very testable.

[@cccc2740]

TDD is not getting that mainstream because majority of developers are into code maintenance tasks, and its pretty difficult to have TDD for legacy code...TDD is only feasible when you get to write code from scratch...my 2 cents

[@nivoset]

You can make tests for new features or bugs in any code. May not hit everything. But that part is tdd

[@qj0n]

Tdd is great help in design, but after practicing it for couple of years I can say, I'm able to write good code without it. I'm still using whenever i write code which will be supported for years, but when i write PoCs or prototypes i skip it. I noticed my way of thinking is still affected by tdd, so code is easily testable

[@ddanielsandberg]

This is common. Dan North has mentioned it in some of his older talks. Once you've written a lot of code using TDD you have learned what good, testable code actually looks like; quite unlike the ideal pattern/by-the-book/I-was-taught obsession. With the experience from TDD you can make great decisions - "If I do this it will be clean and testable. If I do this other thing instead that will be harder". The problem is that most people that starts out with TDD thinks it gets in their way and therefore TDD sucks, not realizing that it's trying to tell you something about the code.

[@nivoset]

I find this about me. Even if i rush and just code something (poc type) it is still so close to testable... i generally end up using most of it with filling in tests. Makes it so easy.

[@agcwall]

@@ddanielsandberg This may sound wonky and unrelated, but I had the same experience with Rust and its borrow checker. It encourages you to organize your data structures in a way that keeps "just the data" together, and have clear delineation between "data" and "services/doers", and if you do that... your code is also more testable and more amenable to proper dependency injection.

[@vladinosky]

One thing that bugs me a lot too is why most podcasts have to be presenting consensual points of view. Why not inviting a notorious expert developer who is not using tdd and could give arguments based on experience?

[@bartschipper5128]

You may enjoy kzbin.infoz9quxZsLcfo. It’s the 1st of a 3-part discussion between DHH (famous for Rails), Kent Beck and Martin Fowler about the question: “Is TDD dead?”

[@tongobong1]

Great point! Dave should ask Martin Fowler why he is not using TDD everywhere.

[@barneylaurance1865]

@@tongobong1 Martin Fowler doesn't work as a programmer these days. I think he's said the main or only software system he works on now is his personal website.

[@tongobong1]

@@barneylaurance1865 so Dave can ask Martin Fowler why he didn't use TDD everywhere when he was still working as a programmer.

[@Ratstail91]

I have enough trouble just unit testing - though I wish I could to TDD. I've actually been working on a scripting language which relies on unit testing - I think that could've benefited from TDD, at least a little bit. Edit: Also, testing in gamedev is shockingly rare.

[@szeredaiakos]

- The "extremely small step argument" is application architecture. Properly done, considered and, importantly, re-considered throughout the development and production of a project should lead to the sweetspot of granularity, and quality. Tho helps, TDD alone can not promise a good design. In fact, the foolish reliance on it can downright destroy any hope of a well structured, high quality solution. - Vast majority of developers can NOT figure out the cases where a module could fail. It is not TDD fault, but it still makes it obsolete in inexperienced teams. - True, TDD has nothing to do with creativity. - As for testing, that can be written parallel to the actual working code. That is not TDD per-se but segregated perspectives does lead to better, more robust code. One could assume the test is written in advance. That is practically TDD, however, the most important part is the complete segregation of the test code and production code and the test should run only after completion to prevent cross pollution. - Tho' I must give one to TDD. It is very good for creating complex nuggets of code, relics. Best relic factory ever. The beauty of it that you can recreate relics with it extremely fast. - Properly done, TDD doubles development time. In highly experienced teams, it is just plain inefficient. If we talk about teams where the most experienced has barely 5 years, yes, it can make sense to include it in as one of the tools which leads to half decent code. But one of the tools, NOT the only tool. The usefulness of TDD as anything out there is a shade of grey, a brighter shade, but it is grey.

[@cheetah100]

To be clear, I'm 100% on having unit tests. However I'm not convinced about writing tests first. Writing a unit test means having an idea what the input and output looks like. Often you need to rub this around a bit to find what you really want subjectively. How can you even write a unit test for a webapp? Usually Selenium for example requires you record a session against the running app. Also, I've seen devs mark tickets as closed when the unit test passes, and not even see it run from a user perspective. This is dangerous. I'm not saying never write the test first; sometimes it makes sense. But it depends. There is no one true church.

[@TheVincent0268]

How do you leave a failing test on the shelve, as a bookmark? You cannot commit it to master because that will break the build.

[@sneibarg]

The way I see it is, if you want TDD to be effective, you have to know and have agreement on a set of requirements. That's the beginning of usefulness to me.

[@richbuilds_com]

If you have requirements, They are your (top level) tests.

[@aaronocelot]

TDD causes one to create black boxes in the convenient shape of a passable test. One distorts reality and lies to oneself. One must ask WHICH TESTS are interesting or useful unit tests, rather than their % of code coverage, and this requires nuance, understanding, and a desire to fix actual bugs, instead of just making black boxes which pass dubious tests. Extreme example: I can make a generic unit test that sees if a web response is a string, and, of course, every response will pass :D

[@aaronocelot]

not to say that it's not useful, but it's just a trendy phrase and not a panacaea, unless applied where applicable, nor does it solve all potential bugs

[@aaronocelot]

there are genuine cases in which system behavioral testing is vital, even if zealots wish for nice little black boxes, it's not the real world 100% of the time. integrations of various kinds require intelligent and nuanced test harnesses, and just seeing green in a test runner can be misleading.

[@raymundenso]

If TDD is not creative... When you do Refactor part you can be creative on how you implement it and does not break your test.

[@aliencommander]

Hey Dave, love your videos. Do you have a quick suggestion as to how to use TDD for SQL projects?

[@nivoset]

I know these side effects are where i "mock." But for me, it is a constructor i can pass a suitable fake db/api interface. Where i pass a one-time use call, instead of mocking the external. I find it much easier. All other things i let fly through on pure functions. Which is most of the code i try to write

[@richbuilds_com]

@nivoset you don't test the sql directly. You test the result of the query matches your requirements. The query might change as you're refactoring but the requirement never does. What if in your final round of refactoring you realise you don't need a query at all? (I.e. you don't test implementation. You test results)

[@eric-seastrand]

Doesn’t that mean you need a database instance pre-loaded with test data in order to run your test? Won’t that make your tests super fragile? Tips on applying TDD to these scenarios?

[@richbuilds_com]

​@@eric-seastrand No. You don't need to test if your database works. You are only testing your code and how it interacts with data. You would test your SQL separately to your code (the query might change but the data it returns does not) - and you can unit test this with a test DB, but once the query works, you unit tests just use "dummy" data. OR Yes. You can write tests that don't need a database rebuild every time. You insert the data your test needs when the test needs it. So long as this doesn't affect any other test. I'm using a test db on my current project (an ORM layer) so the DB interaction is critical to my testing so I test alongside my queries. So, for example: I need to change a query to return some additional data. I change the query. Change the test that checks my query works. And (now magic happens). When I run the remainder of my tests - they tell me *exactly* which bits of code now fail because the query changed! In a fairly large code base you are bound to miss some of those edge cases. This is why TDD works. I don't have to worry about code OR schema updates any more. I've got it covered. It gives you massive confidence when it comes to estimating fix / feature timelines because you don't have that nagging doubt you've missed something that's going to come back and bit you at 4:40pm on a Friday...

[@nivoset]

@Richard Allsebrook then i remove the mock? Though that rarely happens as the code i am testing where i mock this tends to be actual api/db calls as that is the section i test. I mean, it is only there as it is needed. I dont test it was called, so even with it not called. As long as i get back the right response, i think the tests are fine. I'm not saying it's perfect. I want a better way, but spinning up a db always took a lot of work and rarely helped more. My db is fully typed, so mocking it isn't going to add or remove excess data without lint errors.

[@Robyo12121]

12:06 Where is the link to the free TDD tutorial? Not in the description.

[@ContinuousDelivery]

Oops, sorry, and thanks for the catch. I have added it to the description now, but you can find it here: courses.cd.training/courses/tdd-tutorial

[@imqqmi]

ADD vs TDD, Assumption Driven Development. I've met a few of those elitist developers that say that debuggers and unit tests are for juniors. While they say that, I've fixed bugs in hours vs they spent days and gave up, blaming the spaghetti code. They seem to think they know how to program so well they don't need to check for edge cases. Testing and confirming is better than assuming.

[@FerrixHoviComedy]

I have been mostly wondering how to assign 2, 3 and 7 to the shirt Venn diagram. Universe and everything are definitely 7, but the others are more difficult.

[@ericplante3237]

I understand the merit of Unit testing in general and finally got a job that let me gain xp and explore the topic. For now, I do code first and wish to explore TDD but I have concerns. It would take too long to list them all but my main one about TDD and Unit Testing in general is that they introduce code that is there juste for the sake of testing therefore, polluting otherwise very good production code. Anyway, do you have something like a Discord channel where I can post my questions and concerns so I can get more point of views and feedbacks? So far I only have my xp and easy examples from the net that doesn't reflect reality.

[@ContinuousDelivery]

I do have a Discord channel, it's available to Patreon supporters: www.patreon.com/continuousdelivery I answer questions here too though, If you are adding things to code only to support your tests then I am afraid that you are doing it wrong! TDD is ALWAYS test first. You drive the development from the tests. One of the advantages of that is that it forces you to design for testability, and testability shares a lot of properties with what we generally consider to be "good design". You should NEVER build back-doors into your code to support testing. Never compromise access, (make something public that should be private), and never attempt to access private or protected things from a test. Forgive me, but I would argue that if you have to do this to test it, then it probably isn't "very good production code". Testable code is modular, cohesive, has a strong separation of concerns, good lines of abstraction and manages coupling carefully. It has to be these things, or we can't test it effectively. I'd say that if your code is more module, cohesive etc etc than mine, it is better than mine, so that is why I suggest that there is probably room to improve your prod code if it doesn't exhibit these properties.

[@ericplante3237]

@@ContinuousDelivery I'm not saying that TDD doesn't follow all the good practices because it does but you re still using interfaces and injection just to make classes easier to test which wouldn't be necessary otherwise and still follow all the best practices with less noise since the production code doesn't need what testing needs and still testable, just more difficult to do so. Unless the company uses an injection framework for their code, code first will often test by looking at private values to test results and mock external instances. Obviously, I need to practice TDD because theory and practice are 2 different beasts but the impression I have is that either alll methods will return something or injection will be done. One aspect of TDD that I find apealing, though, is that the mental process is validated immediatly instead of only being revised at the end of coding but I fear what refining my architecture can do to all those tests already done.

[@ContinuousDelivery]

@@ericplante3237 Well I'd see that very differently. I am not doing those things "just to make the code testable" I am doing it, because it makes the code better designed. I am adding interfaces to improve the abstraction in my code, and injecting dependencies because that improves the separation of concerns and promotes better modularity and cohesion. That's what I mean by "TDD amplifies our talent as designers".

[@ericplante3237]

@@ContinuousDelivery Do I understand correctly that you have no problem using an interface for a single class just so you can inject a mock using that interface when testing? Between property injection and method parameter injection, do you think there's one that is better than the other? When I'm facing with the idea of injection I'm often confronted with that dilemma and I'm never sure what to choose. I usually prefer passing them by parameters to not expose properties but mixing them with fonctional parameters makes me uneasy.

[@softwaretestinglearninghub]

Great video, thank you!

[@ContinuousDelivery]

Glad you liked it!

[@pixelslate9979]

First "It's really 'Specification-Driven Development'" and then later "It's really 'Test-Driven Design'". J. B. Rainsberger

[@Fitzrovialitter]

Please elucidate.

[@leojboby]

How would you even go about automating CD if you can't automate regression testing, that is a practical reason why i dont see a way around it. Perhaps there are better ways? But how else do you exhaustively test that you didnt break anything too obvious. The bigger the project, and the less familiar you are with it, the more forceful this question becomes.

[@orange-vlcybpd2]

When you ever questioned the code you wrote or were about to write, you have been one step away from writing tests.

[@ProgroOvonzodo]

Code coverage! It's free real state

[@bobbycrosby9765]

As someone that doesn't practice TDD, I think the best argument for me is that - if you need tests anyways, TDD basically forces you to have them. I don't practice TDD, but I'm still thinking of tests as I design the code, and I write tests that exercise the public interface of a module shortly after in order to test the code. I don't think I'm smart, I just think it's pretty obvious if you aren't writing testable code at this level of granularity. Edit to add: in particular, even when playing around with TDD I've never been a "microtester". As in, I have never written exceedingly small unit tests. Again, I test public interfaces of modules. A class is not a worthwhile definition of a "unit", and focusing on them as your unit leads to testing implementation details. IMHO of course. I also follow "Chicago style" test automation. I could see TDD having more value if your units are smaller, and/or you practice London style. But for the software I write, the size of my units, and the way I test them, the designs just aren't that gnarly.

[@tongobong1]

Yes Chicago style is good. London style on the other hand is terrible.

[@lkyuvsad]

@@tongobong1 can you expand?

[@evancombs5159]

@@tongobong1 can you explain the difference between the styles?

[@tongobong1]

@@evancombs5159 find explanations with google.

[@ContinuousDelivery]

I have a video that does just that! kzbin.info/www/bejne/lYSYmoicZaaBr7M

[@maurizio_italy]

I have that t-shirt too !

[@InfinityDz]

I tried doing TDD while writing an emulator. I dropped TDD and just focused on the emulator. I felt rather stupid writing tests for trivial lines of code. I believe in debugging, critically reviewing my code in order to improve it, and in the premise that good code is usually the fastest and shortest (with the motto that "Perfection isn't achieved when there's nothing more to add, but when the're nothing more to take out"). Of course if I have to test something that would be tedious to verify manually I'll write a test, but I don't make it a point to write a function that verifies that add(3,5) is indeed 8. Maybe I just still don't get TDD, but I'd like to.

[@qj0n]

My advice would be to test bigger chunks of your code or whole features. I think i became good at TDD after reading a book on BDD. We don't use cucumber language or don't share test results outside of dev team, but it influenced the way I think about tests. I developed simple parser for reverse engineered format with TDD and I think it's a bit similar case to emulator. I prepared a bunch of inputs and wrote manually their corresponding outputs. Every time I found a new corner case i added tests. So not only I got the parser, but also a documentation for reverse engineered format (at least how I understood it) for future developers

[@tongobong1]

Yes the strict TDD sometimes feels so silly... You should skip the silly parts and write a test for the basic functionality that makes sense first. When you implement the functionality so the test passes then you should write tests for edge cases and fix the implementation so they all pass.

[@gJonii]

The big thing that helped me to "get" tdd is that each test is you writing a program that does something useful to you, and you're allowed to use code that does not exist. The only limitation is, you need to check if the program you wrote did what you expected it to. The difficult parts are answering "what program would I like to have", and "how do I know the program did what I wanted it to". But if you think about it, these are really helpful questions to have an answer to. I've never written emulator but I guess I'd start out by asserting I have components that behave the same as in the original system. Not sure what kinda components there are, so can't go into any details tho. Also, you can remove tests or change them if they don't serve a purpose.

[@hmtnl]

The question is not TDD is good or bad, but rather where do we get that t-shirt

[@ContinuousDelivery]

The T-shirt company is called Qwertee, and they have a special offer EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! 🔗 Check out their collection HERE: bit.ly/3vTkWy3 🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

[@hmtnl]

@@ContinuousDelivery Thanks

[@GBlunted]

I wish you would leave the tweets on the screen long enough to comfortably read them and not have to rewind or pause the video to properly consume them - especially the longer tweets...

[@fulcobohle4576]

Start with writing the software that test your test software, and then write the software that test your test software that test your test software that tests your software... you get it ?

[@barneylaurance1865]

The test software tests itself - or at least it tests its own ability to pass. To test its ability to fail, firstly you can just run it before you're written the software under test and see it fail, but to have a more robust system of testing that it can fail you can use a mutation testing tool.

[@f0ssig]

Another video that can be summarised with "No true Scotsman". TDD is dogmatic because it's a set of strict rules we should follow based on what the authority tells me to. If I'm questioning it, or not seeing the same benefits, then I'm simply not doing it right. I should "try harder" and have a "skill issue".

[@MatthewChaplain]

13:28 That's it. I'm famous now. I can finally rest.

[@jimdopango]

Describing TDD as a 'tool' is questionable, I think. There's a big difference between a square rule and TDD: one is an inert thing that you control and use to get information about your work. The other is a prescriptive set of norms that control how to do your work - it imposes a sequence of steps and it forces you to see the object of design through a very specifically shaped 'slit view'. Some people feel comfortable and productive looking at things that way and performing the ritual of TDD. Others would prefer to look at the object of design from afar first and only gradually shape it into something that can be exercised in its specific micro-interactions. I agree that we all want testable designs, that's a given. But TDD is definitely *not* the only (economical) way to get to that outcome.

[@ContinuousDelivery]

Sorry, but that makes no sense to me. First how is a test not "an inert thing that you control and use to get information about your work"? That is exactly how I use tests in TDD. Next, it sounds to me as though you haven't done much carpentry. "Measure twice, cut once" is at least *as* close to a "proscriptive set of rules" as "Red, Green, Refactor" and there is more to the guidance of using something like a T-square than that. You are supposed to pick, and stick to, a single reference side as a baseline for all measurements for example.

[@jimdopango]

@@ContinuousDelivery A test is definitely an inert thing, it's a tool alright. TDD isn't. I write tests all the time, and I design my systems to be testable - but I do not do TDD. As for the "measure twice, cut once" exhortation from carpenters, I don't see it at all as akin to a system design discipline like TDD. "Measure twice, cut once" is pure tactics. It's an energy saving technique, it says nothing about the design of the piece being produced.TDD on the other hand is a strategy, it prescribes a sequence of *design* steps, not just implementation acts. Like I said, some people feel comfortable following that strategy and are happy with the resulting designs they produce that way. I'd say from what I hear that some people even cannot think of any other way of getting to those good designs. That's ok, I don't see anything wrong with that. What is not ok is saying that TDD is the only, or the best way of getting a good design *in general*. That's just not supported by any evidence I've ever seen. There are many examples of extraordinarily well designed systems out there that were produced without TDD.

[@evancombs5159]

This is being a bit pedantic don't you think?

[@jimdopango]

@Evan Combs maybe a little bit, yeah. But I suppose one man's pedantism can be another man's push back against muddled thinking and unwarranted maximalism.

[@gJonii]

While I'd agree with this channel a lot on the value of TDD, I think you have a point, but it's not really clear enough to me to comment on the validity of the point. TDD forces a very specific, narrow view on design. That is to me the allure of the ritual of TDD. It does open the question of, "are there equally good alternatives", which you posit exist, but I haven't really seen. You say that TDD goes into details which to me is a bit misleading. TDD as a design tool goes into the part you want to test first. It can be "can you run a program" or other quite far-view type things. I've noticed that despite having this freedom, I usually go straight to the details at a level one-to-three-paragraph summary of the problem I was solving would go at. I think I do often go more into details at first, I usually err towards more specific as usually first tests I'm writing while I'm also figuring out the details. But ultimately, TDD doesn't seem prescriptive in this manner, you're free to choose a level of abstraction that feels natural to you. Also, projects I do often have information gathering phase where I'm not writing code but just collecting information about the problem domain. So with that, while I agree that TDD is a rigid ritualistic approach to design, and not merely a tool, I think this ritual doesn't have the limitation on the level of abstraction you speak of, and I do not know what alternatives you know that provide similar quality to design. Also, one caveat I kinda want to pre-empt is that to me TDD is a happy path, special case of a more general "need first" driven design, where you write implementations only based on existing use of that implementation. Say, tests use an implementation, so you write implementation after there's a test that requires it. But a common case where this fails is user interface, your need is no longer based on code that uses it, but an user that wants to do something. Usually TDD directs you to make this layer interacting with user quite thin, but regardless of how thin it is, this layer doesn't really allow TDD, but the more general principle of need-first driven design still applies.

[@maxron6514]

TDD: is annoying to learn, costs time, then finally saves time and first and foremost prevents the developer from writing bullshyte. That is, when the developer finally understands it. Many cannot or simply do Not want to.

[@maxron6514]

my real world experience with others and also myself.

[@tomaAlex2001]

TDD is a beautiful approach to developing software, but as far as I can tell until now, in the javascripty hacky startupy kind of world, TDD is an overkill.

[@bernardobuffa2391]

my major concern about tests is how do you know your tests are good and that they prove what they should prove... do we need meta-tests?

[@hermida]

Of course TDD limits your creativity. Think of all the times you had to find extremely creative solutions to test after writing the code.

[@adambickford8720]

Stupid reflection tricks and monkey patching, here i come!

[@ContinuousDelivery]

If you are "finding solutions to test after writing the code" it isn't "TDD". "TDD" is by definition "Test-First".

[@nivoset]

Need the sarcasm tag i think

[@gnarfgnarf4004]

TDD seems so tedious. You wind up spending as much time developing, as traditional methods. Show us some examples. You drone on and are not inspiring. (I've been programming since 1965. Looking to get motivated in TDD).

[@ContinuousDelivery]

Actually you could consider TDD a "traditional method" it is how NASA wrote the software for the Mercury programme in the early 1960s and it was described by Alan Perlis at the first ever conference on "Software Engineering" in 1968.

[@soainpractice]

Even ChatGPT is able to do "a kind of TDD" - the following question would result in a class implementation which passes the given test case: " Given the following Java test case: @Test public void testDayMonthYear() { ImmutableDate date = new ImmutableDate("2023-02-23"); Assert.assertEquals(11, date.getDay()); Assert.assertEquals(12, date.getMonth()); Assert.assertEquals(2018, date.getYear()); } please, generate the immutable class called ImmutableDate to make this test happy."