Rewarding at work. Spend 3 to 4 times the amount of time to produce the same thing. Produce 2 to 3 times the code that has to be maintained. Your companies cost increased and the amount of time to produce the same product increases. Yet, the cost of running the business and hourly wages, electricity, property cost and so on all stay the same. Sure do this if you like the unemployment line being in your future or your company going bankrupt.
When you’re regularly using TDD it doesn’t take 3/4 times as long. Also you don’t need to maintain your tests, if your tests need maintaining then your tests are bad tests. You only ever test the public interface, which shouldn’t change regularly.
It's plainly clear that you have never been part of a quality software operation and I would never want to touch or be affected by the programs you're responsible for.
At first, yes. I can attest to that. It takes significant skill in this method before it yields results. But it does allow you to prove that your work... works. (Assuming that the tests are correct.) It also helps guide you to a solution. So it can be useful in complex systems. You definitely should decide per project, or even per module in a project, whether you want to apply TDD or not. And keep in mind, having to write tests afterwards is even less fun.
I hate TDD if anyone who I hire ever suggest it it will be their last day at work for me. It serves no good purpose in my opinion. You create code to test other code but you don't create code to test the code that is testing the other code. That is like using a un-calibrated power meter to test and calibrate another meter. It is just stupid! I've seen people screw up the test code. In fact there are youtube videos showing people do that. But lets say you want to modify the way something works so then you have right more test code just to update that function or class or first. I've never once seen the best code result come from TDD. It instead encourages people to look at only small issues rather than look at the larger picture in solving something. So rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes. By the time they get to the point were they have something working they don't want to go through and do the work of refactoring the primary work to improve it and choose to just leave it as is. You end up with 3 to 10 times the code written just to get the same project done. You wonder why your over budget and costs are going through the roof. The only programmers i know who love this crap are amateurs and people getting paid by the line or hour in code.
_"but you don't create code to test the code that is testing the other code"_ In this video, Bob did that by first making the test fail, and then making it pass. It's true that that only tests the test in that moment. It's not a test regression test. (Whoo, complicated names here! xD) But it's better than writing tests after the fact, that have only ever succeeded. TDD or no TDD, tests testing tests is not something that comes naturally either way. In both cases you have to put in the same effort to accomplish that, or you accept not testing tests. This does not affect your choice whether to use TDD or not. _"I've seen people screw up the test code."_ I wonder if these people have applied TDD in the optimal way. Not that there's ever a guarantee for correct test code. That's not the case ever. This does not affect your choice whether to use TDD or not. _"It instead encourages people to look at only small issues rather than look at the larger picture in solving something."_ I think that is what you want! At the moment, you're writing a unit. Focus on the unit. Make sure that that does what you want it to do. Once finished, you take a step back, and look at the picture one step above the unit: the module. You can apply TDD to the module also. Once the module does what you want it to do, take a step back, and look at the picture above that: the program. And, you guessed it, you can apply TDD to the program also! Losing sight of the bigger picture is not a TDD problem. Because you can apply TDD on all levels. (Or BDD if that is your jam.) _" rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes"_ Now this is an actual concern. One that I don't know the answer to. I would say that this should be thought about during the refactor steps after each increment of the TDD process. Make the test fail, write code to make it pass, refactor. When people refactor, they should engage with the larger picture at least a little bit. I can imagine that this takes experience to pull off well. You also voice concerns over time and costs. And I understand why. Programming with TDD takes time. Especially if programmers aren't already quite experienced with TDD. The hope is, and the promise is, that TDD helps you win that time back by preventing bugs and making them easier to solve. It's hard to sell, because you don't normally see this trade-off. You don't see the time you don't spend. You only see that TDD takes more time during development. I won't say that TDD will make true on its promise. That is up to the developer. Hopefully other people will share their thoughts, because I find this an interesting topic. It's fascinating to see the different pros and cons of TDD, or any methodology.
You wouldn't last long in my team because we use TDD every day and most of our code is written that way. Why we do it? Because it makes our life easier. Yes, writing a new feature takes more time, that's a fact. But after time, this investment pays off. Good tests that test behaviour (not implementation) give quick feedback that the new code we wrote did not break previously implemented features. It also allows you to change the internal structure of the tested module (unit) in a safe way (refactoring), so the code does not get worse over time. I think the most important part is learning how to write good tests. Here Uncle Bob shows us a simple example. A real live example where you have a module, not a class, with some dependencies, maybe infrastructure like the database or network, etc. would be better, but that's hard to do in an hour in front of 100 people.
Amazing!
Very fun!
Only 3 concepts: Parameters, Subject and Informational Individual! This is the future in software!
This exercise looks a lot how AI tries to write code for me 😂
Stack, Stack and Stack .... but the future in software is Universal Software Model! Much more simple.
Rewarding at work. Spend 3 to 4 times the amount of time to produce the same thing. Produce 2 to 3 times the code that has to be maintained. Your companies cost increased and the amount of time to produce the same product increases. Yet, the cost of running the business and hourly wages, electricity, property cost and so on all stay the same. Sure do this if you like the unemployment line being in your future or your company going bankrupt.
When you’re regularly using TDD it doesn’t take 3/4 times as long. Also you don’t need to maintain your tests, if your tests need maintaining then your tests are bad tests.
You only ever test the public interface, which shouldn’t change regularly.
It's plainly clear that you have never been part of a quality software operation and I would never want to touch or be affected by the programs you're responsible for.
This methodology seems so unfun and draining 🤔
At first, yes. I can attest to that. It takes significant skill in this method before it yields results.
But it does allow you to prove that your work... works. (Assuming that the tests are correct.)
It also helps guide you to a solution. So it can be useful in complex systems.
You definitely should decide per project, or even per module in a project, whether you want to apply TDD or not.
And keep in mind, having to write tests afterwards is even less fun.
Programming isn’t supposed to be fun. It’s a job.
@@TheRafark Programming is fun. But successfully delivering requirements is not.
I hate TDD if anyone who I hire ever suggest it it will be their last day at work for me. It serves no good purpose in my opinion. You create code to test other code but you don't create code to test the code that is testing the other code. That is like using a un-calibrated power meter to test and calibrate another meter. It is just stupid!
I've seen people screw up the test code. In fact there are youtube videos showing people do that. But lets say you want to modify the way something works so then you have right more test code just to update that function or class or first. I've never once seen the best code result come from TDD. It instead encourages people to look at only small issues rather than look at the larger picture in solving something. So rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes. By the time they get to the point were they have something working they don't want to go through and do the work of refactoring the primary work to improve it and choose to just leave it as is. You end up with 3 to 10 times the code written just to get the same project done. You wonder why your over budget and costs are going through the roof. The only programmers i know who love this crap are amateurs and people getting paid by the line or hour in code.
_"but you don't create code to test the code that is testing the other code"_
In this video, Bob did that by first making the test fail, and then making it pass.
It's true that that only tests the test in that moment. It's not a test regression test. (Whoo, complicated names here! xD) But it's better than writing tests after the fact, that have only ever succeeded.
TDD or no TDD, tests testing tests is not something that comes naturally either way. In both cases you have to put in the same effort to accomplish that, or you accept not testing tests. This does not affect your choice whether to use TDD or not.
_"I've seen people screw up the test code."_
I wonder if these people have applied TDD in the optimal way. Not that there's ever a guarantee for correct test code. That's not the case ever.
This does not affect your choice whether to use TDD or not.
_"It instead encourages people to look at only small issues rather than look at the larger picture in solving something."_
I think that is what you want! At the moment, you're writing a unit. Focus on the unit. Make sure that that does what you want it to do. Once finished, you take a step back, and look at the picture one step above the unit: the module.
You can apply TDD to the module also. Once the module does what you want it to do, take a step back, and look at the picture above that: the program.
And, you guessed it, you can apply TDD to the program also!
Losing sight of the bigger picture is not a TDD problem. Because you can apply TDD on all levels. (Or BDD if that is your jam.)
_" rather than end up with some efficient code you end up with many if else nest piles of crap for code that people wrote because they make these incremental changes to comply with the TDD testing changes"_
Now this is an actual concern. One that I don't know the answer to.
I would say that this should be thought about during the refactor steps after each increment of the TDD process. Make the test fail, write code to make it pass, refactor. When people refactor, they should engage with the larger picture at least a little bit.
I can imagine that this takes experience to pull off well.
You also voice concerns over time and costs. And I understand why. Programming with TDD takes time. Especially if programmers aren't already quite experienced with TDD.
The hope is, and the promise is, that TDD helps you win that time back by preventing bugs and making them easier to solve. It's hard to sell, because you don't normally see this trade-off. You don't see the time you don't spend. You only see that TDD takes more time during development.
I won't say that TDD will make true on its promise. That is up to the developer.
Hopefully other people will share their thoughts, because I find this an interesting topic.
It's fascinating to see the different pros and cons of TDD, or any methodology.
Tell me you don't know anything about unit testing and TDD, without telling me you know nothing about unit testing and TDD
“ The only programmers i know who love this crap are amateurs”
Every accusation is a confession
You wouldn't last long in my team because we use TDD every day and most of our code is written that way. Why we do it? Because it makes our life easier.
Yes, writing a new feature takes more time, that's a fact. But after time, this investment pays off. Good tests that test behaviour (not implementation) give quick feedback that the new code we wrote did not break previously implemented features. It also allows you to change the internal structure of the tested module (unit) in a safe way (refactoring), so the code does not get worse over time.
I think the most important part is learning how to write good tests. Here Uncle Bob shows us a simple example. A real live example where you have a module, not a class, with some dependencies, maybe infrastructure like the database or network, etc. would be better, but that's hard to do in an hour in front of 100 people.