🚨 ONLINE TDD COURSE | I’ve put 25+ years of training and consultancy experience into creating a course specifically designed to accelerate your understanding and application of TDD. Studying with me HAS NEVER BEEN EASIER. Find out more HERE ➡ courses.cd.training/courses/tdd-bdd-design-through-testing
Great video to watch while I'm using TDD and while it is paying dividends. I'm reverse engineering some software for which i don't have the source. The original software can export it's config as a text file. Using TDD i was able to find bugs in my code but also find bugs in the original authors code. I was working with a binary file and offsets of the data change depending on the type of record. TDD made it easy to get that right. I discovered i made a spelling mistake deep into the build. It turned out to be all over the code and tests. TDD allowed me to correct this and ensure i didn't break existing code. The hardest part has been ensuring that i have the discipline to stay the course. Thanks for the leadership on TDD. 16:03
Since I have started to apply TDD every now and then I started realizing how pointless writing tests after implementing the function is. You basically already did stuff and now you tend to write tests according to your code. It might help you find problems if your refactoring breaks the functionalty but will not make sure that your code meets the requirements in the first place. Also I love that TDD forces you to write tests that make sense... like not just try to cover every line of code but check the functionalities on a higher level. Thanks for giving me the chance to find it out!
If the tests you wrote after writing the code didn't reveal any bugs then your tests were terrible. The most vital type of testing is system level tests which not only test your application code but the infrastructure and integration points as well.
@@deanschulze3129 oh that sounds bad, but could you give me an example of a test that checks the infrastructure and integration points? like for example what would that mean for a web app or a desktop app?
@@AleksandraSetsumei - For a web app you would start by testing basic CRUD functionality on the endpoints. You would also have to write tests to verify that business logic is working properly. It's usually best to write these end-end tests in the same language you used to write application code in.
It's the same reason why (good) Agile is rarely used. It's not that its hard, its that you have to unlearn so many things that were previously taken to be obviously true.
It's the same. Agile is as useless as TDD. That's the reason why nobody does TDD and that's the reason why people are massively stopping doing 'agile' methodologies. Both are useless... Tough 'agile' might have some interesting points. TDD not even that.
@@joanvallve7647 TDD is as useless as UML. Read that as "people that can't do UML properly see little value in UML". Ignore the fact that having thought out things in your sequence and state diagrams saved you A LOT of time writing the wrong thing that you then had to refactor and kludge into something workable. Ignore the fact that the diagrams themselves are documentation of the system. Ignore the fact that they give you a good estimation on how and how much changes can or will break the system. tldr: React Andy's will never grep the value of systems architecture, which is OK as their code won't be in use long enough to be an issue.
I only know "agile" as a weaponized framework for management to bully engineers into, they hope, "work faster." It's had the opposite effect on me. TDD sounds interesting, but I've yet to internalize its merits.
Excellent presentation. I've softened thought that TDD is misnamed. Thinking it should be called "Test Driven Design" ... as the reference to "development" seems to focus "coding practices", rather than the practice of "code design" via implantation of test.
Agreed and also guilty. I’m going to try and change my workshops and use TDD in them. I think it will suit some subjects better than others? A session on refactoring code to use design patterns would be a good use case I think? I’m sure it will make attendees more confident in TDD in general?
@@leerothman2715 good point. Also, I discourage using production code as the learning curve is only steeper. On a personal note, once I got comfortable with microtechniques such as Parallel Change and Unlocking the Awesome Power of Refactoring, writing the minimal (sinful) code to get to green felt more natural and I felt confident I could refactor to something better.
I really like the idea of TDD, but haven't ever succeeded on thinking I'm doing it in a useful way. A lot of the time in development I'm testing interfaces to understand how can they be used to solve a requirement. What design can you do if you don't even fully understand the parts of a system you need to interact with? I'll tell you: A bad design...
Remember that with TDD you iterate really quickly. There's the XP idea of making baby steps in a direction that may, possibly, work. You don't even know yourself whether what you're doing will (eventually, fully) work. So you start off, make a step in the right direction, Maybe you don't even seperate concerns with an interface to start with, and just directly write a method to make a step towards a solution. Then you keep going. Eventually you have 3 methods, 4 methods in one class. Then you start noticing the SRP being a serious code smell, so you refactor, splitting the class into two, but keeping the tests you have up to that point green. Eventually you decide to improve the design further an introduce interface seperation too when there's a warrant to do this. Etc. It is *extremely* evolutionary but you'll find that as you improve at all this you'll start knowing when you likely want to introduce bigger architectural arcs. Remember also that there's the idea of "code spikes" -- intentionally throwaway code that you write to learn about how a provided API or set of API's *actually* work. Here too, you can employ TDD to play with and write throwaway experiments with new API's and code you want to use. The tests are not about the tests, they are just a place for you to document, in code, how you understand an API to work and test and improve your understanding. (I used this process when I had to write a Kafka client recently anew as a new user of Kafka. It was an extremely useful process because in playing with the Kafka client in tests, I learnt some things that I may not have known otherwise, in particular around the behaviour of Kafka when delivering messages and which ended up equipping me to make sure the code I eventually wrote was done in a robust manner.)
We programmers are never required to provide a warranty against future defects found in our Production code. Nor are we rewarded for writing Clean and maintainable (same thing really) code, but for meeting deadlines so we can go onto the next project. And also for learning the latest frameworks and libraries and tools, to polish our resumes for our next job. That adds up to a lot of distractions. So, here is the proposition I put to you, fellow professionals: "Do you take pride in your work?" In the past 7 years I have worked with a couple of hundred Java programmers all over the world. Only two of them wrote automated tests unless management forced them to - after the fact - to get 80% code coverage. My code reviews with junior and medium programmers rarely had an effect on code quality beyond the Pull Request Classes. But in a few cases the programmer started writing code that they were proud of. However, TDD is still a long way off. Dave's audience doubtless includes a lot of proud professionals. We have a lot more work to do.
Nonsense. I have worked on many projects for the military, avionic and security fields where we programmers put our names to the code we wrote. Whilst we personally will likely never get the blame for failure the company may well be held liable and traceability to root causes of failures is required. Further all our code was subject to review, one would not have a good time if one did not try to make code clearly readable and maintainable. "Do I take pride in my work? Absolutely. Luckily I have never worked with a bunch of code monkeys that cared nothing for what they churned out.
@@AllanSavolainen Quite so. What we programmers have to realise is all these catchy names for development ideas, "Clean", "Solid", "Agile", "TDD" etc are just buzzwords attached to snake oil sold to us by self proclaimed gurus selling us books, training sessions, consultancy services and RUclips vids. Magic potions that will cure all our software development ills. I'm sure there are the seeds of good ideas in all these magic cures but they are not hard and fast rules. Hardly possible given the vague nature of their formula. There is no solid, scientific, experiment we can do to demonstrate their effectiveness. Despite hand waving statistics offers by those who claim to have adopted the methods and had some success. Here is my suggestion: Do try and get your requirements down as solidly as possible. Do some design up front. For large projects with large teams you at least need to specify components/modules to distribute between team members or teams. People have to know who is going to do what. The communications between components will need to be specified. Else you cannot even start. Do use a language that tries to catch as many silly errors coders make as possible. Rust is a front runner in that respect. Do have someone review code other than the author. Do have tests in place. Strive for 100% code coverage and 100% coverage of edge cases in conditionals, loops, value ranges etc. Oh, and do test for performance where required. Finally, do strive to make code that is amenable to being read and modified. Those requirements may change or be expanded.
Great analogy with writing prose. I didn't even need to make that experiment, I already know how many mistakes I make, and I am continuously surprised that I can still find errors after the 5th re-read. Or I might decide to rearrange some text, and next time, I discover I wrote exactly the same twice. I don't really consider TDD a testing workflow, it's a feedback workflow, and it's the fast feedback that improves efficiency.
I feel that for "busywork" like everyday centering divs and making cruds... TDD is not strictly necessary, but later I'll totally test it. But for some more complex things, then TDD will help me make it. I think I could say something along the lines of: "If I know what I need, but not how: TDD. If I know how, but not exactly what... then no TDD, discover it by doing then add tests later."
@@leerothman2715 cruds are basically already done, some frameworks have generators that do a lot of the boilerplate. there are things the "design" is: be called, call this, return that.
7 месяцев назад
CRUD interface is very easy to test and usually has a clear contract. I'm surprised that no testing framework has already some basic "templates" for CRUD (Create X, Read X, Update X, Delete X). Now, almost all the time I've seen CRUD, they were either useless abstractions (the code just called a lower storage interface), or a leaky interface (the client is responsible for maintaining the consistency of the data), and so creating a test for them was also useless without a proper redefinition of the contract (making the simple CRUD test useless).
As I’ve already touched on in an earlier comment, I think most approach’s to software development is often based on opinions not on anything concrete. Why do we not take lessons from the scientific community and use experiments and observations (sounds like agile to me) to influence decisions on the way we write code? Science had their Age of Enlightenment back in the 17th century, when will get ours?
Software development today includes provisioning cloud resources with terraform or some other IAC software. How would you TDD cloud infrastructure, for example a simple real-time data pipeline with kinesis, lambda, and SQS? Or is TDD irrelevant for provisioning cloud resources?
@@francis_n - I think you're correct. But declarative code is a critical part of software development and it evolves with the project application code. Cloud infrastructure need to be thoroughly tested too. We've always had declarative code in code bases, like maven pom.xml.
@@deanschulze3129 yes you're right, it will need to be tested to ensure to functions as desired but TDD as in writing tests first and incrementally may not be suitable for provisioning cloud resources and terraform. I'm happy to be corrected. I do vouch heavily for TDD when writing more typical code like in Java etc
I LOVE TDD. It is the only way to write professional software. There is one situation in which it shouldn't be used: when exploring a solution space. But as soon as the design starts to solidify, the paradigm should shift to TDD.
I agree with your first statement, but not your second, I find TDD extremely valuable when exploring a solution. But for that to work that way takes a very strong "design" focus in your TDD, I think.
@@ContinuousDelivery to focus on design while still exploring the solution space will lead to premature choices you will regret. It is better to make throw-away proof-of-concepts in that phase. Just be sure to actually throw them away...
@@TheEvertwUsing the whiteboard in order to help thinking about the architecture is probably better than starting to write some code in that case. TDD can then be used for checking the expected behavior of the sketched model.
Speaking of coders writing their own tests, even with best intentions youre trying to plug holes by adding a slice of cheese from the same wheel and the holes might line up more easily than if you're having an independent tester.
You can group your legacy into one or multiple modules (libraries) and use them from your current entry points you keep in place ie http controllers. And then you can apply TDD from each method that is used by your entry points, or from the entry points themselves. Think hexagonal architecture and you should be able to do it quite quickly. You will then spend more time covering the legacy code you moved to the module through the public method you left open to your entry points, but actually you are just filling the « technical debt » missing test coverage you should already have inherited from your predecessors, isn’t it ?
If the legacy classes are testable, there is no reason not to do TDD. If the legacy classes are not testable, you could work towards making them testable, especially those parts that are subject to most change. That effort will soon earn itself back.
Small incremental changes to the legacy code using the strangler fig pattern will allow your legacy code to evolve into well designed and easy to change code.
It's very subtle. In the 'bad' example he's using the implementation by looking at the `.length` property of the backing field vs the `length()` method. Same with the 'get' example: in the 'bad' case he's directly accessing the array via index instead of the public api i.e. the `get(i)` method. Technically a `StringList` doesn't have to be backed by an array, even if it's the obvious implementation. However, if you couple to the array it will break when evolving.
There is more to it. And it's essential. In the good tests, the assertion calls on (assumed public) methods of the class and used the public access to the class any other class would be able to use. In the bad tests, the assertion uses (assumed protected) properties, that cannot be accessed by other classes. So in worst case, the test might work when at the same time something goes wrong, when other classes try to access the object and the code breaks.
@@Viertelhund And specifically, this has tightly coupled your tests to your implementation. So, when something changes, "1000+ unit tests all failed, so we disabled them". Another good reason not to air your Privates in Public ;p
No. The good tests hide the implementation details of StringList. You do not check item addition by looking as size, you call a Size() method. You also do not ask the item using direct lookup, but through a method. This permits me to change the underlying implementation of StringList to whatever I like as long as that implementation is passing the tests.
Thanks Dave! I've been applying TDD for a while now, but I'm struggling with something new for me. I'm trying to solve a problem that has multiple solutions, it's non deterministic. How should I approach testing? I only have laidout 'negative' tests, as in 'if this, assert this does not happen', because positive assertions seem difficult for this problem. How should I handle such type of problems?
You should test sufficient facts about each solution, that make sure that a given result is a solution, instead of testing for a specific example. But then, the function that tests whether a solution is good is code that also has to be tested beforehand. So first write tests for isThisASolution(y), then write tests for buildAnySolution(x) by doing isThisASolution(buildAnySolution(x)) for all x in an array of test inputs of your choice.
Write the tests in the implementation language. If you can't do that, use another language, or admit you're doing some BDD/TDD hybrid (in Dave's example). One of the issues for TDD is that the languages we commonly use were not designed for it, so it is easier to code without doing TDD.
Talking about Javascript for in the browser, I presume? It is about time we ditch that abomination. Though you could bring them under test by writing a simulation of the DOM etc.
You can write any integration test for any codebase in its implementation language. He choose a BDD framework in this case to present the test case in a slightly more human readable way (using Cucumber), but the underlying code that does the actual testing has the same language as the codebase itself (in this case, Java)
I disagree on your calculator example. Sure, it is important that you get the right result. But it is also important that the right input describes the right task. If your task is to do an RPN calculator, you better make sure that your calculator accepts the task in RPN form, while if your calculator is supposed to use infix notation, you should make sure that the calculator correctly accepts infix notation. If you are supposed to write an infix calculator, but all your test says is "adding 10 to 20 should give 30", and you implement instead an RPN calculator and also implement your test to use RPN as well, then your test will happily pass despite your code not doing what it is supposed to do.
The calculator example, probably not a good example? Yes, given 50 add to 70, expect 120. It can be web based, or whatever the FE to be, but its not right to test it on the FE. If I build the math library, I would test the math library instead. If I have already tested my math library, why would I test it on the FE? Would you re-test every library you includes into your application? There should also need to have a clear understanding about delegation of responsibilities. And if you have several services that shares the same function, and if you put the functiom in the library so that your services can use them, would yoi test the function on the library or EVERY service that uses it? I like the idea of outside in and behavior test, but I notice there has been a lot of confusion on how people understood it as only testing at the high level (e.g. API)... which is more like an Integration Test, and it resulted in debate of not needing low level test, which usually people dislike to write test for their code. Anyway, whats important is also to ensure that the test helps you, especially to know what went wrong and easily finding out the problem. Most of the time, high level test dont tell you what went wrong and it could also give a lot of false positive when the feature is complex and has many dependent scenarios. If a test fail and you end up spending time debugging to find what went wrong... is the test helping you? Thats like manually running and API and getting an error code. A good test is when a test failed, it tells you exactly what went wrong and where... yet, many people are arguing what is right or wrong. I'm not sure I want to be right, IF the test doesnt even helpful or beneficial for me. I'm not writing test because I have to or for showing I can write a good test, the whole reason I started and wrote test ia because I'm annoyed with manually testing, repeating it over and over again, and also debugging and finding what went wrong. When I wrote test, I want to know if I can trust the test and it can help me... if it doesnt, usually I will review and think of how I can write a better test. I also dislike writing test that are hard to read and maintain, you'll get this when you try to look back and your test or refactoring, and finally to get others in your team to understood what you're covering/testing and how easy it would be to add new scenarios to a test.
Imo the Microsoft/IBM study doesn't tell us anything about anything. It's from 20 years ago, Dave said waterfall was used, the abstract called agile a methodology (it couldn't be more ignorant than that) and it appears that the programs were toy programs and typically several tests were written at once. To begin with I don't see how anyone could take TDD seriously except as a small but essential component in the context of DORA's research findings (as shown by Dave in the video), and for Production software development (except in the case of Katas). To do TDD, you have to write Clean code or you won't be able to write one test at a time, first. You also need to be an expert software architect/designer and do DDD, because you have work to do up front, and as you go along - being agile doesn't mean you make it up as you go along.
It's not hard to do, it's hard to contextualize. I recently started a small vending machine project, and it involves code. I put that code on Github - does this code need to be done with TDD? Given that you are supposed to start with TDD, why would a small python project I built specifically as something to build with my kids need TDD? How much time do I set aside to try and test hardware - like a coin acceptor's inputs for different sizes coins - for a project that is meant for fun? The code is a small, almost insignificant aspect of the project. In other words, a lot of larger projects start from humble beginnings, and they often start in a single script, or CLI that just does something simple. In my experience, most projects don't begin with a thoroughly written requirements document - where beginning with TDD makes obvious sense. I think a lot of this TDD evangelism misses so many examples of cases where TDD from the start would seem pedantic and almost a bit narcissistic.
@@beowulf_of_wall_st you realize that Tim Berners Lee was knighted because of his ideas that anyone could publish on the web? I don't want to live in this world where every single thing needs a toolchain and test coverage. How do I know the code works? Because I've been a developer for 15 years. Further, all TDD suffers from being at least 1 degree separated from the actual code. How do you know TDD is helping you?
@@NicodemusT ... what on earth? why don't you answer my question? do you run your code manually or not? I have never found someone who gets emotional like this over something like unit testing who isn't sitting there manually refreshing pages or running code through a console because of some weird mental resistance to just writing a test function
@@beowulf_of_wall_st You sound really close to the subject, my friend. You are definitely projecting. Maybe it's time to take a seat. There's nothing emotional about pointing out that the web was not intended for your evangelism. In fact, people are highly regarded for NOT being gatekeepers. What does "do you run your code manually" even mean? You are proposing TDD because it helps you walk through your logic, and yet this is how you talk about code? Illogically? What part of "vending machine" makes you think I am refreshing pages?
@@NicodemusT Ok, if you don't want to talk about your web projects, how do you check that your code for your coin acceptor works? There are only three options, one is that you're manually runniing it, one is that you have a test suite, one is that you just assume it works. So which is it?
TDD is full of bad examples and awful courses in the internet, and the biggest d problem is the fact that everyone is trying to sell the idea of learning tdd as it was a knife or some kind of tool. Truth is knowing how to use a tool doesn’t make it useful. You need to have a purpose for the tool and that’s where everyone fails, TDD without a clear and reproducible goal won’t make any difference to your project and making clear goals is a communication problem usually addressed by BDD which also fails badly in the real world
No, they don't. But you need to know enough of Java and OOP in order to get the difference. If you know Java, you'll see that the first one obviously accesses member variables, while the second one accesses member functions. And in OOP, the general rule is that you should not access member variables, but always call member functions, even if they are just trivial getters or setters for the member variables. So basically the point the example is trying to make is that your test should not require you to access the internals of your code, only the interface. However, I consider it not a very illustrative example for that, exactly because it presumes a lot of very specific knowledge.
I like that TDD forces you to think first about good APIs and contracts. Also about how responsibility is divided between parts of the code. But once you can do that on your own, you can ignore the rest of TDD.
I don't like TDD. I rather write the code first, and then do the tests afterwards. Many will disagree with me and I don't care. If you use a strong typing langue like Haskell, you can use the typing system to catch problems at compile time. This is my preferred approach. Languages like Python and Ruby are loosy-goody when it comes to typing, so you need to write a lot more tests. TDD may actually make sense for those languages. C++? Doing TDD will be messy at best. Rust? I really don't like Rust, but at least it allows you to seamlessly write your tests along with the code. That is one feature I wish other languages had. I rather spend my time architecting the project, the algorithms, etc. Once the code is written, I'll know where the tests are needed. One developer struck me as odd -- he wanted me to write my code to make it easier to test. To me, that is like the tail wagging the dog. Well, I have seen many methodologies come and go over the decades. TDD is yet another methodology that has come and will fade away in the future.
@@leerothman2715 Test logic can have bugs too. The logic can be completely wrong. Ultimately, real world is where theories are proven. There is a place for tests, but it should be case by case, not full coverage.
@@trappedcat3615 If you write a failing test first then write the code to make it pass, then I’m not sure how it can be wrong? If you mean that the result you wanted wasn’t correct then your requirements were wrong. That’s not a problem with the test, that’s a problem with the process of gathering acceptance criteria.
@@leerothman2715 agreed, and to expand on this, TDD helps you find these errors in and missing requirements earlier when they're much easier, faster and cheaper to fix.
@@leerothman2715 The assumption is that it is always possible to know beforehand where how when why the code fails, but it's not a given. It depends on what you are doing, but you simply cannot forsee everything when your live environments are global and unpredictable. Again, I'm not advocating for no tests, just that full coverage is not necessary. In some things it should be required.
The moment you get into agile like arguments (you are doing scrum wrong etc) you know that something is off. The ugly reality of software (like everything) is that success is not about the processes, tools methodologies but the people their experience and competence. It's no wonder why on every project it's that small team of great people that make it happen, yet none admits it since it's admitting the failure of management. Competent people can use any tool and process and make it work to their benefit. Software should move, from headcount and the fallacy of cookie cutter process to competence.
Scrum is a methodology. Agile is not. Scrum ceremonies have their uses, but they have little to do with agile. I think your point is two-fold: (1) every IT department and Project has a culture (i.e., "the way we do things round here"), and if you unilaterally go against that and you have no clout, you are definitely not a team player and that doesn't help anyone, and (2) motivation and agency matter when management is absent. But don't expect robust, maintainable software.
Do you know software used to be there until this epoch of free-money arrived? Competence in software is coming back because money to budget software is not for free anymore.
@@BangsarRia agile is a bullet point manifesto, which automatically drives you to propose methodologies like Scrum... Agile Manifesto is BS... Like many other stuff naively proposed for the good, which finally ended on catastrophe...
@@joanvallve7647 Yeap I yearn for this period to come again. No free money leads to no over- hiring , no over hiring means more competent engineers. More competent engineers means less workshops less consultants and less fads that we have to put up with. Wanna make money in engineering? Deliver value and work in an actual project that makes money.
I don't get it. "Driven" implies that ones tests are pushing the software creation process along. But what are the tests designed/derived from? Presumably from some requirements, one does not start writing random tests for fun. So really we always have "Requirements Driven Design". But a bunch of source code that is the tests is not a good design document or development plan. No, we have Requirements Driven Design. Design drives the creation of some kind of design, if only to identify areas of the work that can be split off into separate chunks for different people or teams to work on. Then we can get on with code and tests. But in what order? By all means write your tests first and drive the code creation from that. Better is to have your quality assurance (test team) create the tests, from the requirements, in parallel with the devs creating the code. (test team and dev may be the same person mind). Further, if I write a bunch of tests for something and then ask you to write some code that will pass those tests you are likely to find it impossible. You cannot drive the software creation from tests. I'm all in favour of tests and testing. But logically things can never be "test driven". It makes no sense and cannot even exist. The "TDD" terminology is just wrong.
You misunderstand, it's Test Driven Development *of your implementation*, a middle layer between the design derived from the requirements ("Add 2 numbers": "We need a method that is given 2 numbers and returns the sum") and the code you write to implement it. The advantages of TDD are that it makes you design your code in a way that it can be tested and then you have the tests as a safety net when you want to refactor your implementation. BDD is the same layer but closer to the design requirement because it's a higher level language.
@@TonyWhitley Am I are right in understanding what you say as 1) From the design write code (modules, classes, methods, functions) in such a way they are easy to test. 2) Do actually write those tests? If so I'm all for it and conclude that "Test Driven" is a misnomer because we are design driven. Having spend years in the 1980's and 90's working in avionics I have to say that pretty much describes what happens when writing flight control software. Except we called it "Unit testing". We also had "integration testing". We also used a language that was designed to write units (modules, methods) that were rigorously testable. Seems to me that with the arrival of OOP with languages like C++ and Java it became all to easy for developers to produce a huge tangled mess of interdependent classes making it very hard to pull them out and test them individually. I have experienced the pain of that in recent years as I laboured to shake the bugs out of a team's work. One of the many reasons I loath OOP. And so it seems this TDD thing is just reminding devs not to do that. Thanks for trying to clear up my misunderstanding.
No, 1) design the implementation details from the requirements, breaking it down into units (e.g. "Add two numbers") 2) write a first test for one unit (e.g. "add(5, 3) == 8") 3) write your first attempt at the unit (e.g. "return (a + b)") 4) if the test fails edit your code, retest until it passes 5) write another test (e.g. "add(5.1, 3.2) == 8.3") 6) goto 4 Repeat until you're satisfied you've covered all scenarios. The tests come first and drive your implementation. Because you're continuously running unit tests you are ensuring that "developers DO NOT produce a huge tangled mess of interdependent classes making it very hard to pull them out and test them individually."
@@TonyWhitley OK. I can go with that. However if you are required to get 100% code coverage and test all edge cases, as we were in the avionics world, you cannot really create the test until the code is written. After all there is an infinite number of ways to write the unit to do that job and get through the tests you describe. Or you need a very complete "Detailed Design Specification" for the unit such that it dictates how the unit is implemented in code. Which we also did in avionics but I'm sure most don't want to do. Anyway, what you said is "tests come first and drive your implementation", but that contradicts your point 1) "Design the implementation details first." Which is "Design Driven. See why all this talk of TDD now a days confuses me, it makes no sense.
I apologise for my confusing terminology. By 1) "Design the implementation details first." I meant breaking the requirements down into blocks that are suitable for translating into code. Then write TDD for each block and use that to drive the design of the actual code. If you want 100% code coverage then 1) you have to have unit tests so why not write them first? 2) TDD will give you code that is easier to test 3) there should not be areas that are not tested because you've only written code to satisfy the test 4) you can always add more tests.
TDD is not hard if you know it Knowing makes everything easy Learning is harder for everything Programmers always go for the least resistance route Therefore programmers always prefer what they already know Therefore TDD is hard to learn because learning is hard Not because TDD itself is hard Most programmers hate when you teach them a new thing For them its just another nonsense most likely That's partly why this channel keeps making the same video so maybe it can break some more programmers resistance: TDD is not hard Kudos for that! I don't know if this is the best way, but it's one way to promote something.
It's not about learning something. Otherwise programmers wouldn't fancy learning new programming languages or frameworks for that matter, at least in the popular opinion. Doing TDD for a personal or standalone project is easy. You build it from scratch, you can progressively learn and experiment with the concept. Introducing TDD in an existing production stack where nothing was properly designed with tests and coded with a spoon is an entirely different exercise. And somehow I never heard Dave Farley speaking about that.
@@sheldonlucas4428 It's not that comprehensive, and spends like 50% of it naval gazing about scenarios that no one has any issue with, but with a narrative that he doesn't even address outside of border-line ad-hominem anecdotes.
@@NicodemusT That's a bit disconcerting. I tried TDD and got completely sold to it after a while. There's a lot more to say than the usual superficial narrative.
Yes because running the application locally and stepping through your code with a debugger is sooo much more efficient. Your prototype will gradually evolve and grow in complexity and then you’ll need to refactor, but you won’t because it will break.
It is slower to use TDD when you're not well practiced at it. I promise, with good practice, the efficiency and pace you gain from TDD will be obvious to you and you will never go back.
@@d3stinYwOw Nope. Just want to help others to avoid wasting their time on a stupid thing. So if they try it anyway, when they find themselves TDD makes no sense at all, they might remember my comment "Hey! Maybe it is not me. I already read somewhere else, TDD was useless".
🚨 ONLINE TDD COURSE | I’ve put 25+ years of training and consultancy experience into creating a course specifically designed to accelerate your understanding and application of TDD. Studying with me HAS NEVER BEEN EASIER. Find out more HERE ➡ courses.cd.training/courses/tdd-bdd-design-through-testing
Great video to watch while I'm using TDD and while it is paying dividends. I'm reverse engineering some software for which i don't have the source. The original software can export it's config as a text file. Using TDD i was able to find bugs in my code but also find bugs in the original authors code. I was working with a binary file and offsets of the data change depending on the type of record. TDD made it easy to get that right. I discovered i made a spelling mistake deep into the build. It turned out to be all over the code and tests. TDD allowed me to correct this and ensure i didn't break existing code. The hardest part has been ensuring that i have the discipline to stay the course. Thanks for the leadership on TDD. 16:03
Since I have started to apply TDD every now and then I started realizing how pointless writing tests after implementing the function is. You basically already did stuff and now you tend to write tests according to your code. It might help you find problems if your refactoring breaks the functionalty but will not make sure that your code meets the requirements in the first place. Also I love that TDD forces you to write tests that make sense... like not just try to cover every line of code but check the functionalities on a higher level. Thanks for giving me the chance to find it out!
If the tests you wrote after writing the code didn't reveal any bugs then your tests were terrible. The most vital type of testing is system level tests which not only test your application code but the infrastructure and integration points as well.
@@deanschulze3129 oh that sounds bad, but could you give me an example of a test that checks the infrastructure and integration points? like for example what would that mean for a web app or a desktop app?
You will probably also have to do load testing to verify scalability, but often this is ignored until you run into performance problems in production.
@@AleksandraSetsumei - For a web app you would start by testing basic CRUD functionality on the endpoints. You would also have to write tests to verify that business logic is working properly. It's usually best to write these end-end tests in the same language you used to write application code in.
@@deanschulze3129 okay thanks I'll look into it. Till now I mostly write integration or unit tests.
Hey Dave can you do a video of a team doing trunk based development, I struggle to understand how it works in practice.
He already has, just search for "continuous delivery don't branch"
It's the same reason why (good) Agile is rarely used. It's not that its hard, its that you have to unlearn so many things that were previously taken to be obviously true.
It's the same. Agile is as useless as TDD. That's the reason why nobody does TDD and that's the reason why people are massively stopping doing 'agile' methodologies. Both are useless... Tough 'agile' might have some interesting points. TDD not even that.
@@joanvallve7647 TDD is as useless as UML. Read that as "people that can't do UML properly see little value in UML". Ignore the fact that having thought out things in your sequence and state diagrams saved you A LOT of time writing the wrong thing that you then had to refactor and kludge into something workable. Ignore the fact that the diagrams themselves are documentation of the system. Ignore the fact that they give you a good estimation on how and how much changes can or will break the system.
tldr: React Andy's will never grep the value of systems architecture, which is OK as their code won't be in use long enough to be an issue.
I only know "agile" as a weaponized framework for management to bully engineers into, they hope, "work faster." It's had the opposite effect on me. TDD sounds interesting, but I've yet to internalize its merits.
@@scyth2 So, you experienced what Agile really is and now you know it. Keep in mind that Agile also 'sounded interesting' before you tried it.
Dave you have the most incredible shirts. I bought your TDD training and am teaching my team, but only because of your badass shirts.
Excellent presentation. I've softened thought that TDD is misnamed. Thinking it should be called "Test Driven Design" ... as the reference to "development" seems to focus "coding practices", rather than the practice of "code design" via implantation of test.
I have noticed, when running workshops, that folks seem numb to the design choices they make and thus don't seem to benefit from TDD.
Agreed and also guilty. I’m going to try and change my workshops and use TDD in them. I think it will suit some subjects better than others? A session on refactoring code to use design patterns would be a good use case I think? I’m sure it will make attendees more confident in TDD in general?
@@leerothman2715 good point. Also, I discourage using production code as the learning curve is only steeper. On a personal note, once I got comfortable with microtechniques such as Parallel Change and Unlocking the Awesome Power of Refactoring, writing the minimal (sinful) code to get to green felt more natural and I felt confident I could refactor to something better.
I really like the idea of TDD, but haven't ever succeeded on thinking I'm doing it in a useful way. A lot of the time in development I'm testing interfaces to understand how can they be used to solve a requirement. What design can you do if you don't even fully understand the parts of a system you need to interact with? I'll tell you: A bad design...
Remember that with TDD you iterate really quickly. There's the XP idea of making baby steps in a direction that may, possibly, work. You don't even know yourself whether what you're doing will (eventually, fully) work. So you start off, make a step in the right direction, Maybe you don't even seperate concerns with an interface to start with, and just directly write a method to make a step towards a solution. Then you keep going. Eventually you have 3 methods, 4 methods in one class. Then you start noticing the SRP being a serious code smell, so you refactor, splitting the class into two, but keeping the tests you have up to that point green. Eventually you decide to improve the design further an introduce interface seperation too when there's a warrant to do this. Etc. It is *extremely* evolutionary but you'll find that as you improve at all this you'll start knowing when you likely want to introduce bigger architectural arcs.
Remember also that there's the idea of "code spikes" -- intentionally throwaway code that you write to learn about how a provided API or set of API's *actually* work. Here too, you can employ TDD to play with and write throwaway experiments with new API's and code you want to use. The tests are not about the tests, they are just a place for you to document, in code, how you understand an API to work and test and improve your understanding. (I used this process when I had to write a Kafka client recently anew as a new user of Kafka. It was an extremely useful process because in playing with the Kafka client in tests, I learnt some things that I may not have known otherwise, in particular around the behaviour of Kafka when delivering messages and which ended up equipping me to make sure the code I eventually wrote was done in a robust manner.)
We programmers are never required to provide a warranty against future defects found in our Production code. Nor are we rewarded for writing Clean and maintainable (same thing really) code, but for meeting deadlines so we can go onto the next project. And also for learning the latest frameworks and libraries and tools, to polish our resumes for our next job. That adds up to a lot of distractions. So, here is the proposition I put to you, fellow professionals: "Do you take pride in your work?"
In the past 7 years I have worked with a couple of hundred Java programmers all over the world. Only two of them wrote automated tests unless management forced them to - after the fact - to get 80% code coverage. My code reviews with junior and medium programmers rarely had an effect on code quality beyond the Pull Request Classes. But in a few cases the programmer started writing code that they were proud of. However, TDD is still a long way off.
Dave's audience doubtless includes a lot of proud professionals. We have a lot more work to do.
Nonsense. I have worked on many projects for the military, avionic and security fields where we programmers put our names to the code we wrote. Whilst we personally will likely never get the blame for failure the company may well be held liable and traceability to root causes of failures is required. Further all our code was subject to review, one would not have a good time if one did not try to make code clearly readable and maintainable.
"Do I take pride in my work? Absolutely. Luckily I have never worked with a bunch of code monkeys that cared nothing for what they churned out.
If by Clean you mean Clean Code(tm) then I would not call it maintainable, assuming you follow all the CC(tm) guidelines.
@@AllanSavolainen Quite so. What we programmers have to realise is all these catchy names for development ideas, "Clean", "Solid", "Agile", "TDD" etc are just buzzwords attached to snake oil sold to us by self proclaimed gurus selling us books, training sessions, consultancy services and RUclips vids. Magic potions that will cure all our software development ills.
I'm sure there are the seeds of good ideas in all these magic cures but they are not hard and fast rules. Hardly possible given the vague nature of their formula. There is no solid, scientific, experiment we can do to demonstrate their effectiveness. Despite hand waving statistics offers by those who claim to have adopted the methods and had some success.
Here is my suggestion:
Do try and get your requirements down as solidly as possible.
Do some design up front. For large projects with large teams you at least need to specify components/modules to distribute between team members or teams. People have to know who is going to do what. The communications between components will need to be specified. Else you cannot even start.
Do use a language that tries to catch as many silly errors coders make as possible. Rust is a front runner in that respect.
Do have someone review code other than the author.
Do have tests in place. Strive for 100% code coverage and 100% coverage of edge cases in conditionals, loops, value ranges etc. Oh, and do test for performance where required.
Finally, do strive to make code that is amenable to being read and modified. Those requirements may change or be expanded.
Great analogy with writing prose. I didn't even need to make that experiment, I already know how many mistakes I make, and I am continuously surprised that I can still find errors after the 5th re-read. Or I might decide to rearrange some text, and next time, I discover I wrote exactly the same twice. I don't really consider TDD a testing workflow, it's a feedback workflow, and it's the fast feedback that improves efficiency.
I feel that for "busywork" like everyday centering divs and making cruds... TDD is not strictly necessary, but later I'll totally test it.
But for some more complex things, then TDD will help me make it.
I think I could say something along the lines of: "If I know what I need, but not how: TDD. If I know how, but not exactly what... then no TDD, discover it by doing then add tests later."
Errr I think you’re missing one of the major points of test first. Tests after will not help you with the design because it’s already done.
@@leerothman2715 cruds are basically already done, some frameworks have generators that do a lot of the boilerplate.
there are things the "design" is: be called, call this, return that.
CRUD interface is very easy to test and usually has a clear contract. I'm surprised that no testing framework has already some basic "templates" for CRUD (Create X, Read X, Update X, Delete X).
Now, almost all the time I've seen CRUD, they were either useless abstractions (the code just called a lower storage interface), or a leaky interface (the client is responsible for maintaining the consistency of the data), and so creating a test for them was also useless without a proper redefinition of the contract (making the simple CRUD test useless).
As I’ve already touched on in an earlier comment, I think most approach’s to software development is often based on opinions not on anything concrete. Why do we not take lessons from the scientific community and use experiments and observations (sounds like agile to me) to influence decisions on the way we write code? Science had their Age of Enlightenment back in the 17th century, when will get ours?
Software development today includes provisioning cloud resources with terraform or some other IAC software. How would you TDD cloud infrastructure, for example a simple real-time data pipeline with kinesis, lambda, and SQS?
Or is TDD irrelevant for provisioning cloud resources?
Provisioning cloud and terraform is mainly declarative and configuration setup. I don't think TDD can be applied to that
@@francis_n - I think you're correct. But declarative code is a critical part of software development and it evolves with the project application code. Cloud infrastructure need to be thoroughly tested too.
We've always had declarative code in code bases, like maven pom.xml.
All code is interpreted at some point.
Unfortunately, Maven is not the be all and end all
That’s what a CD process will help with.
@@deanschulze3129 yes you're right, it will need to be tested to ensure to functions as desired but TDD as in writing tests first and incrementally may not be suitable for provisioning cloud resources and terraform. I'm happy to be corrected. I do vouch heavily for TDD when writing more typical code like in Java etc
I LOVE TDD. It is the only way to write professional software.
There is one situation in which it shouldn't be used: when exploring a solution space. But as soon as the design starts to solidify, the paradigm should shift to TDD.
I agree with your first statement, but not your second, I find TDD extremely valuable when exploring a solution. But for that to work that way takes a very strong "design" focus in your TDD, I think.
@@ContinuousDelivery to focus on design while still exploring the solution space will lead to premature choices you will regret. It is better to make throw-away proof-of-concepts in that phase. Just be sure to actually throw them away...
@@TheEvertwUsing the whiteboard in order to help thinking about the architecture is probably better than starting to write some code in that case. TDD can then be used for checking the expected behavior of the sketched model.
@@tdp-pop6810 White-boards don't give feedback.
Selling TDD course while arguing for TDD doesn't really help the argument... :-/
Speaking of coders writing their own tests, even with best intentions youre trying to plug holes by adding a slice of cheese from the same wheel and the holes might line up more easily than if you're having an independent tester.
Id like to do tdd but always working on massive legacy classes 😢
You can group your legacy into one or multiple modules (libraries) and use them from your current entry points you keep in place ie http controllers.
And then you can apply TDD from each method that is used by your entry points, or from the entry points themselves.
Think hexagonal architecture and you should be able to do it quite quickly.
You will then spend more time covering the legacy code you moved to the module through the public method you left open to your entry points, but actually you are just filling the « technical debt » missing test coverage you should already have inherited from your predecessors, isn’t it ?
@@user-de8bt9co8c very good advice, ty
If the legacy classes are testable, there is no reason not to do TDD.
If the legacy classes are not testable, you could work towards making them testable, especially those parts that are subject to most change. That effort will soon earn itself back.
@@TheEvertw OFC, a class having +20 dependencies is "testable". Welcome to the mock party.
Small incremental changes to the legacy code using the strangler fig pattern will allow your legacy code to evolve into well designed and easy to change code.
I didn't get the difference between the good and bad code you mentioned, except the test name. Is that it?
It's very subtle. In the 'bad' example he's using the implementation by looking at the `.length` property of the backing field vs the `length()` method. Same with the 'get' example: in the 'bad' case he's directly accessing the array via index instead of the public api i.e. the `get(i)` method. Technically a `StringList` doesn't have to be backed by an array, even if it's the obvious implementation. However, if you couple to the array it will break when evolving.
There is more to it. And it's essential. In the good tests, the assertion calls on (assumed public) methods of the class and used the public access to the class any other class would be able to use. In the bad tests, the assertion uses (assumed protected) properties, that cannot be accessed by other classes. So in worst case, the test might work when at the same time something goes wrong, when other classes try to access the object and the code breaks.
@@Viertelhund And specifically, this has tightly coupled your tests to your implementation. So, when something changes, "1000+ unit tests all failed, so we disabled them". Another good reason not to air your Privates in Public ;p
@@ossirioth yeah all these people playing around with their privates all day and they're surprised when it causes problems at work
No. The good tests hide the implementation details of StringList. You do not check item addition by looking as size, you call a Size() method. You also do not ask the item using direct lookup, but through a method. This permits me to change the underlying implementation of StringList to whatever I like as long as that implementation is passing the tests.
Thanks Dave! I've been applying TDD for a while now, but I'm struggling with something new for me. I'm trying to solve a problem that has multiple solutions, it's non deterministic.
How should I approach testing? I only have laidout 'negative' tests, as in 'if this, assert this does not happen', because positive assertions seem difficult for this problem.
How should I handle such type of problems?
You should test sufficient facts about each solution, that make sure that a given result is a solution, instead of testing for a specific example. But then, the function that tests whether a solution is good is code that also has to be tested beforehand. So first write tests for isThisASolution(y), then write tests for buildAnySolution(x) by doing isThisASolution(buildAnySolution(x)) for all x in an array of test inputs of your choice.
How do you feel about Use Case Development?
Are those comments in your tests, Dave?
Write the tests in the implementation language. If you can't do that, use another language, or admit you're doing some BDD/TDD hybrid (in Dave's example).
One of the issues for TDD is that the languages we commonly use were not designed for it, so it is easier to code without doing TDD.
Talking about Javascript for in the browser, I presume?
It is about time we ditch that abomination. Though you could bring them under test by writing a simulation of the DOM etc.
You can write any integration test for any codebase in its implementation language. He choose a BDD framework in this case to present the test case in a slightly more human readable way (using Cucumber), but the underlying code that does the actual testing has the same language as the codebase itself (in this case, Java)
Can you possibly speak about TDD for Game dev?
I already have, ruclips.net/video/17esmz3X7tw/видео.html
but also keep an eye out for an upcoming "Engineering Room" podcast.
wow, I love your videos and podcast !!! AWESOME !
Wow, thank you!
I disagree on your calculator example. Sure, it is important that you get the right result. But it is also important that the right input describes the right task. If your task is to do an RPN calculator, you better make sure that your calculator accepts the task in RPN form, while if your calculator is supposed to use infix notation, you should make sure that the calculator correctly accepts infix notation. If you are supposed to write an infix calculator, but all your test says is "adding 10 to 20 should give 30", and you implement instead an RPN calculator and also implement your test to use RPN as well, then your test will happily pass despite your code not doing what it is supposed to do.
The calculator example, probably not a good example? Yes, given 50 add to 70, expect 120. It can be web based, or whatever the FE to be, but its not right to test it on the FE. If I build the math library, I would test the math library instead. If I have already tested my math library, why would I test it on the FE? Would you re-test every library you includes into your application? There should also need to have a clear understanding about delegation of responsibilities.
And if you have several services that shares the same function, and if you put the functiom in the library so that your services can use them, would yoi test the function on the library or EVERY service that uses it?
I like the idea of outside in and behavior test, but I notice there has been a lot of confusion on how people understood it as only testing at the high level (e.g. API)... which is more like an Integration Test, and it resulted in debate of not needing low level test, which usually people dislike to write test for their code.
Anyway, whats important is also to ensure that the test helps you, especially to know what went wrong and easily finding out the problem. Most of the time, high level test dont tell you what went wrong and it could also give a lot of false positive when the feature is complex and has many dependent scenarios. If a test fail and you end up spending time debugging to find what went wrong... is the test helping you? Thats like manually running and API and getting an error code. A good test is when a test failed, it tells you exactly what went wrong and where... yet, many people are arguing what is right or wrong. I'm not sure I want to be right, IF the test doesnt even helpful or beneficial for me. I'm not writing test because I have to or for showing I can write a good test, the whole reason I started and wrote test ia because I'm annoyed with manually testing, repeating it over and over again, and also debugging and finding what went wrong. When I wrote test, I want to know if I can trust the test and it can help me... if it doesnt, usually I will review and think of how I can write a better test. I also dislike writing test that are hard to read and maintain, you'll get this when you try to look back and your test or refactoring, and finally to get others in your team to understood what you're covering/testing and how easy it would be to add new scenarios to a test.
Write good tests you can trust, is the hardest part.
Love the Bender the conqueror shirt
Imo the Microsoft/IBM study doesn't tell us anything about anything. It's from 20 years ago, Dave said waterfall was used, the abstract called agile a methodology (it couldn't be more ignorant than that) and it appears that the programs were toy programs and typically several tests were written at once.
To begin with I don't see how anyone could take TDD seriously except as a small but essential component in the context of DORA's research findings (as shown by Dave in the video), and for Production software development (except in the case of Katas).
To do TDD, you have to write Clean code or you won't be able to write one test at a time, first. You also need to be an expert software architect/designer and do DDD, because you have work to do up front, and as you go along - being agile doesn't mean you make it up as you go along.
It's not hard to do, it's hard to contextualize. I recently started a small vending machine project, and it involves code. I put that code on Github - does this code need to be done with TDD? Given that you are supposed to start with TDD, why would a small python project I built specifically as something to build with my kids need TDD? How much time do I set aside to try and test hardware - like a coin acceptor's inputs for different sizes coins - for a project that is meant for fun? The code is a small, almost insignificant aspect of the project.
In other words, a lot of larger projects start from humble beginnings, and they often start in a single script, or CLI that just does something simple. In my experience, most projects don't begin with a thoroughly written requirements document - where beginning with TDD makes obvious sense. I think a lot of this TDD evangelism misses so many examples of cases where TDD from the start would seem pedantic and almost a bit narcissistic.
how do you know the code works at all? TDD is less work than manually running it
@@beowulf_of_wall_st you realize that Tim Berners Lee was knighted because of his ideas that anyone could publish on the web? I don't want to live in this world where every single thing needs a toolchain and test coverage. How do I know the code works? Because I've been a developer for 15 years. Further, all TDD suffers from being at least 1 degree separated from the actual code. How do you know TDD is helping you?
@@NicodemusT ... what on earth? why don't you answer my question? do you run your code manually or not? I have never found someone who gets emotional like this over something like unit testing who isn't sitting there manually refreshing pages or running code through a console because of some weird mental resistance to just writing a test function
@@beowulf_of_wall_st You sound really close to the subject, my friend. You are definitely projecting. Maybe it's time to take a seat. There's nothing emotional about pointing out that the web was not intended for your evangelism. In fact, people are highly regarded for NOT being gatekeepers. What does "do you run your code manually" even mean? You are proposing TDD because it helps you walk through your logic, and yet this is how you talk about code? Illogically? What part of "vending machine" makes you think I am refreshing pages?
@@NicodemusT Ok, if you don't want to talk about your web projects, how do you check that your code for your coin acceptor works? There are only three options, one is that you're manually runniing it, one is that you have a test suite, one is that you just assume it works. So which is it?
TDD is full of bad examples and awful courses in the internet, and the biggest d problem is the fact that everyone is trying to sell the idea of learning tdd as it was a knife or some kind of tool. Truth is knowing how to use a tool doesn’t make it useful. You need to have a purpose for the tool and that’s where everyone fails, TDD without a clear and reproducible goal won’t make any difference to your project and making clear goals is a communication problem usually addressed by BDD which also fails badly in the real world
_TDD Isn't Hard, It's Something Else..._
😏
The bad test and good test looks the same? Mistake?
No, they don't. But you need to know enough of Java and OOP in order to get the difference. If you know Java, you'll see that the first one obviously accesses member variables, while the second one accesses member functions. And in OOP, the general rule is that you should not access member variables, but always call member functions, even if they are just trivial getters or setters for the member variables.
So basically the point the example is trying to make is that your test should not require you to access the internals of your code, only the interface. However, I consider it not a very illustrative example for that, exactly because it presumes a lot of very specific knowledge.
Ah, subtle difference between .size vs .size() that totally overlooked.
Thank for the explanation! 👍
Amazing T-Shirt
If you did not test it, it does not work
false
Not really the point of the video.
You can't rely on developers testing their own code. If someone else hasn't used it, it doesn't work. I believe John Osterhout said that.
Just because you tested, doesn't mean it works either 😂
@@jasondads9509so true
I like that TDD forces you to think first about good APIs and contracts. Also about how responsibility is divided between parts of the code. But once you can do that on your own, you can ignore the rest of TDD.
You've made a good start, which is rare. I suggest watching some Kent Beck, Uncle Bob and Jakub Nabrdalik RUclipss
It would be nice if you share your thoughts on the relevance of TDD to Agile Project Managers and how they can improve TDD 😊 developing teams
‘Agile project managers’ sounds like an oxymoron to me 😀.
@leerothman2715 last I checked I didn't ask a question about sounds or figures of speech.
I don't like TDD. I rather write the code first, and then do the tests afterwards. Many will disagree with me and I don't care.
If you use a strong typing langue like Haskell, you can use the typing system to catch problems at compile time. This is my preferred approach.
Languages like Python and Ruby are loosy-goody when it comes to typing, so you need to write a lot more tests. TDD may actually make sense for those languages.
C++? Doing TDD will be messy at best.
Rust? I really don't like Rust, but at least it allows you to seamlessly write your tests along with the code. That is one feature I wish other languages had.
I rather spend my time architecting the project, the algorithms, etc. Once the code is written, I'll know where the tests are needed.
One developer struck me as odd -- he wanted me to write my code to make it easier to test. To me, that is like the tail wagging the dog.
Well, I have seen many methodologies come and go over the decades. TDD is yet another methodology that has come and will fade away in the future.
Some TDD is a waste of time, it takes up half the process, is never enough, and often distracts from solving real world problems and bugs.
You have bugs then, enough said.
@@leerothman2715 Test logic can have bugs too. The logic can be completely wrong. Ultimately, real world is where theories are proven. There is a place for tests, but it should be case by case, not full coverage.
@@trappedcat3615 If you write a failing test first then write the code to make it pass, then I’m not sure how it can be wrong? If you mean that the result you wanted wasn’t correct then your requirements were wrong. That’s not a problem with the test, that’s a problem with the process of gathering acceptance criteria.
@@leerothman2715 agreed, and to expand on this, TDD helps you find these errors in and missing requirements earlier when they're much easier, faster and cheaper to fix.
@@leerothman2715 The assumption is that it is always possible to know beforehand where how when why the code fails, but it's not a given. It depends on what you are doing, but you simply cannot forsee everything when your live environments are global and unpredictable. Again, I'm not advocating for no tests, just that full coverage is not necessary. In some things it should be required.
The moment you get into agile like arguments (you are doing scrum wrong etc) you know that something is off. The ugly reality of software (like everything) is that success is not about the processes, tools methodologies but the people their experience and competence. It's no wonder why on every project it's that small team of great people that make it happen, yet none admits it since it's admitting the failure of management. Competent people can use any tool and process and make it work to their benefit. Software should move, from headcount and the fallacy of cookie cutter process to competence.
Scrum is a methodology. Agile is not. Scrum ceremonies have their uses, but they have little to do with agile.
I think your point is two-fold: (1) every IT department and Project has a culture (i.e., "the way we do things round here"), and if you unilaterally go against that and you have no clout, you are definitely not a team player and that doesn't help anyone, and (2) motivation and agency matter when management is absent.
But don't expect robust, maintainable software.
Do you know software used to be there until this epoch of free-money arrived? Competence in software is coming back because money to budget software is not for free anymore.
@@BangsarRia agile is a bullet point manifesto, which automatically drives you to propose methodologies like Scrum... Agile Manifesto is BS... Like many other stuff naively proposed for the good, which finally ended on catastrophe...
@@BangsarRiaBy the way..... Robust and sustainable software has NOTHING to do with agile.
@@joanvallve7647 Yeap I yearn for this period to come again. No free money leads to no over- hiring , no over hiring means more competent engineers. More competent engineers means less workshops less consultants and less fads that we have to put up with. Wanna make money in engineering? Deliver value and work in an actual project that makes money.
It's Othello.
I don't get it. "Driven" implies that ones tests are pushing the software creation process along. But what are the tests designed/derived from? Presumably from some requirements, one does not start writing random tests for fun. So really we always have "Requirements Driven Design". But a bunch of source code that is the tests is not a good design document or development plan.
No, we have Requirements Driven Design. Design drives the creation of some kind of design, if only to identify areas of the work that can be split off into separate chunks for different people or teams to work on. Then we can get on with code and tests. But in what order? By all means write your tests first and drive the code creation from that. Better is to have your quality assurance (test team) create the tests, from the requirements, in parallel with the devs creating the code. (test team and dev may be the same person mind).
Further, if I write a bunch of tests for something and then ask you to write some code that will pass those tests you are likely to find it impossible. You cannot drive the software creation from tests.
I'm all in favour of tests and testing. But logically things can never be "test driven". It makes no sense and cannot even exist. The "TDD" terminology is just wrong.
You misunderstand, it's Test Driven Development *of your implementation*, a middle layer between the design derived from the requirements ("Add 2 numbers": "We need a method that is given 2 numbers and returns the sum") and the code you write to implement it. The advantages of TDD are that it makes you design your code in a way that it can be tested and then you have the tests as a safety net when you want to refactor your implementation. BDD is the same layer but closer to the design requirement because it's a higher level language.
@@TonyWhitley Am I are right in understanding what you say as 1) From the design write code (modules, classes, methods, functions) in such a way they are easy to test. 2) Do actually write those tests? If so I'm all for it and conclude that "Test Driven" is a misnomer because we are design driven.
Having spend years in the 1980's and 90's working in avionics I have to say that pretty much describes what happens when writing flight control software. Except we called it "Unit testing". We also had "integration testing". We also used a language that was designed to write units (modules, methods) that were rigorously testable.
Seems to me that with the arrival of OOP with languages like C++ and Java it became all to easy for developers to produce a huge tangled mess of interdependent classes making it very hard to pull them out and test them individually. I have experienced the pain of that in recent years as I laboured to shake the bugs out of a team's work. One of the many reasons I loath OOP. And so it seems this TDD thing is just reminding devs not to do that.
Thanks for trying to clear up my misunderstanding.
No,
1) design the implementation details from the requirements, breaking it down into units (e.g. "Add two numbers")
2) write a first test for one unit (e.g. "add(5, 3) == 8")
3) write your first attempt at the unit (e.g. "return (a + b)")
4) if the test fails edit your code, retest until it passes
5) write another test (e.g. "add(5.1, 3.2) == 8.3")
6) goto 4
Repeat until you're satisfied you've covered all scenarios.
The tests come first and drive your implementation. Because you're continuously running unit tests you are ensuring that "developers DO NOT produce a huge tangled mess of interdependent classes making it very hard to pull them out and test them individually."
@@TonyWhitley OK. I can go with that. However if you are required to get 100% code coverage and test all edge cases, as we were in the avionics world, you cannot really create the test until the code is written. After all there is an infinite number of ways to write the unit to do that job and get through the tests you describe. Or you need a very complete "Detailed Design Specification" for the unit such that it dictates how the unit is implemented in code. Which we also did in avionics but I'm sure most don't want to do. Anyway, what you said is "tests come first and drive your implementation", but that contradicts your point 1) "Design the implementation details first." Which is "Design Driven. See why all this talk of TDD now a days confuses me, it makes no sense.
I apologise for my confusing terminology. By 1) "Design the implementation details first." I meant breaking the requirements down into blocks that are suitable for translating into code. Then write TDD for each block and use that to drive the design of the actual code.
If you want 100% code coverage then 1) you have to have unit tests so why not write them first? 2) TDD will give you code that is easier to test 3) there should not be areas that are not tested because you've only written code to satisfy the test 4) you can always add more tests.
Cool haircut
Oof, the sneaky plugs are a little off putting, but good video outside of that
TDD is not hard if you know it
Knowing makes everything easy
Learning is harder for everything
Programmers always go for the least resistance route
Therefore programmers always prefer what they already know
Therefore TDD is hard to learn because learning is hard
Not because TDD itself is hard
Most programmers hate when you teach them a new thing
For them its just another nonsense most likely
That's partly why this channel keeps making the same video so maybe it can break some more programmers resistance: TDD is not hard
Kudos for that!
I don't know if this is the best way, but it's one way to promote something.
It's not about learning something. Otherwise programmers wouldn't fancy learning new programming languages or frameworks for that matter, at least in the popular opinion.
Doing TDD for a personal or standalone project is easy. You build it from scratch, you can progressively learn and experiment with the concept.
Introducing TDD in an existing production stack where nothing was properly designed with tests and coded with a spoon is an entirely different exercise. And somehow I never heard Dave Farley speaking about that.
@@vladinosky He has in a video did a walk thru with legacy code dont recall so do a search for it
@@vladinosky He will never address anything outside the most plain, practical and perfect circumstances.
@@sheldonlucas4428 It's not that comprehensive, and spends like 50% of it naval gazing about scenarios that no one has any issue with, but with a narrative that he doesn't even address outside of border-line ad-hominem anecdotes.
@@NicodemusT That's a bit disconcerting. I tried TDD and got completely sold to it after a while. There's a lot more to say than the usual superficial narrative.
TDD is not complex. It is just inefficient, especially for a startup’s fast moving prototype.
Not according to what data we have.
Yes because running the application locally and stepping through your code with a debugger is sooo much more efficient. Your prototype will gradually evolve and grow in complexity and then you’ll need to refactor, but you won’t because it will break.
It is slower to use TDD when you're not well practiced at it. I promise, with good practice, the efficiency and pace you gain from TDD will be obvious to you and you will never go back.
In my experience it is much faster to write code without TDD.
For about ten minutes. Maybe fifteen in ideal cases.
@@dtkedtyjrtyj try to write code slower. this is not a race competition about who writes code faster if the result is garbage
*Click bait. Not everyone got TDD wrong. So it's the perfect time to down-vote this video* 🙂
It's not hard. TDD is just useless.
Care to elaborate?
@@d3stinYwOw Nope. Just want to help others to avoid wasting their time on a stupid thing. So if they try it anyway, when they find themselves TDD makes no sense at all, they might remember my comment "Hey! Maybe it is not me. I already read somewhere else, TDD was useless".
@@joanvallve7647 It's not an argument :)
TDD makes perfect sense.
@@d3stinYwOw Yours neither ;-) Nope. TDD is useless (99.7% of the times).
@@joanvallve7647 better than yours. Now we dropped from 100% of times where TDD is 'useless' (when it's not) to 99.7. Few times and we will agree ;)