I say that the biggest compliment you can get as a software engineer is when your fellow colleagues tell you that they had to work on your code and they enjoyed it.
I can agree. bc I have a lot of experience with the opposite. people no longer with a company that I wanted to sue for having to maintain and rewrite their code! 🤣
I've seen "experts" claim that you TDD the frontend by doing e2e TDD 🤣 bye bye quick feedback, hello brittle tests (the opposite of what you try to achieve in "real" TDD)
This. This is the greatest barrier imo. I'm working in a small team and trying to bring tdd to our new angular app. I have nobody and nowhere to go with my questions, doubts etc. And my very specific problems aren't usually covered in simple examples found in online tutorials
@@krzysztofprzybylski2750 if you try to bring tdd to a team and you don't master it you should forget about it. People will be convinced one you show them how it works and how fast you implement stuff thanks to this technique. I've been guilty of the same stuff when I was younger, believe me. Improve your practices and then try to bring them into new teams. Or quit your job and join teams that practice well already (hard as f..k imo)
For me the change came a few years ago, when I was part of a small team working on a project where management was not interfering and we were free to develop code in any way we want, provided that it worked. That was not the first time I had done TDD, but it was the first time it clicked for me. Just that freedom to work on just one piece of the whole code and not have to constantly keep checking if I haven't messed up something else! And the feeling when I go home Friday evening and not have to think about all the bugs that are waiting for me to fix next Monday - that peace of mind, that is priceless! Now I like to repeat what I once heard someone say: TDD is only important if you want to be able to trust your code. It gives me that strange fuzzy feeling that maybe writing good code is not that difficult after all... or as Kent Beck has said, I am not a great programmer, I am just a good programmer with great habits.
I haven't done proper TDD but I think I'll give it a shot. I do know that feeling though. My habit is to write the feature one small piece at a time, verify each small piece manually, and then go back and write tests for all or most of the edge cases I can think of. I know I've written enough tests when I feel like I can trust them, if that makes sense
I think tdd as a mindset has been transformative.Writing useful and reliable tests is the key, just trying to fulfil code coverage is a waste of time. I think people mistake tdd for unit test coverage in my experience
I have one similar story to Farley. I was practicing TDD for a while, but it was mostly me learning on my own what to do and applying it at work. It wasn't until I joined a company that had enough good practicioners of TDD (in my case was Codurance) that I did not elevate my understanding. Having people to guide you is such a massive boost.
In most work places they've heard about quality code but they don't care. They usually just talk about it during an interview. It's such a lure for new hires.
Why hasn't TDD taken over the world? Easy, the problem with TDD is that almost all examples you can find is either not applicable on the real world (.e.g. FizzBuzz), are needlessly testing underlying runtime methods that we can assume is already working properly (like String.length and Integer.parse), or are testing built in arithmetic such as if(50 == 50) that will only fail if your CPU hasn't got enough thermal paste.
The drawback of TDD is that it extends development time by a factor of however many functions you have and the amount of possible inputs and outputs. Useful for making close to perfect software but impractical for business.
That's only true if you assume that your speed of development is proportional to the speed at which you type. I prefer to optimise for thinking rather than typing, so TDD is a lot faster for me.
If you find yourself saying “You’re just not doing it right” every time someone brings up an objection to your favorite way of doing things, I find it’s often more profitable to take a closer look at the practice itself: maybe everyone is doing a practice wrong because it’s *difficult* to get it right, and maybe that actually means that the practice itself is less valuable *because* it’s so difficult to get right. I would argue TDD is one of these things. A powerful tool in well-practiced hands, it’s easy to misapply and get wrong. It does not create a “pit of success” for practitioners to fall into, but rather a mountain that must be climbed. This is a demerit against the practice. Not a statement of how everyone else is just incompetent or misinformed.
I've never accepted the idea of Test-Driven-Development. When I see civil engineers sit besides a stream and start a bridge build testing it with twigs before they move on to sticks and eventually ends up with concrete and steel (as we all knew they would) when they want to build a 4 lane bridge I may accept the approach. It is almost like software developers hate themselves or don't have respect for their own trade. I NEVER make tests first. What I really want are tests to verify the code AFTER it is finished to make it easy to maintain AFTER the code is doing what it is supposed to do. I call it Verification-Assisted-Maintenance. The tests are there solely to verify the code is still working after someone has fiddled with something in the codebase. I've also NEVER seen civil engineers sit together to verify each others work like we do in software development with peer-review. Again: It is almost like we all are amateurs just poking around and jabbing in programming statements until they work. We don't behave at all like other trained professionals that knows what they are doing.
You would be amazed to discover that about 90% of all programmers have precisely this poking around approach to coding. They twiddle with code mostly senselessly until it works on their desk. This is quite detrimental when in esp. interfaces to complex library mechanisms are involved that actually require full understanding of the semantics to make the code work robustly.
I've stopped calling TDD as Test-Driven-Development... for me, I think a more accurate name is Test-Driven-**Design**. You raise something along these lines around 9:40. My rationale for this is that TDD helps me naturally write better designed software. I think a maxim we can all agree on is that well designed code is easier to test compared to badly designed code. Learning to build software via TDD was almost like learning a brand new skill adjacent to software development. I can't imagine another way of building software that I'm prepared to put my name against.
When I was writing my book "Modern Software Engineering" I wanted to write some bad code to demonstrate poor modularity, cohesion, separation of concerns , abstraction and coupling so that I could de-construct it in the book. I started as I always start, with a test, and quickly found that it was impossible to write code that was as bad as I wanted with the tests. I had to make the code untestable to make it bad enough, so I dropped the tests, then it was easy to write terrible code. I think this says something important about TDD - what else does that for software?
On that last point about job security - I have a story. Long long ago ( early 1990s ), I developed an extremely simple way of doing a large portion of design & programming for a games company I worked at. The company specialized in flight simulators, and the part I optimized was where the user would set-up scenarios - e.g. weather conditions, airplane models, number of opponents, etc.. Up to that point, it took a full 1/3rd of engineering effort to create the scenario-builder. I introduced OOP along with an extremely small and efficient library to assemble the various screens ( usually a forest of checkboxes and radio buttons ). A couple of non-engineers - an artist a producer were able to create virtually an entire scenario builder, only requiring a small amount of engineering to hook-up the scenario onto the simulator input file. ( and, I was working on eliminating THAT ). They were amazed and anxious to use the system ( and another group of game designers started prototyping using it as an accidental side-effect ). I was told that other engineers were nervous about the system, and expressed all kinds of concerns - hinting that 1/3rd of the engineering staff may need to be let go. I was pulled-off the prototyper, and transferred to mundane stuff - and was gone from the company within 3 months. That company died long ago, and that attitude probably hastened its demise.
I’ve used TDD for many years and would say I’m addicted to the fast feedback loop. However, I also like the patten ”Spike and stabilize” coined by Dan North, which also is about faster feedback, however on a different level. We deliberately defer the decision on quality to learn faster whether code has any business value in the first place.
We have spoken a lot about this topic, but I think that TDD is one of these things that needs a good teacher to convince a company to redirect that ship. I have seen too much cases where a poor implementation of TDD was enough to give up and go back to cavern programming. Good episode and keep pushing with this kind of videos I hope they reach the right people.
The difficulty I have with TDD is that all the tutorials focus around very simple problems that have predefined input parameters and expected output parameters. The usual example is a calculator, thats easy. The interface is already very clear. Where as with most of the stuff I do, I am given a feature request, but the implementation has no clear interface, and I'll often experiment with different implementations until I come up with something that works well. To me, TDD is not much help here. It's more productive to edit the code in the actual app to see how things could work. I should add that my work mainly is in WPF applications, so mostly UI
I see it similarly to you BUT honestly, TDD is more like a playground for me. I do mainly backend stuff and I’ve recently tried to get into working with TDD. I don’t do it as strictly as red, green, refactor. But for me it’s a great way to just try stuff out! Writing a test allows me to press a button and run a small part of code from a larger project. So I constantly go back and forth between production code and test code and expand either side a bit until I’ve really figured out what my input is and what my output should be. And once I figured that out, my production code is basically 80% already there. And since I used a test to guide my coding, I’ve also made the production code ready for unit tests, since I had to think about mocking and so on. Without starting tests first into a problem, I would have never thought about mocks. And trust me, I’ve spent SO MUCH time in the last few months rewriting code since without TDD I didn’t think about testing and now I’m stuck with production code that is untestable and needs heavy rewriting.
That is one of my problems also, TDD proponents, most of the time, only demonstrate how to do it, using simple examples, mostly unrelated with what you would find at you job or more complex projects. Another issue is, it's always your problem if you can't understand and use it, TDD is a silver bullet and you are the idiot unable to wield that gun ...
My biggest complaint about TDD is the notion that tests should be written first -- and often I don't *quite* know what I'm working on yet! Creating tests in the exploration stage hampers my ability to get into a "groove" where I start to understand the problem, and thus can create the tests the problem needs. I have found, however, that once I'm on a roll with the tests, and particularly when I'm nearing completion of the feature in question, that creating good tests can help uncover edge cases that would have otherwise been overlooked!
IMO you should write descriptions before the actual tests, i write the skeletons of expected behaviours first, so that my implementation does not influence my description of the underlying spec, then i play around with ideas for implementing it, then i fill out the test, mocks and spies necessary making sure it's as generic and independent from the concrete implementation as realistically possible and then i clean up the implementation
Fun fact: I had a boss that completely misunderstood the term "Extreme Programming" to mean that we should _literally_ be extreme, so he enrolled the entire team (there was just 3 of us) into taking Pilot Licenses and paid for the theory and exams. For some strange reason we all failed to protest and correct him, and unfortunately I couldn't afford the flight hours required for the license, but we had fun times :P
13:27 > There isn't a a specific technology nor a a a type of software that I've come across that isn't amenable to TDD in my experience I think this fails to take into account those who work within a framework bubble. This is what happened back in 2014 with the Martin Fowler, Kent Beck and DHH debate. DHH claimed that TDD caused Test-induced design damage. Of course he made this claim as a framework author who designed his framework with a certain work flow in mind; a work flow that never considered including TDD. And to a degree I see the same thing happening in the React space (and perhaps within the larger movement of so called component-orientation). While there are boundaries between components, within the components traditionally distinct concerns are readily blended. This lead to the creation of testing frameworks (e.g. Jest) with features to support testing these framework components which are invariably slow given the concerns that are mixed within these components. Meanwhile a whole new generation of developers learn testing with the capabilities of these tools, being left with the impression that using tests is about correctness-not that tests are feedback machines. Microtests detect unwanted change. They don't verify correctness. This situation is now further being aggravated by a movement to start using AI-tools to write tests for the developer-which is completely missing the point.
The greatest resistance to TDD I've seen comes from those who are used to working (mostly) solo on short projects, and who are intelligent enough that they (mostly) get their code working on the happy path quickly. Tdd feels like overhead to them, since they "design in their head", or by rapid prototyping with few safety nets. That's great and all, but it's difficult to help them get through implementation work that way.
That's not necessarily the case. Even if you work alone TDD and CI/CD helps you actually save time. It will also save time when colleagues have to do builds and have to follow a simple short documentation. Starting a script which executes everything is hardly beyond anyone's skill.
I made a project involving some maths before knowing how to unit test, and ended up with buggy maths, unit tests can be really useful, as regression tests or just as technical documentation
Yes I think id fall into the category you described. What do you say to these people? Maybe it’s an ADHD thing but I’m big on exploratory problem solving where I’m just getting in there and coding before I know what I’m doing. I’m just starting to scaffold out the right ideas and once I understand the code I want to write, then I can write the tests and code in either order it doesn’t really matter. I don’t see the benefit of TDD except for developers who like it. If it feels good for you then go for it just like any other DX thing.
I agree with this one. "Too smart for your own good", who needs methodology, order, and consistency when you have unlimited brain power right? At some point in time, I think Software Developers realize that they are not coding for themselves, is always someone else or your future self. One day the problem exceeds you, if you are chasing the right problems soon it will, and you will love to have methodology, order, and consistency... some days, the unlimited brain power machine won't turn on or will need some hours warming up to turn on.
@@judgemental_coder okay someone please explain the TDD superiority complex. “You’ll want order eventually” is such a weird critique because obviously anyone that spends time coding is going to develop methodologies for coding. What is the benefit of the design process necessarily starting with writing a test? We could write code with infinite variations of design processes. If TDD feels good for you use it. Sure. but are there any real reasons why it’s objectively better in any way?
On point 2: Better, more flexible, more readable code... I have to say that I've heard this a lot since the early days of Martin Fowler and Clean Code, and generally speaking I disagree with it. The most readable code is often the least flexible, it does one thing and does it clearly. There's a long debate about procedural vs functional vs object oriented code, encapsulated and decoupled vs tightly coupled code, and depending on where you did your career work, your opinions are likely the polar opposite of other people in different careers. I think there's no question that tightly coupled code is less complex than decoupled code. It takes less time to write, less effort to follow, there are fewer places where a problem could lie. Programmers and OO specialists often talk about information hiding and encapsulated functionality as if it's a good thing, but rather than good or bad, what we can say is that it adds layers of complexity to the whole project. If you only see the outer layer, then the project will look simpler. But if you have to look at all the layers and follow code flow, it often gets so complicated there's almost nothing you can do except break out your debugger and follow along to see where it's going. Encapsulated code is often effectively impossible to reason about, unless you're the person who wrote it. In that respect, I have found that consulting firms often love it when their developers write code like this, because it's so abstract that you cannot maintain it. Even with testing in place, they might be able to say, "It works as intended!" but it's so complicated that there's no way to falsify the claim that it is working as it should. And that to me is the most significant danger of going down this rabbit hole: You have to write modular code and break apart functions until they are testable, so that they fit into the TDD model. But at that point, you might have taken a 5 line process and decomposed it into 12 different functions, there's no longer any discernible code flow, but you can proudly claim it works exactly as it should... Until what it needs to do changes. That's not to say that you cannot find success with some of the TDD ideas, or you should give up testing altogether, but I think by far the simplest reason TDD didn't take over the world is that TDD makes your code much more complex in order to make it testable, and that regular humans (who most of the programmers you hire off the street will be) are not going to be able to find success working on a project that's got pages and pages of business rules broken out into thousands and thousands of lines of decoupled, flexible code. But programmers cannot even agree on the definition of complex (literally: "consisting of many different and interconnected parts") and simple (c.f. simplex: "composed of or characterized by a single part or structure"). The fundamental lie of Object Oriented programmers and the Refactorers and Decouplers is that we should not write Simple code because it's too hard to maintain, which is almost never true. We shouldn't always write it because it won't help us get our job done, often times we do need complex behavior as an end result but many TDD people go straight for the most complex possible solution so that every line of code they write is "encapsulated", "reusable", "decoupled". And it's just a mess.
Interesting questions. Some $0.02: A. Software is usually developed within some economic context. Decent tests significantly add to the cost to develop a piece of software. Often the business context is uncertain initially. E.g. "we just want to see if something is possible/how it looks/show something quick to a prospective customer". This means that if you pound the table saying that you need to write your tests first, the business owner is probably going to fire you and get someone who is fine with hacking away with no tests initially to do the work. Often tests get added later, if the code turns out to be used in production/sold/have some value. In this context any plan to write the tests first will clearly fail. B. Commonly used test frameworks were developed by folks who had some particular idea about how they wanted to run tests, usually the arrangement is to run the test code "in-process" with the code-under-test, written in the same language, with some added salt and pepper about how to report results, inherit from some base test class, and so on. This is only the right way to do tests for some scenarios -- generally when the code you're testing is being shipped as a library, to be consumed by some calling code that runs in the same process. But lots of software isn't like that. It's providing a network service or indexing large volumes of data across a cluster, or whatever. In my experience developers today just disable their brains and blindly plough on writing tests that are not really useful tests, just to fit in with their test framework-du-jour. This discourages clear thinking for TDD because there's no direct link between "what the thing we're making does" and "what I put in my tests". It's all a dreamscape of mocking and nonsense (in my experience).
Nobody on the business side has to know about testing, but I really find that TDD is fantastic for those "just want to see if something is possible" scenarios. Its the fastest way of just playing around with code until you get something you like. If I wasn't writing tests, I'd be checking results manually which can't possibly be faster than running a test.
A does not have to be true, as explained in the video. Writing a test case isn't more expensive than writing any other lines of code, and usually in my experience it actually ends up with less time spent rewriting incorrect code - if you don't write tests, the only way you can test your code is by running it, finding out it doesn't work, then re-writing it until it does work. If you can write you code perfectly first time then sure, don't worry about tests, but nobody can do this, so it's a false economy not to write them, and it's generally much cheaper to write them first because you don't end up writing tests which end up tightly coupled to the implementation details and full of mocking - which leads into point B: TDD when done well in my experience helps to avoid the problem you talk about here with over mocking because it becomes very quickly apparent if you're having to add a bunch of mocks in order to get your tests to pass, and you can try different approaches to minimise their use. This is something that needs to be learned, it's not immediately obvious, especially if you come from a background of writing tests after where sometimes extensive mocking is the only way to retrofit tests into poorly designed codebases.
@@QmunkEI've also seen lots of over-mocking, not just with existing code, but also with people's own code when they code then test. Of course, all the tests they see are like this, so they never learn any other way to do it.
Because software _companies_ hate testing and QA, _not_ software developers. Testing & QA are only cost centers for a SW outfit - good QA never generates revenue (much less a profit) and no SW company has ever bothered to try to learn to sell it. They only care that the product is in at least an MVP state at GA release time (always 5pm on a Friday) - barely functional enough to close the deal with the victim/customer from quarter to quarter. I was in QA for almost 30 years and in that time I never worked for an outfit where QA and testing were anything better than an afterthought constantly on the brink of starvation, that the place was dragged into kicking and screaming, because "hello world" didn't work in one of their major releases. SW companies don't care if their products are crappy; only developers care about that. Not complicated....
Most critics of TDD I've spoken with never tried it. They just repeat all these arguments discussed by Dave which they've heard somewhere. Or their arguments are more against testing itself than TDD. At least they are afraid to say "we shouldn't write test because (for example) they slow us down", as even non-technical managers understand importance of testing. Instead they use the same argument but replace testing with TDD. And I completely agree with Dave. Testing is not the goal in itself. The real goal is to write better software.
I have a much more reasonable explanation for that: TDD is a practice that does not fit in every single problem/solution domain as proponents like Dave insists. It's not a silver bullet: actually, it works well for the context that Dave frames over and over on his videos - relatively small projects, generally as a tool when designing the core logic of a micro-service, without touching too much infrastructure. Unfortunately, real world Software is much bigger than this. Arguing that one can easily do embedded programming, Mobile/Desktop/UI programming, IaC programming and others with TDD is a total unrealistic claim, since it's extremely common that the tooling itself jeopardize the (expected) fast feedback loop, making TDD unfeasible. Been working with Mobile Engineering in the past 10 years, I followed advises similar to Dave's and when I finally was ready to try TDD in REAL projects, slow compile/build times made it just impossible. Another example are large repos with thousands or hundreds of thousands of tests (eg, mono-repos) : you can assume that all of them are the outcome of TDD if you want, so there are no useless tests out there. As soon as one suffers with slow feedback loops when trying by-the-book TDD, one realizes that something different is needed. Another example are mission-critical applications and low-level software, where performance matters a lot and good performance usually means non-orthodox software design decisions, eventually exploring the boundaries of our own programming languages, the underlying Operating System, or opt-in into "bad practices" like shared mutable state. Can TDD spot non-orthodox decisions when the goal is to meet Security/Perf requirements? Sorry, but in my experience, the answer is no. Nevertheless, TDD is a practice that assumes that Engineers know few stuff (or nothing) about a particular problem/solution domain. Such an assumption may work for entry-level JR Engineers out there, and maybe for consultants, but definitely will fail for experienced Engineers working in the same industry domain for several years in a row, specially when specializing in sub-domains: we can think here on an Engineer working for 10+ years with Quant/Trade systems in different companies, or an Engineer that focused on compilers and tooling for his/her all life, or even Salesforce developers, and many other examples. Thinking that such experienced Engineers won't bring their own background on a given (sub) domain to the table, exclusively delegating design decisions to the outcomes of TDD / pair-programming sessions is naive at most and unrealistic at best. Also, Dave's claims on TDD have a built-in hidden assumption on pair-programming / TBD, ie, they assume up-front that the emergent design from a TDD process won't be reviewed, scrutinized and eventually rejected by other Engineers involved in the social technical context. Dave ignores that gatekeeped Code Reviews (eg, via PRs) are the default standard in our industry, and that such a process is not necessarily friendly to by-the-book, clean TDD. Is TDD something it's worth learning (or at least try)? Definitely yes. Is TDD something you want to use if the social-technical context allows to? Definitely yes. Should people push for TDD regardless the social-technical context, like Dave recommends? Definitely no.
I’ve tried out NUnit and GoogleTest at my last two employers. Regression testing is definitely useful but it is rarely the unit tests that break. It’s almost always E2E tests that fail under unforeseen circumstances. However, that’s not because TDD ASSUMES that developers know nothing about the domain. It’s because the software evolves and no human can possibly keep tabs on it over the course of months and years. However, the TDD approach to development is not about testing. It’s a design methodology that enables software to be tested using these OOP testing frameworks. If you simply go through the Red-Green-Refactor steps that Kent Beck talks about, it doesn’t really need a testing framework but rather thinking through what the requirements of the component are, adding test drivers fir that functionality, and then implementing the component and bridging the gap between the tests and implementation. That puts you into the perspective of a user first. However, I agree with you in practice this is no silver bullet because the real assumption is that you as a programmer understand how the user will want to use the software component you’re putting all these tests around. At the unit level, these are usually sound because you are using your own components but once you get to the system level, there’s too many assumptions which break and performance certainly supersedes feature factories in many contexts. Basically, the only real achievement of TDD is that component regression tests are brought at the design stage. However, these are never sufficient for system level tests, regardless of whether it is an embedded project for manufacturing, a server side backend, or anything that involves more than a small group of close-knit developers who are always there on the project. In recent years, I’ve come to realize that big companies who have TDD and such practices still face similar problems to any place that doesn’t have them. Most real issues are discovered in production or by users.
I'm surprised that there wasn't a significant set of developer responses talking about the difficulties of implementing TDD in a legacy code environment. That's where most of us work, after all. In my experience it's not so much that the developers are resistant to ideas like TDD, they just can't figure out where to start! If a software company has been going long enough that it is making money, then, by definition, a lot of its software will be classed as 'legacy' by its current developers. And unless that software was originally written, 5 or 10 or 20 years ago, in a way that makes it easy, or even possible, to wrap automated tests around its units, implementing ideas like extreme programming and TDD feels somewhat daunting even if the developers would absolutely love to do it. Without performing significant surgery on your commercially successful, maintenance headache of a product, without the safety net of a decent suite of automated tests, or even a coherent suite of documented manual regression tests, you're not going to get your spaghetti monster into TDD-able shape anytime soon, and you'll struggle to get budget signoff to even try. You could still write your tests first before you make your changes to the software - but you'd be writing your pre-conditions and assertions on "paper" and executing them manually every time. There might be some merit in doing that, but would that really TDD?
There are strategies to improve it though. I don't recommend arbitrarily adding TDD to legacy code, you have to do it carefully. Here are a few thoughts... ruclips.net/video/_gs3MjJBEfs/видео.html
I've really tried to take on board the 'tests first' ideology, but my biggest impediment is the way my brain seems to work. Once I've got a coding idea in my head I find it next to impossible to NOT think about implementation ideas. Not just in front of the computer, but cooking dinner, watching tv, out walking, doing DIY; I can't get it out of my head! I have to start on a basic implementation to satisfy my curiosity of what an implementation might be and to get my ideas down somewhere where they will not get lost or forgotten. After that I sort of ping-pong between unit-tests and implementation details.
I am not sure that that is a problem, I think that my mind works a bit like that too, but that has almost zero to do with the tests that you need to write, Your goal with the tests is to say in many small steps what the code needs to do, not how it does it. I think that this is a VERY good design discipline, that is, to my mind, particularly useful for people like us, who's brain jumps to solutions, because it puts a brake on us heading off in bad directions. I know that for me, TDD gives me better feedback, sooner, on my design choices. I read something from Kent Beck that I liked a lot recently. He said "TDD is about designing the interfaces between the parts, but then the tests that we use to define the interfaces, as a side effect, also verify that our implementation choices behind those interfaces actually work" I think that is a VERY accurate description.
@@ContinuousDelivery One of my old bosses used to say that when he asked me in a meeting about a possible new feature, he could almost "see the code scrolling in front of my eyes" as I thought about it.
In my opinion TDD can be a huge time waster, if it is enforced by an uncertain manager. Now that I work on my own terms in a tiny team, I could strategically test my code: I almost always work TDD when I do data transformation and cover edge cases. I almost never write tests for UI prototypes that in a week I'm going to throw away. I find being able to test locally if your API calls end up in the database a great investment, but I don't do E2E testing much. So, in short: teach people different ways of testing, don't stop until they are familiar with the pros and cons, and then let them decide themselves when and what type of testing they require.
I guess TDD requires some upfront planning and knowing what you want. I don't think it makes sense for massively risky projects where it is unknown whether the approach will even work and spending time writing the tests gets in the way. For me, when there are a lot of unknowns, I find myself trying something and often ripping it out when I discover the approach doesn't work. The code wasn't useless, it generated information and writing tests would have slowed down that discovery process.
Good question, and the 10 items make sense. But after more than 20 years of lack of adoption, maybe it is time to look a little bit harder? I'd argue that the way we mould our organizations is an intrinsic and big part of the problem. The hierarchies we preserve in our organizations (TDD rarely makes managers look great, and its benefits are hard to measure) and the market we operate in (there's little money to be made in TDD) are better root causes.
When writing tests, if those tests are becoming awkward and more difficult to write, it means you're getting feedback on your design. TDD is talking to you. It's telling you your design is starting to suck, so you need to fix your design.
YES! 1000x YES! I see this often when mocks and stubs (can never remember the technical distinction between the two) are rampant. Everything requires olympic level contortions to just get a test running. Another problem with mocks in your tests are when the real world changes and your tests should be breaking, the mocks happily keep your tests passing.
the problem with coding tutorials is that usually when you are trying to do what the tutorial says exactly you run into issues that did not happen to the guide.
I think that the main reason why TDD did not taken over the world is because none of the TDD experts or preachers showed to the world how they TDD a big mobile app for example. I think it would be useful to see you just simply create a big mobile app and show us how you do it in TDD. Make a video series showing us how it's done on a real project. For example why not, a video player or a photo editor with visual effects. Doing TDD for page transitions. I think it would be a wonderful way to express how much nicer is to do TDD and how the result code is better.
@@ContinuousDelivery after searching many of them all of them show us how to TDD 1 + 1 = 2. I know how to TDD that.. But why not make you an example? I mean it should be basic stuff right?
@@arpysemlac I try to make examples, but I think that the problem is different to you, I don't believe that this is a problem that is about mobile vs web or web vs game dev or back-end vs front-end, I think that this is a problem of a focus on design, whatever you are building. I have employed TDD for all of these things, and many more, and I am convinced that it works, but it changes how you organise your code. So for me the difference between a mobile app and something else is pretty much irrelevant, because I am interested in testing the behaviour of my code, and I can choose how to present that to make it easy to test, through the choices that I make in design. I don't particularly like the look of the tools being used here, I prefer xUnit style code for TDD, but this video seems to have a decent focus on the right sorts of things to do: ruclips.net/video/lqelzovTPhY/видео.htmlsi=0lVwLu2SFIEEUwxy (I haven't watched it all the way through so don't hold me to it!) I have a video that tries to explain a bit more of what I mean here: ruclips.net/video/ESHn53myB88/видео.html This is sometimes called "the Humble Object Pattern", but the idea is that you isolate, by design, the I/O from you code and then you can test everything else thoroughly. The key idea in TDD for me, is that we change the design of our code to MAKE IT TESTABLE and as a side effect of working like that we usually end up with better quality designs.
@@ContinuousDelivery my experience has been different. I've found no issue with practicing TDD or a combination of TDD and Unit Tests in certain projects. For instance, we successfully implemented parts of a real-time trading exchange system using C++ for the backend (order entry modules, price conversion etc) using TDD and it worked exceptionally well. While I appreciate the benefits in certain contexts, I do find it impractical for other types of applications. I am genuinely open to discussing this topic. I was very serious in my comment: In my opinion, one of the significant challenges with TDD is its frequent dismissal due to overly ambitious claims. Even in situations where it could be beneficial, it's often overlooked because people insist it works universally, leading to unmet expectations. I don't claim that it doesn't work universally but I do believe that many TDD practitioners struggle to provide practical solutions for diverse use cases, leaving developers facing real issues in their applications without true support. People face real issues in their apps and most TDD guys cannot deliver, cannot give them practical solutions for their use case, but they are still making those ambitious claims.
@ContinuousDelivery, my comment was actually serious. I genuinely believe that the limited availability of high-quality resources applicable to the production of large or intricate applications, where writing tests is not straightforward, is a significant factor discouraging people from adopting unit testing, not to mention TDD. As an example, during my experience working on a real-time trading backend in C++, TDD proved to be highly effective and successful for many modules. However, upon starting my own startup involving web and mobile apps, my perspective shifted. While I do incorporate some tests, I often find them impractical in various scenarios. The examples circulating on the internet, in my opinion, are often simplistic at best and, at worst, misleading. These misleading examples can be so off-putting that individuals dismiss testing even when it could be a perfect fit, precisely because some proponents of TDD make lofty claims without providing solid, practical examples. Lacking a grounded or pragmatic viewpoint, individuals find themselves in real-world applications with genuine challenges and with no real answer or support from the TDD advocates.
BTW: Here's a challenge for ya: I'm working on a 3D engine, the goal of our code has several both vague, conflicting and also abstract goals: *It must be fast. This is "easy" to test for (not easy as in simple, but a known field) *It must handle HUGE data sets, often orders of magnitude bigger than can fit in memory and even on a local disk. *It must mostly render the data correctly. There's no demands for picture perfect, the data has billions of points/triangles/lines, contains lots of unprecise/erroneous data. *It must look good. Surprisingly subjective requirement :P *It must be highly flexible, both in code and at runtime when loading new data sets. Having unit tests for anything else than some of the basic fundamentals doesn't work all that well, and as many of the main goals revolve around how fast it runs/how much data it can handle. And since yet more of them are highly subjective and rather flexible, any rigid testing scheme very quickly gets in the way of solving the implementation challenges (which are just as often "can this even be done?" as "we must be able to set the style of these objects dynamically").
Well you have to build performance into the system from the beginning but you also need correctness. If it fast but produces shitty result it worth nothing. Unit tests can help you with the correctness part, and you have to define what "fast" means, and what "huge" means when it comes to amount of data. You say it is a 3D engine, then one testcase can be "It must be able to handle X amount of objects while maintaining Y frame rate in Z*W resolution" that is a requirement. Squeeze one out of you product manager or product owner, generate the data set, build the performance test suite, and run it regularly.
@@banatibor83 Except it _cant_. You can test the correctness of every single component (unit if you like), but having too many separate component will give you bad performance, and they'll also tell you little about the actual correctness (you're not guaranteed order of execution on fragment shaders). Besides, what causes performance problems isn't just rendering one type of data, it is more often than not a compound problem, ie the result of combining different types of data and filters causing a bottleneck in the GPU. Fast means 90+ FPS, 0 (or less, yes that means having to predict stuff) latency, and huge means 1TB+ pointclouds, 100M+ parametric surfaces. And of course this has to work on a mobile phone, and even worse: in a Browser. The ultra naive test case you suggested only covers a small portion of a single scenario, not even on a specific type of hardware, not in combination with other data sets, and not with restrictions of latency, memory use nor network use, and you'd also need to add environment variance. You'd need 1000's of different tests (compound tests combining different data of different sizes with different characteristics), run on 100's of devices, 100's of times to even get close to some specific numbers. And after you've spent the entire dev teams development budget for 5 years (and realistically spent more time than that building it), how are you going to adapt to an ever changing hardware world, new types of data, and new innovations in algorithms?
@@brynyard Hmm... if you need thousands of tests to run on hundreds of devices, hundreds of times... do you somehow believe that doing that MANUALLY is faster than doing it in code? Or does the problem evaporate if you don't write the tests, and the code just works perfectly?
@@MarcelPopescu and where do I claim doing it manually is an option? I’m just trying to highlight that testing everything isn’t an option (or rather that it's less of a imaginary option with these kinds of problems than others, since testing everything isn't ever a realistic option in the first place).
Been TDDing(-ish) for more than 15 years and I spend 80% of my time on thinking of test design and implementation. And please please please write integration tests; unit tests prove that your code works now; integration tests will help you making it work in 3 years' time
I LOVE that you're spending 80% of your time on design & testing. That seems about right. My view on unit and integration tests: Unit tests test pure functions in the business logic -- push data in as function args and confirm that the function returns the right thing. No side effects allowed -- no filesystem, no database, no network. Thus, if a unit test fails we have either (1) a bug, or (2) a test that doesn't express the requirement correctly. Integration tests are for firing up some services, letting them talk to each other, and assessing if there are problems. Network/db/etc is fair game here as service should talk to each other over their proper interfaces. Failures here indicate service-to-service interface problems.
Education is a huge factor, and not in the way you might think. It's not that there aren't resources to learn TDD. You can't throw a rock without hitting one. However almost all guidance about TDD I've ever read really once made sense once I already knew TDD and could read between the lines. Otherwise, its very easy to draw the entirely wrong conclusions. I tried TDD a few times but gave it up each time because it just never seemed worth it. It didn't really click until I started actually ignoring a ton of the advice about TDD. Once it did click however, there was no going back.
Please could you help me understand how to get to your point? I'm currently thinking that test driven development should actually be called specification driven development and that having the process leading up to it is arguably more important than the tests themselves.
@@SamOweenyou're on the right track that the tests themselves aren't really the most important thing about TDD. Thinking they were is one of the things that kept me from adopting TDD from the beginning. Instead think of it more like "what's the fastest way for me to check if my stuff works?" That's something a lot of people don't think about. They're thinking 100% about how to solve the problem and not at all about how to know if the problem is solved or not. That often leads to overcomplicated solutions that don't actually solve the full problem.
@@SamOween I think it's about intent. "I want the thing I plan to write to do X" and you write a test to that effect. So immediately you are focusing on something valuable you can observe from the outside. When writing the code to fulfill that test it basically forces you to fulfill that goal instead of hacking away in a general direction you think you is a good idea to go (hint, it usually isn't). With that approach you super quickly find out your idea was actually wrong or that it does not lead where it should instead of building complicated system then trying to test it only to find out it's untestable...
I can’t help thinking, most people check out when they start watching a video about TDD and the person says “write a test before you write the code and then execute it, knowing it will fail”. Just seems daft and although I suspect nobody actually does that, it has a “follow the methodology entirely like we say or you will fail” feel to it. So lots of people just go “nope”. So they just write unit tests (probably after writing the code) because it has a clear, immediate, benefit
I think the answer is simple: because it's a private practice. If your outputs are the same, you have the same code and tests, and you did all the work on your own or in a pair while I wasn't watching you, I can't tell if you used TDD to do it or not. What I've attempted to do in my career is bring the process up to the surface: using event storming, ATDD, gherkin scenarios etc. Getting the whole team involved in driving development from use cases and ATDD-style scenarios, and surfacing the scenarios as artifacts themselves and the linchpin around which we write all our tests (unit tests, automated acceptance tests, etc). This has resulted in my developers writing much better unit tests and much better code. Whether they use TDD when I'm not watching, I can't know. I will say more, however: without the focus being on acceptance tests, I find that people attempting to "do TDD" go down the wrong track. That is my hunch for why the research on TDD hasn't had good outcomes: red-green-refactor cycle isn't enough if you aren't focusing on acceptance tests. TDD as red-green-refactor isn't the key thing. The key thing is very clearly thinking through your design. Continuously as you write code, you need to bring your attention regularly away from the nitty-gritty details and back up to the guiding star of the high-level interfaces you are building. Not "how can I hack away at this to get the code to do the thing", but "how do I want to use this code", "in an ideal world what would be the nicest interface I could ask for here", etc. That's the stuff Kent really focuses on in his TDD by Example book, not just the red-green-refactor rules.
Dave, I'm always looking to learn new techniques, I've been an Electrical Engineer for over 45 years, so learning is my life. But we generally work with real world equipment, with simulations, data acquisition, etc. And because of that our design process must start with characterizing the equipment properties and functions, making a list of each individual step that must be accomplished as simple single responsibility, input/process/output methods, definining a basic structure of the core simulation logic, and so on. Those steps are a must, and I don't see how TDD would help with that. Yes, once we have that structure in place we might use TDD for designing the individual methods. But it seems like the real work in doing that is identifying the edge cases that will make the tests useful. In one video you showed an example of doing TDD on a simple calculator app. But the real work is not in TDD, it's figuring out that you need to check for divide by zero, and therefore make a test for that. But that's something you can (and must) implement even without TDD. So yeah, I'm sure some large corporations use it and may benefit from it to whatever extent , but as you and I both know there's a long list of corporate fads that have come and gone over the years, so I'm not sure that's necessarily a thing. And I'm sure they'd never announce it just to sound cool in the industry. Anyway, presently I'm working on a very complicated logic portion of an engineering project, and I'll see if I can implement some sort of TDD, but the real challenge is figuring out the overall logic dealing with complex objects, so I'm not sure how TDD will help with that.
Completely Agree. The complaints i find people make about TDD seem to be mostly mis-interpretations of TDD, or things that TDD actually HELPS with! Making your design more flexible and amenable to change, and therefore, easier to test. TDD can make things feel maddeningly difficult, but whenever I lose my way and just stop writing good tests i find that i was just able to make a mess in record time, while anything that i completed using TDD not only feels more robust, but feels better thought-out and feels like something i would be proud to show other programmers. As always, i think those comes to the lack of proper training for new programmers and understanding that TDD is about the foundations
It's sad but after over 15 years in the business I have yet to find one who does TDD consistently in real life projects. Guess i've never been so lucky to join one of those companies
I'm surprised that a reduction in "agility" hasn't come up in the list. In my practical experience the biggest hinderance to TDD is that in the vast majority of projects I have been part of, the requirement only becomes clear a couple of months down the line. I find that a lot of projects start off with good intentions and TDD, but when the guy in sales calls you and says "the client has changed their mind about everything except the demo date", all of those tests get commented out. So I often think of TDD as the privilege of developers with clear specifications.
Michael Feathers' book Working Effectively with Legacy Code changed everything about how I write code. Your video aligns with my experience using TDD spot on.
Counterpoint for discussion of Time Investment: Professional programmers are paid to deliver business value. Sometimes expediency is more important to business value than quality. In those cases, the cost of tech debt is less than the cost in additional time to write better quality immediately. E.g. If software has an actively exploited vulnerability or fault, the most immediate solution is likely best. Regarding code design and evolution: I imagine what folks are referring to is when you need to make foundational or structural changes rather than updates to functions. I also think most developers like to intuit, and sometimes it's a lot harder to intuit under TDD than incrementally coding (e.g updating policies in rego for the first time or structuring terraform).
100% I use tdd for my own personal projects, but if I dared used it at work, I'd get dragged to the town square and burned. Since they want things pushed asap.
It just occurred to me that a simple way to describe the challenge some have with TDD is: "Hey, how would I design a motorcycle?" The TDD answer: "Well, first out figure how you might bench test a fuel injection system". Well, no, you first figure out what the desired design & performance specifications are, the customer price range, available components, etc. After all of that, THEN you can start thinking about testing the components and how well they work together.
my experience is that with better languages, most bugs are gone. in the beginning of my career bugs were very common. these days, I rarely see too many bugs in projects with 100k loc. bugs I see would never be caught with anything close to a unit test or tdd. they are complex attack vectors that depend on economic incentives that are misaligned between components that are miles apart in code distance. even thinking of these bugs require years of training and understanding. there are never buffer overflow errors, parsing errors, exceptions that are not caught, bad error handling etc. none of those issues are relevant anymore with modern languages. what we have now is focusing on writing simple software that an AI can write for us. if you split your code into units with clear boundaries, the AI will write it all for you. breaking things down into steps does not overwhelm the AI. so there is some overlap between tdd and modern uses of ai in development. but bugs are not such a big issue anymore. indeed most tests are written together with the code when using gpt-4 and code assistants, so the whole idea of what comes first, the code or the test, is not too relevant when they are both written at the same time by a robot.
5:20: Hello there! Can you prove by example that that isn't a true Scotsman Fallacy? _"Unit Testing only fails when it is bad Unit Testing"??_ I'm neither for nor against TDD, I'm just a little wary regarding all software religions. I think TDD is extra interesting for implementing maths libraries, and libraries in general, but besides that? As for intuition: TDD sounds funnier and more secure than normal programming, I'm going to try it for a private project, but I'm pretty sure there are some limitations here and there.
It depends also what you are building, I see for frontend developers it is harder, but that is also that it has a lot of side effects. Normally you can just send input and check the output, you define that. In the frontend, especially with SPA with e.g. React, it is a whole different world. Since I write TDD, I like more and more the backend processes, that are easy to define first.
I think the reason why it hasn't taken over the world is that it's just too hard to really get it right. I've been doing it for over five years in commercial products and I still fall into one of the common pitfalls from time to time. And when I do, it does actually slow me down. For me it's usually implementation details getting mixed up with behaviour and ending up in tests.
Software is often subject to change. TDD helps you test and use the code early and make it easier testable. Without it you have repeatedly manual debugging sessions for parts or most of your code. In certain environments (e.g. scripting) it's a bit harder to use it but not impossible. You just have to learn how to break down your code to easily test it. Regarding job security, i work for a government body. Testing and doing custom software/ tools is my job.
Well I have an answer to your question in the video title TDD hasn't taken over the world of software development because most of the development people do is not actually development, it's bug fixing. The time spent on new features is minuscule, and when I actually do get to do some new features, it's over in the blink of an eye, and wasn't even that difficult. At least, not that difficult compared to fixing a bug with some spaghettified mess in a legacy codebase. And when you do get to do this fresh new coding, you don't need TDD, 99% of the time you are just adding some new page on the UI and giving it a service and maybe a DB table, where is the need for TDD there? Maybe if you are building a brand new system from scratch and most of the time is spent on new features and getting the basic building blocks of the software constructed, TDD could be useful there. As an aside, my own opinion of TDD is not good, despite everything you said in the video. The concept of writing a test before you do the development analysis is fundamentally flawed, I can go into more detail on that if you like. I would question the methods used to determine that an instance of using TDD was a success story, how do you measure this success properly? Can you do a controlled study where you write the same software twice, once with TDD and once without? I would suspect if you did that, the first time you write the software would affect the second time, and the study would struggle to isolate the effect of TDD on the development
While I completely agree with - 100% - for what I believe is some variation of "because it's hard" is why it just isn't used. "Hard" and not wanting to deal with all of the "cruft" many don't even completely understand the underlying ideas of like Mocks, and more specifically how to integrate them into very legacy code seamlessly.
That last factor: "the fear of losing one's job". Is common to many technical professions where the practitioner believes their value is somehow captured in the item they deliver, and that knowledge of the delivered product is a source of ongoing revenue. Sadly this is one of those fallacies that impedes the journeyman from achieving artisan status. You have to make the transition into understanding that all things delivered are but ephemeral expressions of your talent and that your true utility is in knowing how you achieved it.
It’s mind boggling to me too TDD has not been more popular, as well as pair programming. I teach both to all the teams I’ve been on with great success. There’s only one skill that gets more ROI than clean tested design, which TDD is the perfect gateway drug to doing well. That higher ROI skill is identifying and testing and iterating on what is worth coding in the first place, as well as coding the minimum possible to answer the hypothesis for next steps, something I see many TDD beginners get wrong and then write the whole thing off entirely. TDD is beautifully powerful, but it doesn’t mean you need to test everything, and it also doesn’t mean TDD philosophy stops at writing code. TDD is really the art of having a good simple hypothesis that can be invalidated and gives a powerful answer to the question being asked. I use TDD when I write 90% throwaway research code, I use TDD when I write additions to legacy system pipeline code, I use TDD when I write UI code, and I use TDD when i write hw sensor code in a flakey error prone system. The way TDD actually works in those scenarios is slightly different, and one size fits all TDD many preach is missing the point: the basic philosophy always holds true of doing the minimum possible at the fastest speed possible to learn and iterate for what the next step should be.
Truer words have not been said. This is exactly what we need. Write failing tests first. Write code to pass the test. Refactor. Repeat. TDD is the way to go.
The reason I keep giving up on TDD is that I'm not sure if test CORRECT in first place (hands up, I'm not good at that and not matter how many times I tried, me or 90% developers I met simply stoped use it). By that I mean if I for example building ReactJS drawing editor on canvas and using few other libraries, and my goal just to create function that will be used for eraser to rub just red colour, I need to write test that mocks canvas, hence deal with web API, also using some testing library write EXACT test code to make sure he is not "lying", because you write incorrect test and then you create function (bad one) you will make test green, even after refactoring, then is not good .... and no one even mention about that, never seen any video or blog about it. And mind you this is just simple example for write test first, I started implementing chatGPT in to ours existing app and this is new area for me, what chance I will write correctly test? Very little. Unless I write another test after implementing feature to confirm that TTD test is correctly expecting value/type/result, but then question why do I need that at all? I'm not saying TTD is bad, I believe this is incredible "invention" if you can call like that but I'm NOT understand why RUclips full of videos where people still surprised why we not using this method (most TDD examples very basic, never seen test first code for let's say bank transactions ), (most of us, I never met anyone who actually use TTD full time)... I'm not understand from where these videos coming from, it's like politicians living detached from real world people...same story. Again, I'm not against that, I just can't get why people who are using TDD wonder why still there is developers who not practicing TDD, well because we write proper test after feature implemented, so we do "contract" with our code, code should work the way I left last night for 20 years unless someone do changes, but then we get notification straight away about it...From hundreds job descriptions I getting from LinkedIn recruiters I swear 95% never mentioning about TDD (big and small companies, with small and massive budgets) because most people not sure how to use it, maybe I'm missing something, maybe it's popular in US but surely not in UK at least. Resume: if TDD will be MUST have and will be asked at least of 20-30% companies I will definitely push my self harder to learn it, by the and of the day it's another challenge and we developers love to learn new thing, libraries, patterns and etc. For now I will do same what I been doing past few years: will come back to it give a try every few months willing I will get that "click"! Until then my code will survive without TDD, as long is clients happy and pay for ours product, this is most important aspect of every software company: make sure nothing breaks and clients pays for it, because if not we will be down the road, doesn't matter you master of TDD or Kung-fu.Peace.
I've NEVER seen TDD make a project faster or less error prone. I have seen TDD screw up a design in order to bypass real database calls thus not even testing the database call.
All 10 are a miss. TDD is unpopular, because it has a high bar for entry. Usually you don’t start project from scratch, but have a huge legacy codebase where all decisions have already been made long before you came. And now you need to figure out how to put this piece of crap under test just to TDD a color change of a text field. Or model a schema change in Cassandra. Good luck doing that with existing (or rather non-existing) tools. React testing library only works when you own your own ui components library, not when it’s supplied to you by subcontractors from . And after you chopped through all that tech debt, try convincing the whole company to follow you or at least agree to write some tests that make sense (before or after - doesn’t matter). And all this while the company optimizes for maintenance costs.
"now you need to figure out how to put this piece of crap under test" 😃 Isn't that what Michael Feathers calls adding *characterisation* tests? i.e. not Test *Driven* Development...
@@BernardMcCarty Exactly! The "Working effectively with legacy code" book is full of techniques to introduce testing into an untested code base. First you create a seam and a separate your change and test your change, write it in TDD. Usually refactor some functionality into a class and add your new functionality to that class. Calling a constructor and a method with a couple of parameters do not need tests. The rest of the system still will be a mess but that little piece will have tests.
I had bad and good experience with and without TTD: - Bad Code without TTD - Good Code without TTD - Good TTD avoiding Bad Code - Bad TDD forcing Bad Code It´s not rare to have a bug on the Test, which means changing both, Test and Code, when that happens means twice more code was written and twitce more bugs created. At the same time, "not rare" does not mean "usually". TTD feels good when works, but feels very bad when dont. Good code wihtout TTD feels like 7 or 8 of 10 Bad code without TDD feels like 2 or 3 of 10 Good code with TDD feels like 10 or 11 of 11 Bad code with TDD feels like -100 of 10 In concluiosn... idk
In regards to the for job security the approach I usually see is: If you write code that is hard to understand and maintain, you probably are not a team player or not good at your job. You may need to get appointed to tasks where that does not matter. I had several projects I had to hand over to other people due to new tasks. I take some pride in being able to do it smoothly and with low effort. Part of it surely was having a good pool of tests and a good design. TDD played a part in that.
Do you think that it makes a difference to the quality of your output if you do tests first and then make the code work, or if you make your code work, then immediately write tests and fix any issues that you uncover while writing the tests?
@@pieflies Yes, I do. The design process has a better structure. That results in a better design from the start and fewer issues to start with. It´s also easier to keep track of paths to test. My experience is that it also takes less time in total. It prevents some avoidable crashes in user tests as well.
Obfuscating one's work product has been a technique for job security in general since the dawn of man. There are a few antidotes to this: one, is to force at least two designers to contribute to every major area. The workload for the designers is still the same, but it's distributed differently. Two is to recognize innovation (i.e. trying new things) rather than rewarding entrenchment on projects which drag on unnecessarily and are obviously being obfuscated for no good reasons.
In my experience my biggest issue with TDD is that teams that implement it often have an alignment issue. Requirements are poorly understood, and passing tests makes the code acceptable, often with poor integration into the overall vision of the application. I like the principles of knowing what your software should do before you build it, but for teams that implement TDD, I've frequently had to go back and ask the teams to reevaluate what the users are looking for and how the code fits into the overall system. Maybe theze teams are implementing TDD "badly," but teams that have more traditional code reviews that focus on the non-quantifiable aspects of the software, where everyone has to have eyes on the code and can't simply turn off their brains because a test case passes, have done a lot better in my experience.
Thank you for this important video that advocate for better practices ! I am still learning it, but I like TDD because it make the code easier to reason about without having to rely to much on functional programming. I am also looking for a "type driven design" way of managing my projects since I learned that types have a fundamental meaning in mathematics (Type theory). Long story short, a type is a formal proof of a theorem and a proof that a set of values hold certain properties that can reduce the amount of tests. I think combining TDD and type theory can bring something interesting in the future
I tried it, I used it, I did it. But TDD is like pushups: You need a goal to make them. After a while you can achieve the same design quality just because you know more. The time passes and you gain knowledge, you gain habits. You are then replacing the old habits with new habits. TDD is then just replaced by new habits. Am I terribly wrong?
I do like the concept of TDD and I’ve used it in a number of projects - however, I’ve over 30 years experience of software development (not all TDD) and my real world experience of time TDD has saved in fixing bugs against the time it taken to write and maintain it is a ratio of at least 1:60, probably more. That is to say that 1 hour of writing additional code for TDD has saved me around 1 minute of time it would take to spot and fix a bug. I guess I could use the same argument about car insurance having never had to claim anything from it, so that’s not supposed to be an argument against TDD - just reflecting on 30+ years of real world experience working for dozens of clients as a freelance developer.
I think what you're experiencing is the end-point of TDD, you''re thinking through your code so well at the start that the tests are unnecessary - I'm sure most experienced devs wind up in this situation, you can just write bug free code and spot bugs instantly on review. However, as you say of course that is no argument against writing tests, after all your clients may turn your code over to less experienced developers to modify who I would assume will welcome the safety net!
Hey Dave! I'd like your insight on a topic. As you know, in the videogames industry (where I work) much of the work is being done with proprietary engines, like Unity or Unreal. These engines are themselves not done with TDD, nor with TDD in mind. This results in us not being able to do code coverage above 40-50%, no matter how much we layer our code. TDD has to be limited to the back end and the business logic, since the actual live testing (_playing_ the game) has to be done in runtime, using these proprietary tools. I can't guarantee a gun is firing properly until I test it in-game, since there's no way for us to simulate the physics 1:1 to what the engine is doing. I believe that the most powerful aspect of TDD is having a 90%+ coverage and being able to assume things work after changing them. This advantage is completely lost here. Aside from that, since we can reuse most of our back end from game to game, it has been so tried-and-tested at this point that we don't really need to test it that much (except for integration testing). I still want to try out TDD. We do everything else from the "agile uncertified" book: pair programming, (mostly) continuous integration, people-over-tools, and individual agency, among others. I'm not sure TDD worth it though. What do you think videogame developers should do when they're not writing their games from scratch?
This channel just released a video about Sea of Thieves' development process, including test automation. Not sure if you've seen that. Also, have you read Working Effectively with Legacy Code? That might have some techniques you can use to unit test more code in your games.
I remember one time when in a project the client demanded that we have at least 90% test coverage otherwise it wouldn't pass the CI process. Of course, I did a little method that using reflection get every class of the app and test every property, and run every method testing if the result type was the expected type or a exception. Problem resolved, 100% test covered with not really testing anything.
I liked extreme programming. Best system I've seen for projects that involve a fair bit of experimenting. And I always consider that the tests are where your code lives. You just allow it to be taken out and built into an application now and then ;) But I have to say TDD hasn't been a total success for me. So I use a modified TDD. My first "tests" may be me stepping through code in the debugger, changing values, backing up, retrying, etc. If I decide the code is an approach I like and want to take then I clean up the code and write the real tests. Otherwise I throw the whole mess away. If of course I know what the code needs to look like, what the APIs are, etc., then you can to plain old TDD. Though at our place we've got too many devs that are still not sold on testing period. The company has a long way to go and it shows in code quality.
I think much of the resistance is a product of disfunctional organisations with leadership who do not really understand SW development. Developers working in these environments are continually buying themselves time by making *visible* progress. In stark contrast, TDD boosts "iceberg" progress, where most of it is invisible and therefore intangible in the short term. Of course, once ~80% of functionality is built, progress slows right down, but then developers benefit from the sunk cost fallacy, and the business ploughs on until the product ships.
When we went to agile in 2005 they fired all the test engineers and told the developers to add more code to cover the testing. Not surprisingly the quality went to hell . Inventing devOps as another fix put lipstick on the pig. dev code testing dev code... 2years later the manager & devs were gone. Company killed the project.
I looked into TDD at some point, weighted what I saw as advantages and disadvantages and eventually rejected the practice. However, there seems to be a broad range of interpretations of what TDD actually is. Iirc, I understood it as writing more or less extensive tests (plural!) on a function/class/unit level first. This of course means that deviations in the following implementation from what you originally envisioned are costly. Since my development style is very iterative and explorative, that was a problem. A coworker recently told me that he worked in a team where it was understand and practiced exactly like that as well, so I am not alone. Then I saw a presentation, I think by James Coplien, where the speaker complains that TDD is regularly misunderstood and Kent Beck meant it differently. So I started to read the book. And yes, Kent Beck outlined something that is very different from what I did. Now I am at least open to try it again. Bottom line: Instead of preaching to coworkers about TDD and exposing them to half-baked explanations, get them to read the book first and then ask what they think.
Or how about if TDD advocates started explaining TDD properly instead of just complaining that all explanations are wrong. Unit tests are worthless in a distributed system. You need to test the entire system deployed the way it will be deployed in production. I've yet to hear a TDD advocate explain how to TDD a distributed system. They can't seem to get past unit testing.
@@deanschulze3129 I think this is an interesting one, how do you test your system is working once you've got it up and running? Its a similar issue with UI design and even with databases where there is state between 'runs' of code.
@@deanschulze3129 I work on distributed systems and unit tests are very valuable. They cannot be used to identity all the issues but they can be used to catch a lot of problems. Distributed systems still have plenty of code where you can apply unit tests as various parts of the system have various functionality and you can break down that into testable components. For example in the system I'm working on one of the first steps is for a component to break down the job into steps to give to other components. So you can until test that, given different requests and different states does it produce the right steps. Then you can integration test parts of it, do they work correctly with other components in the system. Finally stuff like how does it perform at scale and race conditions require end to end testing. It's much better to catch mistakes in your unit tests, so even if they can't cover everything having some bugs caught there has value so there are valuable in a Distributed system. If we had to wait for end to end tests to catch all the bugs development would slow down massively.
I work for a company that builds software for several clients and most projects start without clear requirements and those requirements always change, that alone would make TDD very impracticle, and besides that we very often need to explore different approaches when implementing the projects, since some approaches may be inefficient, incorrect or simply not what the client needed. In this situation starting with tests would make twice the code to change in order to accomodate the changing requirements.
Actually, the conditions you describe are exactly where tdd shines the most. I work in similar conditions (i guess most devs are) and TDD lets me get to the right requirements much faster than anything I've ever tried. But the learning curve is steep and long. I've been doing it for around 5 years, and I'm just starting to feel that I'm beginning to figure out how to get the most of it
Do you write tests at all though? Because if you do, what happens if you write your tests after and the requirements change, as they do in software development, in some cases won't you have to refactor or scrap no longer valid tests? What's the difference then? Whether you write the code first or last, software is never really 'done', it's evolving and so too are some of its test code. I've found that with TDD my tests change a lot less than my main implementation code because the tests written with TDD express intended behaviour of code and system, not the implementation. When the underlying implementation is refactored the Test Driven code largely stays the same. Tests written after can tests behaviour but often times because the implementation was written first we find we have to cheat to make the test pass. Such cheating may get you to expose inner implementation that should be private, or duplicate implementation in the test case, over mock or completely skip out on testing a piece of code because the black box was so sealed it was hard to get at and test that you have up
It's often in large financial companies like insurance and banks that more efficient teams just get cut down on members by MT. So it's hard to advocate 'work smarter, not harder' ideas. These people tend to block different approaches than they've used for the past 30 years. Once a team start asking MT for more features on the backlog it sets a flag to either cut down teams or indeed come up with more features, usually managers get promoted easier with cost cutting than taking risks with innovative new features.
Practicality in Specific Scenarios is the killer for me. I like TDD, but its hard to do for UI, embedded etc. Despite many assertions that it works, I've never seen a credible example (please link me up 😊😊) . Another area I've not really seen addressed is brownfield. Most of us rarely see File | New Project in our jobs. Instead we're working on existing systems on short timescales for clients where a deep refactor for testing isn't an option. You'd think that e2e tests written to drive new or modified features might work, driven by 3-amigos and capable automated testers (SDET). However in 15 years or so I've met precisely one SDET willing and capable to get ahead of stories as would be needed, and developers reluctant to do the SDET role alongside dev on the ticket. Poorly defined Definition of Done contributes and lets teams close tickets before they are tested.
We're facing a similar situation (with 25+ year old code), however with the mindset that TDD is focused on making sure the interface works, and how we'd know if that interface works, (for whatever definition of interface if yours - we've got plsql packages mainly) enables a sort of piece-meal approach - as you add new parts to an interface you can add testing around them. Not always going to be possible to retrofit but any point where new functionality is added or old stuff ripped out is an opportunity.
TDD in my experience leads to better modularization and better testability, both of which are big reasons for me to apply it. My theory is that many developers fail to realize the importance of these two qualities, that's why they don't see the benefits of TDD.
There are quite a few comments here who have honestly not listened to the video and taken the message on borad. There's all sorts of excuses as to why it wouldn't work in scenario X or it would make scenario Y too difficult. Over the last 8 or 9 years I've been practicing TDD, on all types of projects, I've heard the same comments over and over and pretty much without exception they've come from a place of never actually given it a good go or never really learning/understanding/accepting the fundamentals. TDD in the real world is not easy and the learning curve can be ferocious if you've not got people around you to coach you. I was initially self taught and learnt from going to talks, seminars and books. It was a slog on my own. Most of the big hurdles are ones that pretty much every TDD developer faced at one time or another. If you have to face them yourself with only the internet or a book to guide you then they can seem overwhelming if you're half hearted about TDD. If you've got someone to coach you through them it's a much less bumby ride.
Thank you! "There are quite a few comments here who have honestly not listened to the video" - or, if I may, also not read the LinkedIn article on which it is based! 🤣
@@mambocollective Hey there, the link to my article is in the description below the video. Not sure I can paste a direct link without YT removing it, sorry :(
@@BernardMcCartygot it, thanks. Interesting article. I think that pretty much all of the issues people have with TDD can be traced to lack of training/education. TDD is a steep learning curve with many bumps along the way. Too many people give up before getting to a comfortable level. It's hard without coaching/mentoring from someone who is already experienced. The education I've seen is too simplistic to equip devs for the real world. I was lucky in that I innately knew it was the right thing to do and persisted through the tough times. The other guys in my team had it easy because I could coach them. 😅
@@mambocollective Ha - nice one! 🤣 Thank you also for the feedback. As a developer who could never get management to agree to agree to support training for TDD, I agree with what you say. I just could never win the argument that time spent on education and training would benefit our teams enormously in the long run. It seemed management was always focussed on short term gains, maybe it was their quarterly bonuses they were more preoccupied rather than real metrics! Even so, I was still surprised at the main takeaway from doing the exercise for the article though. Namely that *just 2* of the reasons for not adopting TDD seemed to be directly related to day-to-day, hands-on software engineering, i.e. Design and Evolution and Maintenance Challenges. The other 8 were broadly into Organisational issues and those of personal or *management* Confidence/Hesitancy/Reluctance... ho hum 😃
No one cares about the quality of your code after some time has passed and you might no longer be at the same company. IMO the poor acceptance criteria and level of team organization make dev skip writing tests, because they don't quite know what they want to achieve, or they know the criteria will change next day (maintenance). The quality of software has been declining since CI/CD became so popular
TDD is a nice theoretical idea but in practice it's often not often applicable. Why ? Because current dev job are often governed by ... (Drum rolls) time constraints and management. TLDR: when your requirements changes often but you also get denied the time required to properly engineer a solution and refactor your code accordingly you also have to skip on writing tests for a piece of code that is probably going to change soon. TDD really works only if you have perfect specifications or unlimited time to develop your solution. ( And I know the obvious counterpoint is that testing ensures that your new half-assed code is working as intended but once again it's all a matter of time management)
But the key to go fast is to go well. What time you lose on writing tests you get it back on debugging and trying out many different solutions. At the end you will have the a working code in roughly the same amount of time, but with TDD you will have better design and an automated test suite.
i've worked for big corp twice and for a startup once. each time the time constraint was strong enough to prevent proper design of the solution (or rather we design as we code hopping to make the best educated guesses). In this context, assumption from 1 month ago may turn out to be false and we had to redesign quickly some pieces of the code. in this context writting test IS A WASTE OF TIME. i like test, coverage is better than no coverage but thrown away covereage written less than 3 month ago is almost worthless @@banatibor83
Yet, this is how Microsoft, Tesla, Google, Amazon, Netflix and many, many more do work? TDD as a dev approach is, in my experience at least, MUCH faster than without, as I think I said in the video the most productive teams I have ever seen all practice TDD. So if you are under time pressure TDD is the correct tool to use!
Honestly all I'm getting here are a bunch of platitudes about how, if I don't like it then I'm either doing test-driven development wrong or I just don't want to do it because I guess I'm stubborn. Well I can be stubborn I've tried to do test-driven development and it's always a big pain with very little benefit. What disappoints me about this video is that there's an opportunity here to enlighten me yet, again I just get platitudes about it with no explanation of how to do it right so I'm still not convinced.
I'm writing a slightly different version of the calculator app every day for a living. TDD works great for me and it made my designs so much better. It must be your fault you can't get it to work for your app which must be not that much different from my calculator app as you mistakenly think.
@Dave - You mentioned jUnit, and it brought me back to circa 2005. Part of the reason TDD hasn't taken over is laid at the feet of Educators. Back in 2005(ish), I tried very hard to get jUnit & TDD in part of our post-secondary programming course. But I was alone, and voted down (even though I showed that it could be done). Now, in 2022, we are FINALLY teaching unit tests (though not TDD, yet). Sometimes, change occurs at the speed of tenure....
Totally agree with the statement that those who don’t like TDD have never really practiced TDD. I often find that more senior developers are more resistant to adopting this (and other XP) practices. Sometimes I just think it’s an issue with egos. In my 10+ years of getting teams to adopt TDD and CD not one team has gone back to their old ways, surely there is a good reason for this.
If what you observe is resistance to change, is it then an argument for TDD that the teams don't _change_ back to the old style? After all, that is now the new status quo. Mind you, I am not arguing TDD at all here, I am just questioning the argument.
@@carstenbohme8813It’s a fair challenge. Teams get a chance to change their ways of working at the retrospective meeting and frequently modify things, but abandoning TDD hasn’t been suggested.
Regarding the point about job security, I have wondered if QA people worry about developers practicing TDD because they fear it will put them out of a job.
As somebody working in QA, nope. Fewer low level "stupid" bugs leaves more time to find high quality bugs, preventing these leaves more dev time to add features to the product which then need to be tested... :)
Nah. As a QA, I think Dev are too lazy to learn TDD. Most of them just want to write code and leave all the testing stuff for us. I think one of the big problem that TDD still not successful is that DEV are too lazy to adapt TDD
@@NguyenDucTung-y4d That is very depressing. Another possibility is that many developers have not heard of it. I’m sure there are plenty of developers who don’t read books or watch RUclips channels like this one. Maybe I haven’t worked with enough people, but I’ve yet to meet anyone else in my 10+ year career who I know practices TDD.
In TDD, you write the test and it becomes your pair, in writing the code. Test complexity is directly related to code cohesion and coupling, which are at the heart of design. So, TDD is the skill of writing the simplest test for your code. Perhaps, instead of code, do test reviews, to teach and increase adoption.
I can't help but feel that TDD is two months of writing tests, and one month of writing code. As opposed to one month of writing code, and one month of debugging. I just don't get it. BTW been coding since 1965.
one of the issues is that dev does TDD their own way and i have yet to come across a good tutorial step by step for a complex project using TDD from start to finish - why are there no complex examples other than the 'hello world' TDD ?
I think the more complex the example, the more effort it takes to build the tutorial. Additionally, the more complex the example, the less well the tutorial works as a written article. I've always been an article/book-oriented learner, but when it came to really getting to grips with TDD, then long-form videos did the best job. J. Rainsberger's video series is the first material that made the whole process of TDD 'click' for me - just look for "The World’s Best Intro to TDD". The first half of the course is free. The next series that really helped me with TDD, and was far more in-depth, was James Shore's "Let's Play Javascript". This used to be subscription only, but recently became entirely free. He also did a Java series called "Let's Play TDD", but I can't vouch for that. There may be other brilliant examples out there and, if there are, I'm guessing they cost money in order to make them financially viable.
Do you think that it makes a difference if you do tests first and then make the code work, or if you make your code work, then immediately write tests and fix any issues that you uncover while writing the tests? Either of those approaches would seem to me to achieve most of the outcomes you say are benefits of TDD.
With TDD, it is required to write a failing test before writing any code. Then you write code that makes it pass. This shows two important things: that the test can fail and that the code you wrote makes it pass. Code/test/fix can't do that. Also, it's faster to write tests then write code than to write code and then have to tear up that code to make it unit testable.
Writing tests after kind of defeats the point. TDD will ensure you have a better design. In addition you can only ever be 100% confident in your tests if you’ve seen them fail first. This is the key to unlocking CD.
@jimmyhirr5773 is it faster though? For the code we have, to write a test involves also adding mocking objects. If I'm experimenting with ideas for an implementation, it would be a lot quicker to just prototype in the code in place.
@@SirBenJamin_I can't speak for your situation. It's possible that it will always be difficult to do TDD in the domain you're working on. But it's also possible that the code's design makes testing unnecessarily difficult. For example, it could have long methods that require lots of mocks to be testable, or big classes that are difficult to mock. If that's the case, then it's possible that the code can be refactored to make unit testing quicker. I will say that in my situation, where I've worked with a big, decade-old codebase where doing manual tests is difficult, TDD is faster if the code isn't too poorly designed.
@@jimmyhirr5773 the thing is, if you follow TDD/Clean coding practices from the start, the methods shouldn't long, classes shouldn't be big because the tests act as a safety net and you can refactor mericlessly. The code you write will be JUST the code needed to produce the required behaviour. No redundancy, no "extras", no guilded roses.
I start with tests when I write new files in Java only and don't unit test my Python code, which I guess is bad. The first time I saw assertions, I thought it was surely testing mostly the core functionality of Java and is quite pointless. What are we building here? An ontology? Well, if you approach the tests as being the documentation for the functional requirements, then it's excellent.
For me, the key distinction was deciding whether the problem was a computer science problem, vs a modeling problem. Unit testing is great for computer science problems where there are absolutely right and wrong answers. For business modeling problems, BDD is the right approach, because there may be many solutions to the problem and locking the solution down with unit tests is the wrong approach.
I have also found that people end up testing the wrong things. There are many people who will overuse mocking to test internal implentation details, which results in any refactoring resulting in a lot of broken tests because they are tied to the implementation. Tests should test the public API, given an input, do we get this output. You are then free to refactor the internal implementation and comfortable that the test will still pass. For something more complicated then you can break it into smaller tests to help implement those small parts, but those tests should then be deleted afterwards. It is also a lot more approachable for beginners, because once you start testing internal implementation details then you almost have a deep understanding of how everything works from the get go and it becomes overwhelming. It is also fine writing messy code to get that test passing. Once it is passing, then you are free to make the code nice and use design patterns. I also think people struggle, because while Coding Katas are a nice exercise practicing TDD, developers then move to real world problems and think, well, how does a bowling game, fizz buzz or mars rover relate to what I am doing here? I think beyond Katas there needs to be more practical real world examples of TDD being used in practice. Not to mention, people who are deep into TDD and XP can be quite religious about the whole thing, and I think that can put some developers off TDD as well.
I always felt that I did test driven development. I write a little piece of a program and test it out. Every change I make I test it. There isn't a single thing I do to my code without checking whether or not there are errors. It's hard to imagine a programmer that just sits there and patiently writes an entire program without ever running it to see if it works so far. It might save time though. But for me it's hard to find the errors if you do a bunch of changes all at once and only afterward you decide to run it and see if it works.
Sorry but that isn't TDD, because your testing comes after your wrote the code. the idea of TDD is to structure you work so that you write code that is demanded of you by a test. Coding decisions are "Driven" by the tests that we put in place first. So what you describe is really not the same thing.
It takes too long and testing everything for the sake of testing, even if it was obvious is daft. A little bit more code? The amount of code written for writing tests is greater than the actual code itself.
I say that the biggest compliment you can get as a software engineer is when your fellow colleagues tell you that they had to work on your code and they enjoyed it.
I can agree. bc I have a lot of experience with the opposite. people no longer with a company that I wanted to sue for having to maintain and rewrite their code! 🤣
True True True! Patches of code that are hard to understand are where the bugs hide
Many developers have never seen TDD done well or design done well. It's a miracle that TDD has survived so long.
I've seen "experts" claim that you TDD the frontend by doing e2e TDD 🤣 bye bye quick feedback, hello brittle tests (the opposite of what you try to achieve in "real" TDD)
This. This is the greatest barrier imo. I'm working in a small team and trying to bring tdd to our new angular app. I have nobody and nowhere to go with my questions, doubts etc. And my very specific problems aren't usually covered in simple examples found in online tutorials
@@krzysztofprzybylski2750 if you try to bring tdd to a team and you don't master it you should forget about it. People will be convinced one you show them how it works and how fast you implement stuff thanks to this technique.
I've been guilty of the same stuff when I was younger, believe me. Improve your practices and then try to bring them into new teams. Or quit your job and join teams that practice well already (hard as f..k imo)
Don't be afraid to blame the educators. I'm in the field, so I should know...
For me the change came a few years ago, when I was part of a small team working on a project where management was not interfering and we were free to develop code in any way we want, provided that it worked. That was not the first time I had done TDD, but it was the first time it clicked for me. Just that freedom to work on just one piece of the whole code and not have to constantly keep checking if I haven't messed up something else! And the feeling when I go home Friday evening and not have to think about all the bugs that are waiting for me to fix next Monday - that peace of mind, that is priceless!
Now I like to repeat what I once heard someone say: TDD is only important if you want to be able to trust your code. It gives me that strange fuzzy feeling that maybe writing good code is not that difficult after all... or as Kent Beck has said, I am not a great programmer, I am just a good programmer with great habits.
I haven't done proper TDD but I think I'll give it a shot. I do know that feeling though. My habit is to write the feature one small piece at a time, verify each small piece manually, and then go back and write tests for all or most of the edge cases I can think of. I know I've written enough tests when I feel like I can trust them, if that makes sense
I think tdd as a mindset has been transformative.Writing useful and reliable tests is the key, just trying to fulfil code coverage is a waste of time.
I think people mistake tdd for unit test coverage in my experience
I have one similar story to Farley. I was practicing TDD for a while, but it was mostly me learning on my own what to do and applying it at work. It wasn't until I joined a company that had enough good practicioners of TDD (in my case was Codurance) that I did not elevate my understanding. Having people to guide you is such a massive boost.
In most work places they've heard about quality code but they don't care. They usually just talk about it during an interview. It's such a lure for new hires.
Why hasn't TDD taken over the world? Easy, the problem with TDD is that almost all examples you can find is either not applicable on the real world (.e.g. FizzBuzz), are needlessly testing underlying runtime methods that we can assume is already working properly (like String.length and Integer.parse), or are testing built in arithmetic such as if(50 == 50) that will only fail if your CPU hasn't got enough thermal paste.
The drawback of TDD is that it extends development time by a factor of however many functions you have and the amount of possible inputs and outputs. Useful for making close to perfect software but impractical for business.
That's only true if you assume that your speed of development is proportional to the speed at which you type. I prefer to optimise for thinking rather than typing, so TDD is a lot faster for me.
If you find yourself saying “You’re just not doing it right” every time someone brings up an objection to your favorite way of doing things, I find it’s often more profitable to take a closer look at the practice itself: maybe everyone is doing a practice wrong because it’s *difficult* to get it right, and maybe that actually means that the practice itself is less valuable *because* it’s so difficult to get right. I would argue TDD is one of these things. A powerful tool in well-practiced hands, it’s easy to misapply and get wrong. It does not create a “pit of success” for practitioners to fall into, but rather a mountain that must be climbed. This is a demerit against the practice. Not a statement of how everyone else is just incompetent or misinformed.
I've never accepted the idea of Test-Driven-Development. When I see civil engineers sit besides a stream and start a bridge build testing it with twigs before they move on to sticks and eventually ends up with concrete and steel (as we all knew they would) when they want to build a 4 lane bridge I may accept the approach. It is almost like software developers hate themselves or don't have respect for their own trade. I NEVER make tests first. What I really want are tests to verify the code AFTER it is finished to make it easy to maintain AFTER the code is doing what it is supposed to do. I call it Verification-Assisted-Maintenance. The tests are there solely to verify the code is still working after someone has fiddled with something in the codebase. I've also NEVER seen civil engineers sit together to verify each others work like we do in software development with peer-review. Again: It is almost like we all are amateurs just poking around and jabbing in programming statements until they work. We don't behave at all like other trained professionals that knows what they are doing.
You would be amazed to discover that about 90% of all programmers have precisely this poking around approach to coding. They twiddle with code mostly senselessly until it works on their desk. This is quite detrimental when in esp. interfaces to complex library mechanisms are involved that actually require full understanding of the semantics to make the code work robustly.
I've stopped calling TDD as Test-Driven-Development... for me, I think a more accurate name is Test-Driven-**Design**. You raise something along these lines around 9:40. My rationale for this is that TDD helps me naturally write better designed software. I think a maxim we can all agree on is that well designed code is easier to test compared to badly designed code.
Learning to build software via TDD was almost like learning a brand new skill adjacent to software development. I can't imagine another way of building software that I'm prepared to put my name against.
When I was writing my book "Modern Software Engineering" I wanted to write some bad code to demonstrate poor modularity, cohesion, separation of concerns , abstraction and coupling so that I could de-construct it in the book. I started as I always start, with a test, and quickly found that it was impossible to write code that was as bad as I wanted with the tests. I had to make the code untestable to make it bad enough, so I dropped the tests, then it was easy to write terrible code.
I think this says something important about TDD - what else does that for software?
On that last point about job security - I have a story.
Long long ago ( early 1990s ), I developed an extremely simple way of doing a large portion of design & programming for a games company I worked at. The company specialized in flight simulators, and the part I optimized was where the user would set-up scenarios - e.g. weather conditions, airplane models, number of opponents, etc.. Up to that point, it took a full 1/3rd of engineering effort to create the scenario-builder.
I introduced OOP along with an extremely small and efficient library to assemble the various screens ( usually a forest of checkboxes and radio buttons ). A couple of non-engineers - an artist a producer were able to create virtually an entire scenario builder, only requiring a small amount of engineering to hook-up the scenario onto the simulator input file. ( and, I was working on eliminating THAT ). They were amazed and anxious to use the system ( and another group of game designers started prototyping using it as an accidental side-effect ).
I was told that other engineers were nervous about the system, and expressed all kinds of concerns - hinting that 1/3rd of the engineering staff may need to be let go.
I was pulled-off the prototyper, and transferred to mundane stuff - and was gone from the company within 3 months. That company died long ago, and that attitude probably hastened its demise.
I’ve used TDD for many years and would say I’m addicted to the fast feedback loop. However, I also like the patten ”Spike and stabilize” coined by Dan North, which also is about faster feedback, however on a different level. We deliberately defer the decision on quality to learn faster whether code has any business value in the first place.
Glad to find such comments here. I have seen so many tests written and throw away together with the code after some weeks
Yup this is the higher level version
We have spoken a lot about this topic, but I think that TDD is one of these things that needs a good teacher to convince a company to redirect that ship. I have seen too much cases where a poor implementation of TDD was enough to give up and go back to cavern programming. Good episode and keep pushing with this kind of videos I hope they reach the right people.
"cavern programming" - love it! 🤣
The difficulty I have with TDD is that all the tutorials focus around very simple problems that have predefined input parameters and expected output parameters. The usual example is a calculator, thats easy. The interface is already very clear. Where as with most of the stuff I do, I am given a feature request, but the implementation has no clear interface, and I'll often experiment with different implementations until I come up with something that works well. To me, TDD is not much help here. It's more productive to edit the code in the actual app to see how things could work. I should add that my work mainly is in WPF applications, so mostly UI
have you explored BDD? And for Windows dev lookup SpecFlow
I see it similarly to you BUT honestly, TDD is more like a playground for me. I do mainly backend stuff and I’ve recently tried to get into working with TDD. I don’t do it as strictly as red, green, refactor. But for me it’s a great way to just try stuff out! Writing a test allows me to press a button and run a small part of code from a larger project. So I constantly go back and forth between production code and test code and expand either side a bit until I’ve really figured out what my input is and what my output should be. And once I figured that out, my production code is basically 80% already there. And since I used a test to guide my coding, I’ve also made the production code ready for unit tests, since I had to think about mocking and so on. Without starting tests first into a problem, I would have never thought about mocks. And trust me, I’ve spent SO MUCH time in the last few months rewriting code since without TDD I didn’t think about testing and now I’m stuck with production code that is untestable and needs heavy rewriting.
@@lifehacker123Have you read Working Effectively with Legacy Code? It sounds like it could really help you.
SirBenJamin, you should check out Bob Martin's Java Case Study. It shows an entire application being developed from scratch with TDD.
That is one of my problems also, TDD proponents, most of the time, only demonstrate how to do it, using simple examples, mostly unrelated with what you would find at you job or more complex projects.
Another issue is, it's always your problem if you can't understand and use it, TDD is a silver bullet and you are the idiot unable to wield that gun ...
My biggest complaint about TDD is the notion that tests should be written first -- and often I don't *quite* know what I'm working on yet! Creating tests in the exploration stage hampers my ability to get into a "groove" where I start to understand the problem, and thus can create the tests the problem needs.
I have found, however, that once I'm on a roll with the tests, and particularly when I'm nearing completion of the feature in question, that creating good tests can help uncover edge cases that would have otherwise been overlooked!
IMO you should write descriptions before the actual tests, i write the skeletons of expected behaviours first, so that my implementation does not influence my description of the underlying spec, then i play around with ideas for implementing it, then i fill out the test, mocks and spies necessary making sure it's as generic and independent from the concrete implementation as realistically possible and then i clean up the implementation
Fun fact: I had a boss that completely misunderstood the term "Extreme Programming" to mean that we should _literally_ be extreme, so he enrolled the entire team (there was just 3 of us) into taking Pilot Licenses and paid for the theory and exams. For some strange reason we all failed to protest and correct him, and unfortunately I couldn't afford the flight hours required for the license, but we had fun times :P
lol
Lmao 🤣
The 90's were a hell of a decade.
extreme programming aka node and npm ecosystem :D
@@Microphunktv-jb3kj Don't forget the pip dependency hell. It's almost on par.
13:27
> There isn't a a specific technology nor a a a type of software that I've come across that isn't amenable to TDD in my experience
I think this fails to take into account those who work within a framework bubble. This is what happened back in 2014 with the Martin Fowler, Kent Beck and DHH debate.
DHH claimed that TDD caused Test-induced design damage. Of course he made this claim as a framework author who designed his framework with a certain work flow in mind; a work flow that never considered including TDD.
And to a degree I see the same thing happening in the React space (and perhaps within the larger movement of so called component-orientation). While there are boundaries between components, within the components traditionally distinct concerns are readily blended.
This lead to the creation of testing frameworks (e.g. Jest) with features to support testing these framework components which are invariably slow given the concerns that are mixed within these components.
Meanwhile a whole new generation of developers learn testing with the capabilities of these tools, being left with the impression that using tests is about correctness-not that tests are feedback machines.
Microtests detect unwanted change. They don't verify correctness.
This situation is now further being aggravated by a movement to start using AI-tools to write tests for the developer-which is completely missing the point.
The greatest resistance to TDD I've seen comes from those who are used to working (mostly) solo on short projects, and who are intelligent enough that they (mostly) get their code working on the happy path quickly. Tdd feels like overhead to them, since they "design in their head", or by rapid prototyping with few safety nets. That's great and all, but it's difficult to help them get through implementation work that way.
That's not necessarily the case. Even if you work alone TDD and CI/CD helps you actually save time. It will also save time when colleagues have to do builds and have to follow a simple short documentation. Starting a script which executes everything is hardly beyond anyone's skill.
I made a project involving some maths before knowing how to unit test, and ended up with buggy maths, unit tests can be really useful, as regression tests or just as technical documentation
Yes I think id fall into the category you described. What do you say to these people? Maybe it’s an ADHD thing but I’m big on exploratory problem solving where I’m just getting in there and coding before I know what I’m doing. I’m just starting to scaffold out the right ideas and once I understand the code I want to write, then I can write the tests and code in either order it doesn’t really matter. I don’t see the benefit of TDD except for developers who like it. If it feels good for you then go for it just like any other DX thing.
I agree with this one. "Too smart for your own good", who needs methodology, order, and consistency when you have unlimited brain power right? At some point in time, I think Software Developers realize that they are not coding for themselves, is always someone else or your future self. One day the problem exceeds you, if you are chasing the right problems soon it will, and you will love to have methodology, order, and consistency... some days, the unlimited brain power machine won't turn on or will need some hours warming up to turn on.
@@judgemental_coder okay someone please explain the TDD superiority complex. “You’ll want order eventually” is such a weird critique because obviously anyone that spends time coding is going to develop methodologies for coding. What is the benefit of the design process necessarily starting with writing a test? We could write code with infinite variations of design processes. If TDD feels good for you use it. Sure. but are there any real reasons why it’s objectively better in any way?
On point 2: Better, more flexible, more readable code... I have to say that I've heard this a lot since the early days of Martin Fowler and Clean Code, and generally speaking I disagree with it. The most readable code is often the least flexible, it does one thing and does it clearly. There's a long debate about procedural vs functional vs object oriented code, encapsulated and decoupled vs tightly coupled code, and depending on where you did your career work, your opinions are likely the polar opposite of other people in different careers.
I think there's no question that tightly coupled code is less complex than decoupled code. It takes less time to write, less effort to follow, there are fewer places where a problem could lie. Programmers and OO specialists often talk about information hiding and encapsulated functionality as if it's a good thing, but rather than good or bad, what we can say is that it adds layers of complexity to the whole project. If you only see the outer layer, then the project will look simpler. But if you have to look at all the layers and follow code flow, it often gets so complicated there's almost nothing you can do except break out your debugger and follow along to see where it's going.
Encapsulated code is often effectively impossible to reason about, unless you're the person who wrote it. In that respect, I have found that consulting firms often love it when their developers write code like this, because it's so abstract that you cannot maintain it. Even with testing in place, they might be able to say, "It works as intended!" but it's so complicated that there's no way to falsify the claim that it is working as it should. And that to me is the most significant danger of going down this rabbit hole: You have to write modular code and break apart functions until they are testable, so that they fit into the TDD model. But at that point, you might have taken a 5 line process and decomposed it into 12 different functions, there's no longer any discernible code flow, but you can proudly claim it works exactly as it should... Until what it needs to do changes.
That's not to say that you cannot find success with some of the TDD ideas, or you should give up testing altogether, but I think by far the simplest reason TDD didn't take over the world is that TDD makes your code much more complex in order to make it testable, and that regular humans (who most of the programmers you hire off the street will be) are not going to be able to find success working on a project that's got pages and pages of business rules broken out into thousands and thousands of lines of decoupled, flexible code. But programmers cannot even agree on the definition of complex (literally: "consisting of many different and interconnected parts") and simple (c.f. simplex: "composed of or characterized by a single part or structure").
The fundamental lie of Object Oriented programmers and the Refactorers and Decouplers is that we should not write Simple code because it's too hard to maintain, which is almost never true. We shouldn't always write it because it won't help us get our job done, often times we do need complex behavior as an end result but many TDD people go straight for the most complex possible solution so that every line of code they write is "encapsulated", "reusable", "decoupled". And it's just a mess.
Interesting questions.
Some $0.02:
A. Software is usually developed within some economic context. Decent tests significantly add to the cost to develop a piece of software. Often the business context is uncertain initially. E.g. "we just want to see if something is possible/how it looks/show something quick to a prospective customer". This means that if you pound the table saying that you need to write your tests first, the business owner is probably going to fire you and get someone who is fine with hacking away with no tests initially to do the work. Often tests get added later, if the code turns out to be used in production/sold/have some value. In this context any plan to write the tests first will clearly fail.
B. Commonly used test frameworks were developed by folks who had some particular idea about how they wanted to run tests, usually the arrangement is to run the test code "in-process" with the code-under-test, written in the same language, with some added salt and pepper about how to report results, inherit from some base test class, and so on. This is only the right way to do tests for some scenarios -- generally when the code you're testing is being shipped as a library, to be consumed by some calling code that runs in the same process. But lots of software isn't like that. It's providing a network service or indexing large volumes of data across a cluster, or whatever. In my experience developers today just disable their brains and blindly plough on writing tests that are not really useful tests, just to fit in with their test framework-du-jour. This discourages clear thinking for TDD because there's no direct link between "what the thing we're making does" and "what I put in my tests". It's all a dreamscape of mocking and nonsense (in my experience).
Nobody on the business side has to know about testing, but I really find that TDD is fantastic for those "just want to see if something is possible" scenarios. Its the fastest way of just playing around with code until you get something you like. If I wasn't writing tests, I'd be checking results manually which can't possibly be faster than running a test.
A does not have to be true, as explained in the video. Writing a test case isn't more expensive than writing any other lines of code, and usually in my experience it actually ends up with less time spent rewriting incorrect code - if you don't write tests, the only way you can test your code is by running it, finding out it doesn't work, then re-writing it until it does work. If you can write you code perfectly first time then sure, don't worry about tests, but nobody can do this, so it's a false economy not to write them, and it's generally much cheaper to write them first because you don't end up writing tests which end up tightly coupled to the implementation details and full of mocking - which leads into point B:
TDD when done well in my experience helps to avoid the problem you talk about here with over mocking because it becomes very quickly apparent if you're having to add a bunch of mocks in order to get your tests to pass, and you can try different approaches to minimise their use. This is something that needs to be learned, it's not immediately obvious, especially if you come from a background of writing tests after where sometimes extensive mocking is the only way to retrofit tests into poorly designed codebases.
@@QmunkEI've also seen lots of over-mocking, not just with existing code, but also with people's own code when they code then test. Of course, all the tests they see are like this, so they never learn any other way to do it.
Because software _companies_ hate testing and QA, _not_ software developers. Testing & QA are only cost centers for a SW outfit - good QA never generates revenue (much less a profit) and no SW company has ever bothered to try to learn to sell it. They only care that the product is in at least an MVP state at GA release time (always 5pm on a Friday) - barely functional enough to close the deal with the victim/customer from quarter to quarter. I was in QA for almost 30 years and in that time I never worked for an outfit where QA and testing were anything better than an afterthought constantly on the brink of starvation, that the place was dragged into kicking and screaming, because "hello world" didn't work in one of their major releases. SW companies don't care if their products are crappy; only developers care about that. Not complicated....
Most critics of TDD I've spoken with never tried it. They just repeat all these arguments discussed by Dave which they've heard somewhere. Or their arguments are more against testing itself than TDD. At least they are afraid to say "we shouldn't write test because (for example) they slow us down", as even non-technical managers understand importance of testing. Instead they use the same argument but replace testing with TDD.
And I completely agree with Dave. Testing is not the goal in itself. The real goal is to write better software.
I have a much more reasonable explanation for that: TDD is a practice that does not fit in every single problem/solution domain as proponents like Dave insists. It's not a silver bullet: actually, it works well for the context that Dave frames over and over on his videos - relatively small projects, generally as a tool when designing the core logic of a micro-service, without touching too much infrastructure. Unfortunately, real world Software is much bigger than this.
Arguing that one can easily do embedded programming, Mobile/Desktop/UI programming, IaC programming and others with TDD is a total unrealistic claim, since it's extremely common that the tooling itself jeopardize the (expected) fast feedback loop, making TDD unfeasible. Been working with Mobile Engineering in the past 10 years, I followed advises similar to Dave's and when I finally was ready to try TDD in REAL projects, slow compile/build times made it just impossible.
Another example are large repos with thousands or hundreds of thousands of tests (eg, mono-repos) : you can assume that all of them are the outcome of TDD if you want, so there are no useless tests out there. As soon as one suffers with slow feedback loops when trying by-the-book TDD, one realizes that something different is needed.
Another example are mission-critical applications and low-level software, where performance matters a lot and good performance usually means non-orthodox software design decisions, eventually exploring the boundaries of our own programming languages, the underlying Operating System, or opt-in into "bad practices" like shared mutable state. Can TDD spot non-orthodox decisions when the goal is to meet Security/Perf requirements? Sorry, but in my experience, the answer is no.
Nevertheless, TDD is a practice that assumes that Engineers know few stuff (or nothing) about a particular problem/solution domain. Such an assumption may work for entry-level JR Engineers out there, and maybe for consultants, but definitely will fail for experienced Engineers working in the same industry domain for several years in a row, specially when specializing in sub-domains: we can think here on an Engineer working for 10+ years with Quant/Trade systems in different companies, or an Engineer that focused on compilers and tooling for his/her all life, or even Salesforce developers, and many other examples.
Thinking that such experienced Engineers won't bring their own background on a given (sub) domain to the table, exclusively delegating design decisions to the outcomes of TDD / pair-programming sessions is naive at most and unrealistic at best.
Also, Dave's claims on TDD have a built-in hidden assumption on pair-programming / TBD, ie, they assume up-front that the emergent design from a TDD process won't be reviewed, scrutinized and eventually rejected by other Engineers involved in the social technical context. Dave ignores that gatekeeped Code Reviews (eg, via PRs) are the default standard in our industry, and that such a process is not necessarily friendly to by-the-book, clean TDD.
Is TDD something it's worth learning (or at least try)? Definitely yes.
Is TDD something you want to use if the social-technical context allows to? Definitely yes.
Should people push for TDD regardless the social-technical context, like Dave recommends? Definitely no.
I’ve tried out NUnit and GoogleTest at my last two employers. Regression testing is definitely useful but it is rarely the unit tests that break. It’s almost always E2E tests that fail under unforeseen circumstances.
However, that’s not because TDD ASSUMES that developers know nothing about the domain. It’s because the software evolves and no human can possibly keep tabs on it over the course of months and years.
However, the TDD approach to development is not about testing. It’s a design methodology that enables software to be tested using these OOP testing frameworks. If you simply go through the Red-Green-Refactor steps that Kent Beck talks about, it doesn’t really need a testing framework but rather thinking through what the requirements of the component are, adding test drivers fir that functionality, and then implementing the component and bridging the gap between the tests and implementation. That puts you into the perspective of a user first.
However, I agree with you in practice this is no silver bullet because the real assumption is that you as a programmer understand how the user will want to use the software component you’re putting all these tests around. At the unit level, these are usually sound because you are using your own components but once you get to the system level, there’s too many assumptions which break and performance certainly supersedes feature factories in many contexts.
Basically, the only real achievement of TDD is that component regression tests are brought at the design stage. However, these are never sufficient for system level tests, regardless of whether it is an embedded project for manufacturing, a server side backend, or anything that involves more than a small group of close-knit developers who are always there on the project. In recent years, I’ve come to realize that big companies who have TDD and such practices still face similar problems to any place that doesn’t have them. Most real issues are discovered in production or by users.
Great video! I'm sure that if you make a series of a project using tdd it would be so much more easy to learn by example instead of only theory.
I'm surprised that there wasn't a significant set of developer responses talking about the difficulties of implementing TDD in a legacy code environment. That's where most of us work, after all. In my experience it's not so much that the developers are resistant to ideas like TDD, they just can't figure out where to start! If a software company has been going long enough that it is making money, then, by definition, a lot of its software will be classed as 'legacy' by its current developers. And unless that software was originally written, 5 or 10 or 20 years ago, in a way that makes it easy, or even possible, to wrap automated tests around its units, implementing ideas like extreme programming and TDD feels somewhat daunting even if the developers would absolutely love to do it. Without performing significant surgery on your commercially successful, maintenance headache of a product, without the safety net of a decent suite of automated tests, or even a coherent suite of documented manual regression tests, you're not going to get your spaghetti monster into TDD-able shape anytime soon, and you'll struggle to get budget signoff to even try. You could still write your tests first before you make your changes to the software - but you'd be writing your pre-conditions and assertions on "paper" and executing them manually every time. There might be some merit in doing that, but would that really TDD?
There are strategies to improve it though. I don't recommend arbitrarily adding TDD to legacy code, you have to do it carefully. Here are a few thoughts...
ruclips.net/video/_gs3MjJBEfs/видео.html
I've really tried to take on board the 'tests first' ideology, but my biggest impediment is the way my brain seems to work.
Once I've got a coding idea in my head I find it next to impossible to NOT think about implementation ideas. Not just in front of the computer, but cooking dinner, watching tv, out walking, doing DIY; I can't get it out of my head!
I have to start on a basic implementation to satisfy my curiosity of what an implementation might be and to get my ideas down somewhere where they will not get lost or forgotten.
After that I sort of ping-pong between unit-tests and implementation details.
I am not sure that that is a problem, I think that my mind works a bit like that too, but that has almost zero to do with the tests that you need to write, Your goal with the tests is to say in many small steps what the code needs to do, not how it does it. I think that this is a VERY good design discipline, that is, to my mind, particularly useful for people like us, who's brain jumps to solutions, because it puts a brake on us heading off in bad directions. I know that for me, TDD gives me better feedback, sooner, on my design choices. I read something from Kent Beck that I liked a lot recently. He said "TDD is about designing the interfaces between the parts, but then the tests that we use to define the interfaces, as a side effect, also verify that our implementation choices behind those interfaces actually work" I think that is a VERY accurate description.
@@ContinuousDelivery One of my old bosses used to say that when he asked me in a meeting about a possible new feature, he could almost "see the code scrolling in front of my eyes" as I thought about it.
In my opinion TDD can be a huge time waster, if it is enforced by an uncertain manager. Now that I work on my own terms in a tiny team, I could strategically test my code: I almost always work TDD when I do data transformation and cover edge cases. I almost never write tests for UI prototypes that in a week I'm going to throw away. I find being able to test locally if your API calls end up in the database a great investment, but I don't do E2E testing much. So, in short: teach people different ways of testing, don't stop until they are familiar with the pros and cons, and then let them decide themselves when and what type of testing they require.
I guess TDD requires some upfront planning and knowing what you want. I don't think it makes sense for massively risky projects where it is unknown whether the approach will even work and spending time writing the tests gets in the way. For me, when there are a lot of unknowns, I find myself trying something and often ripping it out when I discover the approach doesn't work. The code wasn't useless, it generated information and writing tests would have slowed down that discovery process.
Thanks for not giving up on helping people get better educated! Myself included!
Good question, and the 10 items make sense. But after more than 20 years of lack of adoption, maybe it is time to look a little bit harder? I'd argue that the way we mould our organizations is an intrinsic and big part of the problem. The hierarchies we preserve in our organizations (TDD rarely makes managers look great, and its benefits are hard to measure) and the market we operate in (there's little money to be made in TDD) are better root causes.
When writing tests, if those tests are becoming awkward and more difficult to write, it means you're getting feedback on your design. TDD is talking to you. It's telling you your design is starting to suck, so you need to fix your design.
YES! 1000x YES! I see this often when mocks and stubs (can never remember the technical distinction between the two) are rampant. Everything requires olympic level contortions to just get a test running. Another problem with mocks in your tests are when the real world changes and your tests should be breaking, the mocks happily keep your tests passing.
the problem with coding tutorials is that usually when you are trying to do what the tutorial says exactly you run into issues that did not happen to the guide.
I think that the main reason why TDD did not taken over the world is because none of the TDD experts or preachers showed to the world how they TDD a big mobile app for example. I think it would be useful to see you just simply create a big mobile app and show us how you do it in TDD. Make a video series showing us how it's done on a real project. For example why not, a video player or a photo editor with visual effects. Doing TDD for page transitions. I think it would be a wonderful way to express how much nicer is to do TDD and how the result code is better.
Well if I search for TDD example for mobile apps I get 1.9 million hits, including several videos of worked examples!?
@@ContinuousDelivery after searching many of them all of them show us how to TDD 1 + 1 = 2. I know how to TDD that.. But why not make you an example? I mean it should be basic stuff right?
@@arpysemlac I try to make examples, but I think that the problem is different to you, I don't believe that this is a problem that is about mobile vs web or web vs game dev or back-end vs front-end, I think that this is a problem of a focus on design, whatever you are building. I have employed TDD for all of these things, and many more, and I am convinced that it works, but it changes how you organise your code. So for me the difference between a mobile app and something else is pretty much irrelevant, because I am interested in testing the behaviour of my code, and I can choose how to present that to make it easy to test, through the choices that I make in design.
I don't particularly like the look of the tools being used here, I prefer xUnit style code for TDD, but this video seems to have a decent focus on the right sorts of things to do: ruclips.net/video/lqelzovTPhY/видео.htmlsi=0lVwLu2SFIEEUwxy (I haven't watched it all the way through so don't hold me to it!)
I have a video that tries to explain a bit more of what I mean here: ruclips.net/video/ESHn53myB88/видео.html
This is sometimes called "the Humble Object Pattern", but the idea is that you isolate, by design, the I/O from you code and then you can test everything else thoroughly.
The key idea in TDD for me, is that we change the design of our code to MAKE IT TESTABLE and as a side effect of working like that we usually end up with better quality designs.
@@ContinuousDelivery my experience has been different. I've found no issue with practicing TDD or a combination of TDD and Unit Tests in certain projects. For instance, we successfully implemented parts of a real-time trading exchange system using C++ for the backend (order entry modules, price conversion etc) using TDD and it worked exceptionally well.
While I appreciate the benefits in certain contexts, I do find it impractical for other types of applications. I am genuinely open to discussing this topic. I was very serious in my comment: In my opinion, one of the significant challenges with TDD is its frequent dismissal due to overly ambitious claims. Even in situations where it could be beneficial, it's often overlooked because people insist it works universally, leading to unmet expectations. I don't claim that it doesn't work universally but I do believe that many TDD practitioners struggle to provide practical solutions for diverse use cases, leaving developers facing real issues in their applications without true support. People face real issues in their apps and most TDD guys cannot deliver, cannot give them practical solutions for their use case, but they are still making those ambitious claims.
@ContinuousDelivery, my comment was actually serious. I genuinely believe that the limited availability of high-quality resources applicable to the production of large or intricate applications, where writing tests is not straightforward, is a significant factor discouraging people from adopting unit testing, not to mention TDD. As an example, during my experience working on a real-time trading backend in C++, TDD proved to be highly effective and successful for many modules. However, upon starting my own startup involving web and mobile apps, my perspective shifted. While I do incorporate some tests, I often find them impractical in various scenarios. The examples circulating on the internet, in my opinion, are often simplistic at best and, at worst, misleading. These misleading examples can be so off-putting that individuals dismiss testing even when it could be a perfect fit, precisely because some proponents of TDD make lofty claims without providing solid, practical examples. Lacking a grounded or pragmatic viewpoint, individuals find themselves in real-world applications with genuine challenges and with no real answer or support from the TDD advocates.
BTW: Here's a challenge for ya:
I'm working on a 3D engine, the goal of our code has several both vague, conflicting and also abstract goals:
*It must be fast. This is "easy" to test for (not easy as in simple, but a known field)
*It must handle HUGE data sets, often orders of magnitude bigger than can fit in memory and even on a local disk.
*It must mostly render the data correctly. There's no demands for picture perfect, the data has billions of points/triangles/lines, contains lots of unprecise/erroneous data.
*It must look good. Surprisingly subjective requirement :P
*It must be highly flexible, both in code and at runtime when loading new data sets.
Having unit tests for anything else than some of the basic fundamentals doesn't work all that well, and as many of the main goals revolve around how fast it runs/how much data it can handle. And since yet more of them are highly subjective and rather flexible, any rigid testing scheme very quickly gets in the way of solving the implementation challenges (which are just as often "can this even be done?" as "we must be able to set the style of these objects dynamically").
Well you have to build performance into the system from the beginning but you also need correctness. If it fast but produces shitty result it worth nothing. Unit tests can help you with the correctness part, and you have to define what "fast" means, and what "huge" means when it comes to amount of data.
You say it is a 3D engine, then one testcase can be "It must be able to handle X amount of objects while maintaining Y frame rate in Z*W resolution" that is a requirement. Squeeze one out of you product manager or product owner, generate the data set, build the performance test suite, and run it regularly.
@@banatibor83
Except it _cant_. You can test the correctness of every single component (unit if you like), but having too many separate component will give you bad performance, and they'll also tell you little about the actual correctness (you're not guaranteed order of execution on fragment shaders). Besides, what causes performance problems isn't just rendering one type of data, it is more often than not a compound problem, ie the result of combining different types of data and filters causing a bottleneck in the GPU.
Fast means 90+ FPS, 0 (or less, yes that means having to predict stuff) latency, and huge means 1TB+ pointclouds, 100M+ parametric surfaces. And of course this has to work on a mobile phone, and even worse: in a Browser.
The ultra naive test case you suggested only covers a small portion of a single scenario, not even on a specific type of hardware, not in combination with other data sets, and not with restrictions of latency, memory use nor network use, and you'd also need to add environment variance. You'd need 1000's of different tests (compound tests combining different data of different sizes with different characteristics), run on 100's of devices, 100's of times to even get close to some specific numbers.
And after you've spent the entire dev teams development budget for 5 years (and realistically spent more time than that building it), how are you going to adapt to an ever changing hardware world, new types of data, and new innovations in algorithms?
@@brynyard Hmm... if you need thousands of tests to run on hundreds of devices, hundreds of times... do you somehow believe that doing that MANUALLY is faster than doing it in code? Or does the problem evaporate if you don't write the tests, and the code just works perfectly?
@@MarcelPopescu and where do I claim doing it manually is an option?
I’m just trying to highlight that testing everything isn’t an option (or rather that it's less of a imaginary option with these kinds of problems than others, since testing everything isn't ever a realistic option in the first place).
Been TDDing(-ish) for more than 15 years and I spend 80% of my time on thinking of test design and implementation. And please please please write integration tests; unit tests prove that your code works now; integration tests will help you making it work in 3 years' time
The way I think of it
Unit tests are for me, to help me write the code
Integration and e2e are for the business and have the real value long term
I LOVE that you're spending 80% of your time on design & testing. That seems about right.
My view on unit and integration tests: Unit tests test pure functions in the business logic -- push data in as function args and confirm that the function returns the right thing. No side effects allowed -- no filesystem, no database, no network. Thus, if a unit test fails we have either (1) a bug, or (2) a test that doesn't express the requirement correctly. Integration tests are for firing up some services, letting them talk to each other, and assessing if there are problems. Network/db/etc is fair game here as service should talk to each other over their proper interfaces. Failures here indicate service-to-service interface problems.
Education is a huge factor, and not in the way you might think. It's not that there aren't resources to learn TDD. You can't throw a rock without hitting one.
However almost all guidance about TDD I've ever read really once made sense once I already knew TDD and could read between the lines. Otherwise, its very easy to draw the entirely wrong conclusions.
I tried TDD a few times but gave it up each time because it just never seemed worth it. It didn't really click until I started actually ignoring a ton of the advice about TDD. Once it did click however, there was no going back.
Please could you help me understand how to get to your point? I'm currently thinking that test driven development should actually be called specification driven development and that having the process leading up to it is arguably more important than the tests themselves.
@@SamOweenyou're on the right track that the tests themselves aren't really the most important thing about TDD. Thinking they were is one of the things that kept me from adopting TDD from the beginning.
Instead think of it more like "what's the fastest way for me to check if my stuff works?" That's something a lot of people don't think about. They're thinking 100% about how to solve the problem and not at all about how to know if the problem is solved or not. That often leads to overcomplicated solutions that don't actually solve the full problem.
@@SamOween I think it's about intent. "I want the thing I plan to write to do X" and you write a test to that effect. So immediately you are focusing on something valuable you can observe from the outside. When writing the code to fulfill that test it basically forces you to fulfill that goal instead of hacking away in a general direction you think you is a good idea to go (hint, it usually isn't). With that approach you super quickly find out your idea was actually wrong or that it does not lead where it should instead of building complicated system then trying to test it only to find out it's untestable...
I think the main reason is that humans are generally not very good at Delayed Gratification.
I can’t help thinking, most people check out when they start watching a video about TDD and the person says “write a test before you write the code and then execute it, knowing it will fail”.
Just seems daft and although I suspect nobody actually does that, it has a “follow the methodology entirely like we say or you will fail” feel to it.
So lots of people just go “nope”. So they just write unit tests (probably after writing the code) because it has a clear, immediate, benefit
Yeah, that sounds like a senseless dogma which is an instant turn off to to a critical thinker.
I think the answer is simple: because it's a private practice.
If your outputs are the same, you have the same code and tests, and you did all the work on your own or in a pair while I wasn't watching you, I can't tell if you used TDD to do it or not.
What I've attempted to do in my career is bring the process up to the surface: using event storming, ATDD, gherkin scenarios etc. Getting the whole team involved in driving development from use cases and ATDD-style scenarios, and surfacing the scenarios as artifacts themselves and the linchpin around which we write all our tests (unit tests, automated acceptance tests, etc).
This has resulted in my developers writing much better unit tests and much better code. Whether they use TDD when I'm not watching, I can't know.
I will say more, however: without the focus being on acceptance tests, I find that people attempting to "do TDD" go down the wrong track. That is my hunch for why the research on TDD hasn't had good outcomes: red-green-refactor cycle isn't enough if you aren't focusing on acceptance tests.
TDD as red-green-refactor isn't the key thing. The key thing is very clearly thinking through your design. Continuously as you write code, you need to bring your attention regularly away from the nitty-gritty details and back up to the guiding star of the high-level interfaces you are building. Not "how can I hack away at this to get the code to do the thing", but "how do I want to use this code", "in an ideal world what would be the nicest interface I could ask for here", etc. That's the stuff Kent really focuses on in his TDD by Example book, not just the red-green-refactor rules.
Dave, I'm always looking to learn new techniques, I've been an Electrical Engineer for over 45 years, so learning is my life. But we generally work with real world equipment, with simulations, data acquisition, etc. And because of that our design process must start with characterizing the equipment properties and functions, making a list of each individual step that must be accomplished as simple single responsibility, input/process/output methods, definining a basic structure of the core simulation logic, and so on. Those steps are a must, and I don't see how TDD would help with that. Yes, once we have that structure in place we might use TDD for designing the individual methods. But it seems like the real work in doing that is identifying the edge cases that will make the tests useful. In one video you showed an example of doing TDD on a simple calculator app. But the real work is not in TDD, it's figuring out that you need to check for divide by zero, and therefore make a test for that. But that's something you can (and must) implement even without TDD. So yeah, I'm sure some large corporations use it and may benefit from it to whatever extent , but as you and I both know there's a long list of corporate fads that have come and gone over the years, so I'm not sure that's necessarily a thing. And I'm sure they'd never announce it just to sound cool in the industry. Anyway, presently I'm working on a very complicated logic portion of an engineering project, and I'll see if I can implement some sort of TDD, but the real challenge is figuring out the overall logic dealing with complex objects, so I'm not sure how TDD will help with that.
Completely Agree. The complaints i find people make about TDD seem to be mostly mis-interpretations of TDD, or things that TDD actually HELPS with! Making your design more flexible and amenable to change, and therefore, easier to test.
TDD can make things feel maddeningly difficult, but whenever I lose my way and just stop writing good tests i find that i was just able to make a mess in record time, while anything that i completed using TDD not only feels more robust, but feels better thought-out and feels like something i would be proud to show other programmers.
As always, i think those comes to the lack of proper training for new programmers and understanding that TDD is about the foundations
This is an excellent collection of common objections. Thank you! (From one who's been learning TDD for over 20 years.)
The problem with TDD is that many don't know what they want before they program something and go through some rounds of refactoring.
It's sad but after over 15 years in the business I have yet to find one who does TDD consistently in real life projects. Guess i've never been so lucky to join one of those companies
I'm surprised that a reduction in "agility" hasn't come up in the list. In my practical experience the biggest hinderance to TDD is that in the vast majority of projects I have been part of, the requirement only becomes clear a couple of months down the line. I find that a lot of projects start off with good intentions and TDD, but when the guy in sales calls you and says "the client has changed their mind about everything except the demo date", all of those tests get commented out. So I often think of TDD as the privilege of developers with clear specifications.
Michael Feathers' book Working Effectively with Legacy Code changed everything about how I write code.
Your video aligns with my experience using TDD spot on.
Because it's a tedious way to develop software whose benefits never seem to come to fruition.
Counterpoint for discussion of Time Investment: Professional programmers are paid to deliver business value. Sometimes expediency is more important to business value than quality. In those cases, the cost of tech debt is less than the cost in additional time to write better quality immediately. E.g. If software has an actively exploited vulnerability or fault, the most immediate solution is likely best.
Regarding code design and evolution: I imagine what folks are referring to is when you need to make foundational or structural changes rather than updates to functions. I also think most developers like to intuit, and sometimes it's a lot harder to intuit under TDD than incrementally coding (e.g updating policies in rego for the first time or structuring terraform).
100% I use tdd for my own personal projects, but if I dared used it at work, I'd get dragged to the town square and burned. Since they want things pushed asap.
It just occurred to me that a simple way to describe the challenge some have with TDD is: "Hey, how would I design a motorcycle?" The TDD answer: "Well, first out figure how you might bench test a fuel injection system". Well, no, you first figure out what the desired design & performance specifications are, the customer price range, available components, etc. After all of that, THEN you can start thinking about testing the components and how well they work together.
my experience is that with better languages, most bugs are gone. in the beginning of my career bugs were very common. these days, I rarely see too many bugs in projects with 100k loc.
bugs I see would never be caught with anything close to a unit test or tdd. they are complex attack vectors that depend on economic incentives that are misaligned between components that are miles apart in code distance. even thinking of these bugs require years of training and understanding.
there are never buffer overflow errors, parsing errors, exceptions that are not caught, bad error handling etc. none of those issues are relevant anymore with modern languages.
what we have now is focusing on writing simple software that an AI can write for us. if you split your code into units with clear boundaries, the AI will write it all for you. breaking things down into steps does not overwhelm the AI. so there is some overlap between tdd and modern uses of ai in development.
but bugs are not such a big issue anymore. indeed most tests are written together with the code when using gpt-4 and code assistants, so the whole idea of what comes first, the code or the test, is not too relevant when they are both written at the same time by a robot.
5:20: Hello there! Can you prove by example that that isn't a true Scotsman Fallacy? _"Unit Testing only fails when it is bad Unit Testing"??_ I'm neither for nor against TDD, I'm just a little wary regarding all software religions. I think TDD is extra interesting for implementing maths libraries, and libraries in general, but besides that? As for intuition: TDD sounds funnier and more secure than normal programming, I'm going to try it for a private project, but I'm pretty sure there are some limitations here and there.
It depends also what you are building, I see for frontend developers it is harder, but that is also that it has a lot of side effects.
Normally you can just send input and check the output, you define that.
In the frontend, especially with SPA with e.g. React, it is a whole different world.
Since I write TDD, I like more and more the backend processes, that are easy to define first.
It's really hard to implement TDD if you get final technical requirements after releasing the test version or your product.
Which is 90% of projects these days
I think the reason why it hasn't taken over the world is that it's just too hard to really get it right. I've been doing it for over five years in commercial products and I still fall into one of the common pitfalls from time to time. And when I do, it does actually slow me down. For me it's usually implementation details getting mixed up with behaviour and ending up in tests.
Software is often subject to change. TDD helps you test and use the code early and make it easier testable. Without it you have repeatedly manual debugging sessions for parts or most of your code. In certain environments (e.g. scripting) it's a bit harder to use it but not impossible. You just have to learn how to break down your code to easily test it.
Regarding job security, i work for a government body. Testing and doing custom software/ tools is my job.
Well I have an answer to your question in the video title
TDD hasn't taken over the world of software development because most of the development people do is not actually development, it's bug fixing.
The time spent on new features is minuscule, and when I actually do get to do some new features, it's over in the blink of an eye, and wasn't even that difficult. At least, not that difficult compared to fixing a bug with some spaghettified mess in a legacy codebase. And when you do get to do this fresh new coding, you don't need TDD, 99% of the time you are just adding some new page on the UI and giving it a service and maybe a DB table, where is the need for TDD there?
Maybe if you are building a brand new system from scratch and most of the time is spent on new features and getting the basic building blocks of the software constructed, TDD could be useful there.
As an aside, my own opinion of TDD is not good, despite everything you said in the video. The concept of writing a test before you do the development analysis is fundamentally flawed, I can go into more detail on that if you like. I would question the methods used to determine that an instance of using TDD was a success story, how do you measure this success properly? Can you do a controlled study where you write the same software twice, once with TDD and once without? I would suspect if you did that, the first time you write the software would affect the second time, and the study would struggle to isolate the effect of TDD on the development
While I completely agree with - 100% - for what I believe is some variation of "because it's hard" is why it just isn't used. "Hard" and not wanting to deal with all of the "cruft" many don't even completely understand the underlying ideas of like Mocks, and more specifically how to integrate them into very legacy code seamlessly.
That last factor: "the fear of losing one's job". Is common to many technical professions where the practitioner believes their value is somehow captured in the item they deliver, and that knowledge of the delivered product is a source of ongoing revenue. Sadly this is one of those fallacies that impedes the journeyman from achieving artisan status. You have to make the transition into understanding that all things delivered are but ephemeral expressions of your talent and that your true utility is in knowing how you achieved it.
Correct, the problem is that my boss doesnt know about it. 😀
It’s mind boggling to me too TDD has not been more popular, as well as pair programming. I teach both to all the teams I’ve been on with great success. There’s only one skill that gets more ROI than clean tested design, which TDD is the perfect gateway drug to doing well. That higher ROI skill is identifying and testing and iterating on what is worth coding in the first place, as well as coding the minimum possible to answer the hypothesis for next steps, something I see many TDD beginners get wrong and then write the whole thing off entirely. TDD is beautifully powerful, but it doesn’t mean you need to test everything, and it also doesn’t mean TDD philosophy stops at writing code. TDD is really the art of having a good simple hypothesis that can be invalidated and gives a powerful answer to the question being asked.
I use TDD when I write 90% throwaway research code, I use TDD when I write additions to legacy system pipeline code, I use TDD when I write UI code, and I use TDD when i write hw sensor code in a flakey error prone system. The way TDD actually works in those scenarios is slightly different, and one size fits all TDD many preach is missing the point: the basic philosophy always holds true of doing the minimum possible at the fastest speed possible to learn and iterate for what the next step should be.
Truer words have not been said. This is exactly what we need. Write failing tests first. Write code to pass the test. Refactor. Repeat. TDD is the way to go.
The reason I keep giving up on TDD is that I'm not sure if test CORRECT in first place (hands up, I'm not good at that and not matter how many times I tried, me or 90% developers I met simply stoped use it). By that I mean if I for example building ReactJS drawing editor on canvas and using few other libraries, and my goal just to create function that will be used for eraser to rub just red colour, I need to write test that mocks canvas, hence deal with web API, also using some testing library write EXACT test code to make sure he is not "lying", because you write incorrect test and then you create function (bad one) you will make test green, even after refactoring, then is not good .... and no one even mention about that, never seen any video or blog about it. And mind you this is just simple example for write test first, I started implementing chatGPT in to ours existing app and this is new area for me, what chance I will write correctly test? Very little. Unless I write another test after implementing feature to confirm that TTD test is correctly expecting value/type/result, but then question why do I need that at all? I'm not saying TTD is bad, I believe this is incredible "invention" if you can call like that but I'm NOT understand why RUclips full of videos where people still surprised why we not using this method (most TDD examples very basic, never seen test first code for let's say bank transactions ), (most of us, I never met anyone who actually use TTD full time)... I'm not understand from where these videos coming from, it's like politicians living detached from real world people...same story. Again, I'm not against that, I just can't get why people who are using TDD wonder why still there is developers who not practicing TDD, well because we write proper test after feature implemented, so we do "contract" with our code, code should work the way I left last night for 20 years unless someone do changes, but then we get notification straight away about it...From hundreds job descriptions I getting from LinkedIn recruiters I swear 95% never mentioning about TDD (big and small companies, with small and massive budgets) because most people not sure how to use it, maybe I'm missing something, maybe it's popular in US but surely not in UK at least. Resume: if TDD will be MUST have and will be asked at least of 20-30% companies I will definitely push my self harder to learn it, by the and of the day it's another challenge and we developers love to learn new thing, libraries, patterns and etc. For now I will do same what I been doing past few years: will come back to it give a try every few months willing I will get that "click"! Until then my code will survive without TDD, as long is clients happy and pay for ours product, this is most important aspect of every software company: make sure nothing breaks and clients pays for it, because if not we will be down the road, doesn't matter you master of TDD or Kung-fu.Peace.
I've NEVER seen TDD make a project faster or less error prone.
I have seen TDD screw up a design in order to bypass real database calls thus not even testing the database call.
All 10 are a miss. TDD is unpopular, because it has a high bar for entry. Usually you don’t start project from scratch, but have a huge legacy codebase where all decisions have already been made long before you came.
And now you need to figure out how to put this piece of crap under test just to TDD a color change of a text field. Or model a schema change in Cassandra. Good luck doing that with existing (or rather non-existing) tools. React testing library only works when you own your own ui components library, not when it’s supplied to you by subcontractors from .
And after you chopped through all that tech debt, try convincing the whole company to follow you or at least agree to write some tests that make sense (before or after - doesn’t matter).
And all this while the company optimizes for maintenance costs.
"now you need to figure out how to put this piece of crap under test" 😃 Isn't that what Michael Feathers calls adding *characterisation* tests? i.e. not Test *Driven* Development...
@@BernardMcCarty Exactly! The "Working effectively with legacy code" book is full of techniques to introduce testing into an untested code base. First you create a seam and a separate your change and test your change, write it in TDD. Usually refactor some functionality into a class and add your new functionality to that class. Calling a constructor and a method with a couple of parameters do not need tests. The rest of the system still will be a mess but that little piece will have tests.
@@banatibor83 such a great book! Did you see Michael's conversation with Dave in The Engineering Room? Well worth a watch if you haven't!
I had bad and good experience with and without TTD:
- Bad Code without TTD
- Good Code without TTD
- Good TTD avoiding Bad Code
- Bad TDD forcing Bad Code
It´s not rare to have a bug on the Test, which means changing both, Test and Code, when that happens means twice more code was written and twitce more bugs created. At the same time, "not rare" does not mean "usually". TTD feels good when works, but feels very bad when dont.
Good code wihtout TTD feels like 7 or 8 of 10
Bad code without TDD feels like 2 or 3 of 10
Good code with TDD feels like 10 or 11 of 11
Bad code with TDD feels like -100 of 10
In concluiosn... idk
In regards to the for job security the approach I usually see is: If you write code that is hard to understand and maintain, you probably are not a team player or not good at your job. You may need to get appointed to tasks where that does not matter.
I had several projects I had to hand over to other people due to new tasks. I take some pride in being able to do it smoothly and with low effort. Part of it surely was having a good pool of tests and a good design. TDD played a part in that.
Do you think that it makes a difference to the quality of your output if you do tests first and then make the code work, or if you make your code work, then immediately write tests and fix any issues that you uncover while writing the tests?
@@pieflies Yes, I do. The design process has a better structure. That results in a better design from the start and fewer issues to start with. It´s also easier to keep track of paths to test. My experience is that it also takes less time in total. It prevents some avoidable crashes in user tests as well.
Obfuscating one's work product has been a technique for job security in general since the dawn of man. There are a few antidotes to this: one, is to force at least two designers to contribute to every major area. The workload for the designers is still the same, but it's distributed differently. Two is to recognize innovation (i.e. trying new things) rather than rewarding entrenchment on projects which drag on unnecessarily and are obviously being obfuscated for no good reasons.
In my experience my biggest issue with TDD is that teams that implement it often have an alignment issue. Requirements are poorly understood, and passing tests makes the code acceptable, often with poor integration into the overall vision of the application. I like the principles of knowing what your software should do before you build it, but for teams that implement TDD, I've frequently had to go back and ask the teams to reevaluate what the users are looking for and how the code fits into the overall system. Maybe theze teams are implementing TDD "badly," but teams that have more traditional code reviews that focus on the non-quantifiable aspects of the software, where everyone has to have eyes on the code and can't simply turn off their brains because a test case passes, have done a lot better in my experience.
Thank you for this important video that advocate for better practices ! I am still learning it, but I like TDD because it make the code easier to reason about without having to rely to much on functional programming.
I am also looking for a "type driven design" way of managing my projects since I learned that types have a fundamental meaning in mathematics (Type theory). Long story short, a type is a formal proof of a theorem and a proof that a set of values hold certain properties that can reduce the amount of tests. I think combining TDD and type theory can bring something interesting in the future
I tried it, I used it, I did it. But TDD is like pushups: You need a goal to make them. After a while you can achieve the same design quality just because you know more. The time passes and you gain knowledge, you gain habits. You are then replacing the old habits with new habits. TDD is then just replaced by new habits. Am I terribly wrong?
I do like the concept of TDD and I’ve used it in a number of projects - however, I’ve over 30 years experience of software development (not all TDD) and my real world experience of time TDD has saved in fixing bugs against the time it taken to write and maintain it is a ratio of at least 1:60, probably more. That is to say that 1 hour of writing additional code for TDD has saved me around 1 minute of time it would take to spot and fix a bug. I guess I could use the same argument about car insurance having never had to claim anything from it, so that’s not supposed to be an argument against TDD - just reflecting on 30+ years of real world experience working for dozens of clients as a freelance developer.
I think what you're experiencing is the end-point of TDD, you''re thinking through your code so well at the start that the tests are unnecessary - I'm sure most experienced devs wind up in this situation, you can just write bug free code and spot bugs instantly on review. However, as you say of course that is no argument against writing tests, after all your clients may turn your code over to less experienced developers to modify who I would assume will welcome the safety net!
Hey Dave! I'd like your insight on a topic. As you know, in the videogames industry (where I work) much of the work is being done with proprietary engines, like Unity or Unreal. These engines are themselves not done with TDD, nor with TDD in mind.
This results in us not being able to do code coverage above 40-50%, no matter how much we layer our code. TDD has to be limited to the back end and the business logic, since the actual live testing (_playing_ the game) has to be done in runtime, using these proprietary tools. I can't guarantee a gun is firing properly until I test it in-game, since there's no way for us to simulate the physics 1:1 to what the engine is doing.
I believe that the most powerful aspect of TDD is having a 90%+ coverage and being able to assume things work after changing them. This advantage is completely lost here. Aside from that, since we can reuse most of our back end from game to game, it has been so tried-and-tested at this point that we don't really need to test it that much (except for integration testing).
I still want to try out TDD. We do everything else from the "agile uncertified" book: pair programming, (mostly) continuous integration, people-over-tools, and individual agency, among others. I'm not sure TDD worth it though. What do you think videogame developers should do when they're not writing their games from scratch?
A game is a UI and even the most hardcore TDD evangelists say that you do not automate UI tests. Especially if it is such fluid UI as a game.
This channel just released a video about Sea of Thieves' development process, including test automation. Not sure if you've seen that.
Also, have you read Working Effectively with Legacy Code? That might have some techniques you can use to unit test more code in your games.
I remember one time when in a project the client demanded that we have at least 90% test coverage otherwise it wouldn't pass the CI process. Of course, I did a little method that using reflection get every class of the app and test every property, and run every method testing if the result type was the expected type or a exception. Problem resolved, 100% test covered with not really testing anything.
This is why unit test coverage is a terrible goal. It's a perfect example of Goodhart's law.
@@jimmyhirr5773never come across that law before. Just done a Google on it. Love it, that's going in my frequently used bag of phrases ❤
I liked extreme programming. Best system I've seen for projects that involve a fair bit of experimenting. And I always consider that the tests are where your code lives. You just allow it to be taken out and built into an application now and then ;) But I have to say TDD hasn't been a total success for me. So I use a modified TDD. My first "tests" may be me stepping through code in the debugger, changing values, backing up, retrying, etc. If I decide the code is an approach I like and want to take then I clean up the code and write the real tests. Otherwise I throw the whole mess away. If of course I know what the code needs to look like, what the APIs are, etc., then you can to plain old TDD.
Though at our place we've got too many devs that are still not sold on testing period. The company has a long way to go and it shows in code quality.
I think much of the resistance is a product of disfunctional organisations with leadership who do not really understand SW development. Developers working in these environments are continually buying themselves time by making *visible* progress. In stark contrast, TDD boosts "iceberg" progress, where most of it is invisible and therefore intangible in the short term.
Of course, once ~80% of functionality is built, progress slows right down, but then developers benefit from the sunk cost fallacy, and the business ploughs on until the product ships.
When we went to agile in 2005 they fired all the test engineers and told the developers to add more code to cover the testing. Not surprisingly the quality went to hell . Inventing devOps as another fix put lipstick on the pig. dev code testing dev code... 2years later the manager & devs were gone. Company killed the project.
Were you working on the Windows Vista team? 🤣
Thanks a lot for this episode. And even more to face the reality in last point, job security.
I looked into TDD at some point, weighted what I saw as advantages and disadvantages and eventually rejected the practice. However, there seems to be a broad range of interpretations of what TDD actually is. Iirc, I understood it as writing more or less extensive tests (plural!) on a function/class/unit level first. This of course means that deviations in the following implementation from what you originally envisioned are costly. Since my development style is very iterative and explorative, that was a problem. A coworker recently told me that he worked in a team where it was understand and practiced exactly like that as well, so I am not alone.
Then I saw a presentation, I think by James Coplien, where the speaker complains that TDD is regularly misunderstood and Kent Beck meant it differently. So I started to read the book. And yes, Kent Beck outlined something that is very different from what I did. Now I am at least open to try it again.
Bottom line: Instead of preaching to coworkers about TDD and exposing them to half-baked explanations, get them to read the book first and then ask what they think.
Or how about if TDD advocates started explaining TDD properly instead of just complaining that all explanations are wrong.
Unit tests are worthless in a distributed system. You need to test the entire system deployed the way it will be deployed in production. I've yet to hear a TDD advocate explain how to TDD a distributed system. They can't seem to get past unit testing.
@@deanschulze3129 I think this is an interesting one, how do you test your system is working once you've got it up and running? Its a similar issue with UI design and even with databases where there is state between 'runs' of code.
@@deanschulze3129 I work on distributed systems and unit tests are very valuable. They cannot be used to identity all the issues but they can be used to catch a lot of problems. Distributed systems still have plenty of code where you can apply unit tests as various parts of the system have various functionality and you can break down that into testable components. For example in the system I'm working on one of the first steps is for a component to break down the job into steps to give to other components. So you can until test that, given different requests and different states does it produce the right steps.
Then you can integration test parts of it, do they work correctly with other components in the system.
Finally stuff like how does it perform at scale and race conditions require end to end testing.
It's much better to catch mistakes in your unit tests, so even if they can't cover everything having some bugs caught there has value so there are valuable in a Distributed system. If we had to wait for end to end tests to catch all the bugs development would slow down massively.
I work for a company that builds software for several clients and most projects start without clear requirements and those requirements always change, that alone would make TDD very impracticle, and besides that we very often need to explore different approaches when implementing the projects, since some approaches may be inefficient, incorrect or simply not what the client needed. In this situation starting with tests would make twice the code to change in order to accomodate the changing requirements.
Actually, the conditions you describe are exactly where tdd shines the most. I work in similar conditions (i guess most devs are) and TDD lets me get to the right requirements much faster than anything I've ever tried. But the learning curve is steep and long. I've been doing it for around 5 years, and I'm just starting to feel that I'm beginning to figure out how to get the most of it
Do you write tests at all though? Because if you do, what happens if you write your tests after and the requirements change, as they do in software development, in some cases won't you have to refactor or scrap no longer valid tests? What's the difference then? Whether you write the code first or last, software is never really 'done', it's evolving and so too are some of its test code. I've found that with TDD my tests change a lot less than my main implementation code because the tests written with TDD express intended behaviour of code and system, not the implementation. When the underlying implementation is refactored the Test Driven code largely stays the same.
Tests written after can tests behaviour but often times because the implementation was written first we find we have to cheat to make the test pass. Such cheating may get you to expose inner implementation that should be private, or duplicate implementation in the test case, over mock or completely skip out on testing a piece of code because the black box was so sealed it was hard to get at and test that you have up
It's often in large financial companies like insurance and banks that more efficient teams just get cut down on members by MT. So it's hard to advocate 'work smarter, not harder' ideas. These people tend to block different approaches than they've used for the past 30 years.
Once a team start asking MT for more features on the backlog it sets a flag to either cut down teams or indeed come up with more features, usually managers get promoted easier with cost cutting than taking risks with innovative new features.
Practicality in Specific Scenarios is the killer for me. I like TDD, but its hard to do for UI, embedded etc. Despite many assertions that it works, I've never seen a credible example (please link me up 😊😊) .
Another area I've not really seen addressed is brownfield. Most of us rarely see File | New Project in our jobs. Instead we're working on existing systems on short timescales for clients where a deep refactor for testing isn't an option. You'd think that e2e tests written to drive new or modified features might work, driven by 3-amigos and capable automated testers (SDET). However in 15 years or so I've met precisely one SDET willing and capable to get ahead of stories as would be needed, and developers reluctant to do the SDET role alongside dev on the ticket. Poorly defined Definition of Done contributes and lets teams close tickets before they are tested.
We're facing a similar situation (with 25+ year old code), however with the mindset that TDD is focused on making sure the interface works, and how we'd know if that interface works, (for whatever definition of interface if yours - we've got plsql packages mainly) enables a sort of piece-meal approach - as you add new parts to an interface you can add testing around them. Not always going to be possible to retrofit but any point where new functionality is added or old stuff ripped out is an opportunity.
TDD in my experience leads to better modularization and better testability, both of which are big reasons for me to apply it. My theory is that many developers fail to realize the importance of these two qualities, that's why they don't see the benefits of TDD.
There are quite a few comments here who have honestly not listened to the video and taken the message on borad. There's all sorts of excuses as to why it wouldn't work in scenario X or it would make scenario Y too difficult. Over the last 8 or 9 years I've been practicing TDD, on all types of projects, I've heard the same comments over and over and pretty much without exception they've come from a place of never actually given it a good go or never really learning/understanding/accepting the fundamentals.
TDD in the real world is not easy and the learning curve can be ferocious if you've not got people around you to coach you. I was initially self taught and learnt from going to talks, seminars and books. It was a slog on my own.
Most of the big hurdles are ones that pretty much every TDD developer faced at one time or another. If you have to face them yourself with only the internet or a book to guide you then they can seem overwhelming if you're half hearted about TDD. If you've got someone to coach you through them it's a much less bumby ride.
Thank you! "There are quite a few comments here who have honestly not listened to the video" - or, if I may, also not read the LinkedIn article on which it is based! 🤣
@@BernardMcCartyhave you got a link to the article please?
@@mambocollective Hey there, the link to my article is in the description below the video. Not sure I can paste a direct link without YT removing it, sorry :(
@@BernardMcCartygot it, thanks. Interesting article. I think that pretty much all of the issues people have with TDD can be traced to lack of training/education. TDD is a steep learning curve with many bumps along the way. Too many people give up before getting to a comfortable level. It's hard without coaching/mentoring from someone who is already experienced. The education I've seen is too simplistic to equip devs for the real world. I was lucky in that I innately knew it was the right thing to do and persisted through the tough times. The other guys in my team had it easy because I could coach them. 😅
@@mambocollective Ha - nice one! 🤣 Thank you also for the feedback. As a developer who could never get management to agree to agree to support training for TDD, I agree with what you say. I just could never win the argument that time spent on education and training would benefit our teams enormously in the long run. It seemed management was always focussed on short term gains, maybe it was their quarterly bonuses they were more preoccupied rather than real metrics! Even so, I was still surprised at the main takeaway from doing the exercise for the article though. Namely that *just 2* of the reasons for not adopting TDD seemed to be directly related to day-to-day, hands-on software engineering, i.e. Design and Evolution and Maintenance Challenges.
The other 8 were broadly into Organisational issues and those of personal or *management* Confidence/Hesitancy/Reluctance... ho hum 😃
No one cares about the quality of your code after some time has passed and you might no longer be at the same company. IMO the poor acceptance criteria and level of team organization make dev skip writing tests, because they don't quite know what they want to achieve, or they know the criteria will change next day (maintenance). The quality of software has been declining since CI/CD became so popular
TDD is a nice theoretical idea but in practice it's often not often applicable.
Why ? Because current dev job are often governed by ... (Drum rolls) time constraints and management.
TLDR: when your requirements changes often but you also get denied the time required to properly engineer a solution and refactor your code accordingly you also have to skip on writing tests for a piece of code that is probably going to change soon. TDD really works only if you have perfect specifications or unlimited time to develop your solution.
( And I know the obvious counterpoint is that testing ensures that your new half-assed code is working as intended but once again it's all a matter of time management)
But the key to go fast is to go well. What time you lose on writing tests you get it back on debugging and trying out many different solutions. At the end you will have the a working code in roughly the same amount of time, but with TDD you will have better design and an automated test suite.
i've worked for big corp twice and for a startup once. each time the time constraint was strong enough to prevent proper design of the solution (or rather we design as we code hopping to make the best educated guesses). In this context, assumption from 1 month ago may turn out to be false and we had to redesign quickly some pieces of the code. in this context writting test IS A WASTE OF TIME. i like test, coverage is better than no coverage but thrown away covereage written less than 3 month ago is almost worthless
@@banatibor83
Yet, this is how Microsoft, Tesla, Google, Amazon, Netflix and many, many more do work?
TDD as a dev approach is, in my experience at least, MUCH faster than without, as I think I said in the video the most productive teams I have ever seen all practice TDD. So if you are under time pressure TDD is the correct tool to use!
1. Clear and correct tests allow us to change the code faster and with confidence.
2. TDD allows us to produce clear and correct tests faster.
Honestly all I'm getting here are a bunch of platitudes about how, if I don't like it then I'm either doing test-driven development wrong or I just don't want to do it because I guess I'm stubborn. Well I can be stubborn I've tried to do test-driven development and it's always a big pain with very little benefit. What disappoints me about this video is that there's an opportunity here to enlighten me yet, again I just get platitudes about it with no explanation of how to do it right so I'm still not convinced.
I'm writing a slightly different version of the calculator app every day for a living. TDD works great for me and it made my designs so much better. It must be your fault you can't get it to work for your app which must be not that much different from my calculator app as you mistakenly think.
@Dave - You mentioned jUnit, and it brought me back to circa 2005. Part of the reason TDD hasn't taken over is laid at the feet of Educators.
Back in 2005(ish), I tried very hard to get jUnit & TDD in part of our post-secondary programming course. But I was alone, and voted down (even though I showed that it could be done). Now, in 2022, we are FINALLY teaching unit tests (though not TDD, yet).
Sometimes, change occurs at the speed of tenure....
Totally agree with the statement that those who don’t like TDD have never really practiced TDD. I often find that more senior developers are more resistant to adopting this (and other XP) practices. Sometimes I just think it’s an issue with egos. In my 10+ years of getting teams to adopt TDD and CD not one team has gone back to their old ways, surely there is a good reason for this.
Exactly, couldn't agree more with that ego problem.
If what you observe is resistance to change, is it then an argument for TDD that the teams don't _change_ back to the old style? After all, that is now the new status quo. Mind you, I am not arguing TDD at all here, I am just questioning the argument.
absolutely rings true..... though i'd say CI is far more crucial than CD
@@carstenbohme8813It’s a fair challenge. Teams get a chance to change their ways of working at the retrospective meeting and frequently modify things, but abandoning TDD hasn’t been suggested.
Regarding the point about job security, I have wondered if QA people worry about developers practicing TDD because they fear it will put them out of a job.
😃Maybe the QA peeps scuppered the "developer" responses on Twitter to keep themselves employed.... 🤔
As somebody working in QA, nope. Fewer low level "stupid" bugs leaves more time to find high quality bugs, preventing these leaves more dev time to add features to the product which then need to be tested... :)
Nah. As a QA, I think Dev are too lazy to learn TDD. Most of them just want to write code and leave all the testing stuff for us. I think one of the big problem that TDD still not successful is that DEV are too lazy to adapt TDD
@@NguyenDucTung-y4d That is very depressing. Another possibility is that many developers have not heard of it. I’m sure there are plenty of developers who don’t read books or watch RUclips channels like this one. Maybe I haven’t worked with enough people, but I’ve yet to meet anyone else in my 10+ year career who I know practices TDD.
I have never got into TDD... but I do use normal Unit Tests. Never saw the reason to use TDD.
In TDD, you write the test and it becomes your pair, in writing the code. Test complexity is directly related to code cohesion and coupling, which are at the heart of design. So, TDD is the skill of writing the simplest test for your code. Perhaps, instead of code, do test reviews, to teach and increase adoption.
I can't help but feel that TDD is two months of writing tests, and one month of writing code.
As opposed to one month of writing code, and one month of debugging.
I just don't get it. BTW been coding since 1965.
Nope, it really doesn't work out that way. By far the most productive teams I have seen, and been part of all did TDD.
one of the issues is that dev does TDD their own way and i have yet to come across a good tutorial step by step for a complex project using TDD from start to finish - why are there no complex examples other than the 'hello world' TDD ?
I think the more complex the example, the more effort it takes to build the tutorial. Additionally, the more complex the example, the less well the tutorial works as a written article. I've always been an article/book-oriented learner, but when it came to really getting to grips with TDD, then long-form videos did the best job.
J. Rainsberger's video series is the first material that made the whole process of TDD 'click' for me - just look for "The World’s Best Intro to TDD". The first half of the course is free.
The next series that really helped me with TDD, and was far more in-depth, was James Shore's "Let's Play Javascript". This used to be subscription only, but recently became entirely free. He also did a Java series called "Let's Play TDD", but I can't vouch for that.
There may be other brilliant examples out there and, if there are, I'm guessing they cost money in order to make them financially viable.
So, you're not going to tell how to apply TDD?
Do you think that it makes a difference if you do tests first and then make the code work, or if you make your code work, then immediately write tests and fix any issues that you uncover while writing the tests?
Either of those approaches would seem to me to achieve most of the outcomes you say are benefits of TDD.
With TDD, it is required to write a failing test before writing any code. Then you write code that makes it pass. This shows two important things: that the test can fail and that the code you wrote makes it pass. Code/test/fix can't do that.
Also, it's faster to write tests then write code than to write code and then have to tear up that code to make it unit testable.
Writing tests after kind of defeats the point. TDD will ensure you have a better design. In addition you can only ever be 100% confident in your tests if you’ve seen them fail first. This is the key to unlocking CD.
@jimmyhirr5773 is it faster though? For the code we have, to write a test involves also adding mocking objects. If I'm experimenting with ideas for an implementation, it would be a lot quicker to just prototype in the code in place.
@@SirBenJamin_I can't speak for your situation. It's possible that it will always be difficult to do TDD in the domain you're working on. But it's also possible that the code's design makes testing unnecessarily difficult. For example, it could have long methods that require lots of mocks to be testable, or big classes that are difficult to mock. If that's the case, then it's possible that the code can be refactored to make unit testing quicker.
I will say that in my situation, where I've worked with a big, decade-old codebase where doing manual tests is difficult, TDD is faster if the code isn't too poorly designed.
@@jimmyhirr5773 the thing is, if you follow TDD/Clean coding practices from the start, the methods shouldn't long, classes shouldn't be big because the tests act as a safety net and you can refactor mericlessly. The code you write will be JUST the code needed to produce the required behaviour. No redundancy, no "extras", no guilded roses.
I start with tests when I write new files in Java only and don't unit test my Python code, which I guess is bad. The first time I saw assertions, I thought it was surely testing mostly the core functionality of Java and is quite pointless. What are we building here? An ontology? Well, if you approach the tests as being the documentation for the functional requirements, then it's excellent.
For me, the key distinction was deciding whether the problem was a computer science problem, vs a modeling problem. Unit testing is great for computer science problems where there are absolutely right and wrong answers. For business modeling problems, BDD is the right approach, because there may be many solutions to the problem and locking the solution down with unit tests is the wrong approach.
I have also found that people end up testing the wrong things. There are many people who will overuse mocking to test internal implentation details, which results in any refactoring resulting in a lot of broken tests because they are tied to the implementation. Tests should test the public API, given an input, do we get this output. You are then free to refactor the internal implementation and comfortable that the test will still pass. For something more complicated then you can break it into smaller tests to help implement those small parts, but those tests should then be deleted afterwards.
It is also a lot more approachable for beginners, because once you start testing internal implementation details then you almost have a deep understanding of how everything works from the get go and it becomes overwhelming. It is also fine writing messy code to get that test passing. Once it is passing, then you are free to make the code nice and use design patterns.
I also think people struggle, because while Coding Katas are a nice exercise practicing TDD, developers then move to real world problems and think, well, how does a bowling game, fizz buzz or mars rover relate to what I am doing here? I think beyond Katas there needs to be more practical real world examples of TDD being used in practice. Not to mention, people who are deep into TDD and XP can be quite religious about the whole thing, and I think that can put some developers off TDD as well.
I always felt that I did test driven development. I write a little piece of a program and test it out. Every change I make I test it. There isn't a single thing I do to my code without checking whether or not there are errors. It's hard to imagine a programmer that just sits there and patiently writes an entire program without ever running it to see if it works so far. It might save time though. But for me it's hard to find the errors if you do a bunch of changes all at once and only afterward you decide to run it and see if it works.
Sorry but that isn't TDD, because your testing comes after your wrote the code. the idea of TDD is to structure you work so that you write code that is demanded of you by a test. Coding decisions are "Driven" by the tests that we put in place first. So what you describe is really not the same thing.
It takes too long and testing everything for the sake of testing, even if it was obvious is daft.
A little bit more code? The amount of code written for writing tests is greater than the actual code itself.