Fake It -> Evolve code incrementally, don't necessarily evolve tests as a way to drive that evolution Triangulation -> Evolve test case and in response evolve the code to match Obvious -> Well, it's obvious, isn't it? haha; But seriously, I feel like in this case you're writing the test just as a means to avoid regression. Excellent video, thank you for the explanations.
Not only to avoid regression but also to document behaviour. However, Obvious Implementation can also be used in something a bit more complex. I feel confident I can go for it, and once it goes wrong I adopt other Driving Pattern
Hmm these approaches remind me of curve fitting, like you do in excel. Basically finding the underlying model of the curve based on the observation data you have. The danger of course is that you have to be sure your data are representative enough to cover all edge cases otherwise you might overfit the curve, satisfying the observations you have but missing on others you don't have.
For beginners of TDD: Simply make sure that you create a unit test for every unit of code that tests it behavior properly. As I wrote in my earlier comments, how TDD has been portrayed in the past is not how you really write code - Like Gui said, it is just one technique that might suit a certain scenario. If you are confident in how to write the code, just go on implementing it without the "Green, Red, Refactor". The point is that you think about testing while you design or write your code. You may already have the requirements, but you want to test the implementation so that it stays consistent, at any level, in any unit. For your own sake, mainly. 🙂
Absolutely, I would only rephrase and say "make sure that you create a unit test for every unit of behavior". Otherwise, people may misunderstand the Unit of Code with Methods/Functions.
@@gui.ferreira Agree. I was thinking about what word to use while writing. "Behavior" is what I would say. Defaulted to "Unit of Code" when talking about programming in general. Yup. Programmers unfortunately are technical people and start out learning about technical concerns - that classes and methods are what matters while the experience developer knows that they don't. It is what they represent, the abstractions, and behaviors. Our mental model of the problem encoded in classes and methods that matter.
Would you please mention the three techniques first. Then you can implement in code. I think it will be the better approach. Anyway thanks for sharing.
The problem with TDD (as it is viewed by many) is that testing always preceeds or eliminates design entirely. All the focus is seemingly on creating stubs adhoc.
@@gui.ferreira to clarify, I meant that it is often portrayed like the only deist that you do is creating stub classes at the spot. They miss the steps about thinking it through and doing the actual design. As so often happens in videos where devs supposedly show how to apply TDD. The way they show TDD might scare some devs away. The mindset is so much more important, and that is sadly missing.
@@gui.ferreiraYes, I guess. I am all for TDD when it means actively using Unit Tests as a test bed for classes and their behavior. TDD to me says nothing about how the Software Design process is. Most videos that are demonstrating the procedure of TDD don’t focus on that and it might lead beginners astray thinking design is done ad-hoc in every test case with stubs. There are usually thoughts behind how you structure code before writing the actual code and test cases.
I get the point you are trying to make but I think the example you have chosen is just too simple to clearly illustrate that point. To motivate developers to try out these techniques instead of jumping right into what they think might be the correct implementation, a more complex example would have been better - maybe some where you try to "triangulate" the solution with a bunch of if-then-else statements and then develop that towards some "calculation"/"algorithm".
Agreed. As the example doesn't have enough complexity, these techniques don't feel like something an expert would do because the logic itself is trivial. On the contrary, it might dissuade developers from using TDD if they feel they have to go over several steps just for such a basic operation. I like how Uncle Bob describes the TDD cycle: "As the tests get more specific, the code gets more generic."
Thanks for the feedback. I will consider that next time. Sometimes is hard to balance the effectiveness of the scenario with the needed complexity. I tried to avoid unneeded complexity in the explanation, but I can see your point. Thanks once again. It is valuable feedback.
Thanks for the feedback, Juan. It's hard to find the balance between required complexity, simple terms, and effectiveness. I will for sure keep this in mind next time.
![“อาร์ต พศุตม์” เกือบเอี่ยวทุกคดีดัง เอ๊ะไว้ก่อน ไม่มีอะไรได้มาง่ายๆ | แฉ 16 ต.ค. 67 [2/3] | GMM25](http://i.ytimg.com/vi/0Gx-0-kUBv8/mqdefault.jpg)
Fake It -> Evolve code incrementally, don't necessarily evolve tests as a way to drive that evolution
Triangulation -> Evolve test case and in response evolve the code to match
Obvious -> Well, it's obvious, isn't it? haha; But seriously, I feel like in this case you're writing the test just as a means to avoid regression.
Excellent video, thank you for the explanations.
Not only to avoid regression but also to document behaviour.
However, Obvious Implementation can also be used in something a bit more complex. I feel confident I can go for it, and once it goes wrong I adopt other Driving Pattern
Hmm these approaches remind me of curve fitting, like you do in excel. Basically finding the underlying model of the curve based on the observation data you have. The danger of course is that you have to be sure your data are representative enough to cover all edge cases otherwise you might overfit the curve, satisfying the observations you have but missing on others you don't have.
I was not aware of the concept of curve fitting. Thanks for adding that 🙏
For beginners of TDD: Simply make sure that you create a unit test for every unit of code that tests it behavior properly.
As I wrote in my earlier comments, how TDD has been portrayed in the past is not how you really write code - Like Gui said, it is just one technique that might suit a certain scenario. If you are confident in how to write the code, just go on implementing it without the "Green, Red, Refactor".
The point is that you think about testing while you design or write your code. You may already have the requirements, but you want to test the implementation so that it stays consistent, at any level, in any unit. For your own sake, mainly. 🙂
Absolutely, I would only rephrase and say "make sure that you create a unit test for every unit of behavior". Otherwise, people may misunderstand the Unit of Code with Methods/Functions.
@@gui.ferreira Agree. I was thinking about what word to use while writing. "Behavior" is what I would say. Defaulted to "Unit of Code" when talking about programming in general.
Yup. Programmers unfortunately are technical people and start out learning about technical concerns - that classes and methods are what matters while the experience developer knows that they don't. It is what they represent, the abstractions, and behaviors. Our mental model of the problem encoded in classes and methods that matter.
Would you please mention the three techniques first. Then you can implement in code. I think it will be the better approach. Anyway thanks for sharing.
The problem with TDD (as it is viewed by many) is that testing always preceeds or eliminates design entirely. All the focus is seemingly on creating stubs adhoc.
That is true. TDD is primarily a design practice, so that's a sign that is being done wrong.
@@gui.ferreira to clarify, I meant that it is often portrayed like the only deist that you do is creating stub classes at the spot.
They miss the steps about thinking it through and doing the actual design. As so often happens in videos where devs supposedly show how to apply TDD. The way they show TDD might scare some devs away.
The mindset is so much more important, and that is sadly missing.
@@marna_li do you mean that design and refactoring are not correctly demonstrated? Am I right?
@@gui.ferreiraYes, I guess. I am all for TDD when it means actively using Unit Tests as a test bed for classes and their behavior. TDD to me says nothing about how the Software Design process is. Most videos that are demonstrating the procedure of TDD don’t focus on that and it might lead beginners astray thinking design is done ad-hoc in every test case with stubs. There are usually thoughts behind how you structure code before writing the actual code and test cases.
I get the point you are trying to make but I think the example you have chosen is just too simple to clearly illustrate that point. To motivate developers to try out these techniques instead of jumping right into what they think might be the correct implementation, a more complex example would have been better - maybe some where you try to "triangulate" the solution with a bunch of if-then-else statements and then develop that towards some "calculation"/"algorithm".
Agreed.
As the example doesn't have enough complexity, these techniques don't feel like something an expert would do because the logic itself is trivial. On the contrary, it might dissuade developers from using TDD if they feel they have to go over several steps just for such a basic operation.
I like how Uncle Bob describes the TDD cycle: "As the tests get more specific, the code gets more generic."
Thanks for the feedback. I will consider that next time.
Sometimes is hard to balance the effectiveness of the scenario with the needed complexity. I tried to avoid unneeded complexity in the explanation, but I can see your point.
Thanks once again. It is valuable feedback.
Thanks for the feedback, Juan.
It's hard to find the balance between required complexity, simple terms, and effectiveness.
I will for sure keep this in mind next time.
I think the example it bad.
Thanks for the feedback, Vladislav.
It's hard to find the balance between simplicity and required complexity.
I will try to do a better job next time.