Are you sure? dannorth.net/introducing-bdd/ (from the inventor of BDD) wiki.c2.com/?DeveloperTest (from the inventor of TDD) TDD is not about Unit Tests, that is wrong; BDD is not about helping the developer, that is wrong too. BDD is TDD, except that BDD focus on the interaction between actors and TDD focus on help to the developer. Because of it, BDD requires a kind of "test" that describes the result at a high level (so everyone can discuss and agree on), whereas TDD, which uses the same final test, requires steptests in the middle to advance steadily to the final result.
Unit tests often help to reveal "small and stupid" mistakes in the code. When my unit test fails, I can quickly find the cause of this failure (at least, I know what part of my code contains a mistake). When my behavioral test fails, I sometimes need a little of debugging to find the cause. Also behavioral tests tend to cover "happy paths" only. But they're the most useful when we need to refactor an old system with tons of legacy code, so... I think, TDD and BDD are like left and right hand for right-hander: you use your right hand more often and its fine motor skills are better, but it's kinda difficult to live without a left hand, too :)
That's a very interesting point about "happy paths": there's no reason that behavioural tests can't cover "unhappy paths"... but there is a tendency to miss them out. Like your left hand/right hand analogy. I may have to borrow that one ;)
"When my unit test fails, I can quickly find the cause of this failure [...]. When my behavioural test fails, I sometimes need a little of debugging to find the cause." >>> This exact point gets addressed in another video. Check it out: ua-cam.com/video/jrus212djPs/v-deo.html
I'm not sure why you think behaviour driven development only cover happy paths ... they check the correct as well as incorrect inputs to all access points of a module don't they
Thank you, indeed it is a nice video representation, keep it up. As far as i understand, behavior driven testing is more focused on the business use cases, whether the application is met the business purpose or not, if not met we have iteratively test each and every scenario and meet the business purpose in the application which is under development/or under test. Where as, the unit testing is the one which is more focussed on testing the code at the unit by unit or segment by segment and to make sure all the functional test cases of the application are passed and is more focussed on quality and reliability of the application. In unit testing the tester has the flexibility to write the negative test cases, perform regression and so on, where as in case of behavior driven testing, the tester is merely focussed on the business level use cases and check whether the purpose of the application is met or not. This is as per my understanding on Test driven testing and Behaviour driven testing.
@1:53 failed 1st test on the 1st drilled hole: reflect about what tested your test? Early testing helps for early correction, and in some cases you can choose between possibilities variants of correction methods and this should be taken into consideration when and how to test, to be able to make the best correction as possible. Here I think the test result (1st positioned drilled hole) can be the result of a chain of all steps before (including measuring and marking the center of the hole to be drilled), but in this video point it looks like exactly 1 step in the process of drilling and screwing. The mentioned waterfall approach have tests at the end, which is to late for intermediate correction steps as shown in the next minute.
BDD is a good choice for Agile teams. Agile requires less documentation and more working software, but this doesn't mean you cant have documentation at all. This is when BDD comes in handy, your Gherkin scenarios become the "detailed" documentation and even better if they are automated, they become live documentation. From a Vertical End to End perspective, TDD and BDD might look a little redundant in some points, but I think they are complementary. One works at the code level and the other one at the actual feature level. BDD helps us to achive things from the bussiness perspective, which is something TDD sometimes cant since is (usually) more oriented to the code. Edit: I really liked this video! its a great way to explain BDD and TDD!
Both can be combined but we have to remember something. What is the target of what we are doing? - Put a shelf on the wall? - Store my books? - Or put a nail exactly at the right place? And if I decide to use a screw for the last one? Will that cover my needs? TDD helps the developper to develop. BDD helps the team to satisfy the requirements. With TDD, what happend if the shelf by itself is not perfectly aligned with its own spécifications, and does not match the requirements? TDD is forcing you to add integration tests. If not, at the end, it can not cover the complete target, and you will have to fix the complete system. Using BDD, you will first think about your needs. Maybe two nails will be enough. Then if you have to reach better performances, as the storage of a bigger object, you will be able to add the two extra nails that you need.
Funny story, I once hung a shelf which passed all of the test driven development tests, but it turned out that the ceiling wasn't quite level. It was unnoticeable until you placed a level shelf not far beneath it. It stood out like a sore thumb so I altered the tests to ensure it was reasonably level but also visually aligned with the ceiling. This solved the problem.
I sometimes start with a behavioural test with gherkin syntax, which is the user story. I then build up the code using unit tests to verify it's going in the right direction. Finally when all the code is there, and the unit tests pass, the behavioural test usually passes as well. Bit more refactoring at this point, needing sometimes changes in the unit tests but they still guide the code. But it's a method I really enjoy.
I would go with TDD in an actual world, but BDD in this case of hanging a shelf is more practical and faster with a quick mallet touch and alignment check. I would think in most organizations is the lack of awareness of TDD which drives development/QA organizations to move to BDD. There is again the talk about white box and black box testing which also plays an important role as to whether development teams resolve to TDD or BDD. In deployment pipelines we also have Sonarqube which helps with coverage analysis but component/integration tests are usually black box tests written by QA organizations. TDD or BDD is a very debatable topic and past experience has told me that really depends on what the development/QA (engineering organization) are comfortable with to get latest code to customers asap.
For real life physical projects like hanging a shelf I would say behaviour driven all the way. With software unit tests happen really quickly however IRL if you have to install 500 shelves in a hotel you'll a real problem.
Very perfect example and explanation. How I take it as - I can keep continuing with TDD approach till my testable features are not ready (eg. Services, API) and once services are ready and integrated I can go for BDD approach. Would that make sense? Please advise.
I think I prefer TDD. It forces you to think differently and since we have automatic build tools these days, we don't need to worry about testing manually each time we write a bit of code. SSDs have also significantly improved the time it takes to commit your code to a local test server and have it test things for you while you plan your next step. You should not go for no longer than 5 minutes (maybe even 5 minutes is too much) into your code without a test. BDD is like a hack job, it gets the job done, but the results aren't always consistent. Another way to think of it, is how would you play chess? The best of players can take hours for a single game. Point being, thinking ahead means you face less troubles later on. The more experience you have, the easier TDD is to pull off.
That's a great comment. Was interest to see that you consider TDD to be more about "planning ahead" than BDD: think the BDD aficionados would take issue with that. Is there a danger, do you think, that TDD could lead you to elegant design... that provides no value?
Elegant design always has value regardless of long-term or short-term goals. If elegant design had no value, we wouldn't have new frameworks or languages, or improvements to those tools. If elegant design wasn't important, then adding or removing new features will eventually become major problems sooner or later. You become better at designing with experience, and it will waste less of your time as you gain more knowledge. After learning a bit more about BDD, I see a place for it in front-end development and less important aspects of an application. I'm primarily focused on back-end, and making sure each component that is testable and tested, is important for stability in the long term; so there may be some bias in my opinions. The only time I don't do TDD, are when I'm doing hobby projects that involve a GUI because it changes more regularly than the core logic and I'm terrible with front-end tools, so I do less automated tests and more manual tests in those areas (e.g. testing display of graphs and custom designed controls) - essentially BDD in theory, but not in code (correct me if I'm wrong, I'm no BDD expert).
I'm also a backend developer. And there's one specific area where I would apply BDD without hesitation: any system with an api. With tools like apiary, it's possible to start with an api definition (Api Blueprint, Swagger) and code against the definition. The tests simultaneously test the code *and* the documentation.Very cool. Of course, I'd be doing TDD at the same time ;)
Hi Gary, thanks for these informative videos 👍🏻 In this example both TDD and BDD has some +ve and -ve. TDD has effort put upfront in through analysis and test case preparation while BDD had effort spread out throughtout the implementation. I would prefer to go with BDD as it allows flexibility in terms of adjusting to enhancements or requirement changes and less effort wastage of upfront test case creation effort. Would like to hear your thought ☺️
In this particular example, BDD emerges as a clear winner: did you notice that there's only ONE behavioural test (applied multiple times)? Contrast that with the numerous unit tests / a much lower level of reuse. In the general case, the absence of unit tests would make me worry about underlying quality; in this particular example, I don't have that concern... but that's probably because the behavioural test is also a unit test!
Technically the behavior test for the shelf is not the the spirit level but what you intend to place on it - the car. If it's slightly out a vase might not slide off but a ball bearing could possibly roll off. Is your shelf for vases, ball bearings or spirit levels? In Engineering specification is everything. A brick layer does not require the same accuracy as a NASA Engineer who is checking the seal of an oxygen tank
There are a number of reasons to not use "the real thing" in testing: it's much more common - universal? - to use a proxy. But I do agree that the correct proxy in this case is not "just" a spirit level. But it could be a spirit level that has been calibrated to allow a range of angles (e.g., 2 degrees) from the horizontal.
I think for me its simple , when your end goal is clear or say you are moving from legacy application to a new modern architecture then go for tdd . But when your end goal is blurry or say your team is developing a new application altogether , then go for bdd . Get the version 1 right and then come back and fine tune it. Agree ?
Lovely explanation! Originally BDD was designed to be a better way to teach TDD, I still hold to that a bit, because there is value to a behavioural approach to even the fine-grained TDD in my opinion. It helps limit the coupling between test and SUT. I also recognise that the conversation, and interpretation, has moved on. I do like your style of describing things very simply with real-world, non-software, examples. Thanks!
You surely need both. The problem is: does your technical stack provide you the tools? In the video, this seams implicit. Working with CakePHP 4, we had to start building the tools. Here is more on that: ua-cam.com/video/PNA1Ck2-nVc/v-deo.html
Behavior is superior because the in between stages are [irrelevant] to the shelf user. The analogy is slightly unfair because you can write code twice but you MIGHT not have a pair of IDENTICAL wall brackets. While we are at it, I would say that the wall CANT be damaged by the process and the shelf SHOULD be able to hold a few Kg ABOVE it's own weight. Staying with your theme of interior-decoration, I recently saw a brand-new kitchen sink with a huge crack on the outside which strongly suggests the installers fitted it WRONG - The result FAILED to function as a water-proof container although that was OBVIOUSLY its purpose.
I think we need both tests to run product development accurately. But i guess BDD will have a bigger shot of the pie since its all about customer needs and changing markets
"Flat" and "Level" are not interchangeable. I can have a flat surface that is at a 45 degree angle to the floor. Consistency and adherence to the Universal Language of the domain (carpentry or construction) is required here!
I think the main take away that we know the end goal and the requirements exactly. Unfortunately in real software projects, the end goal is blurry. Management and clients often ask for a lot of modifications in first version or while developing, you find out the design architecture that you initially thought would not be the best fit and you spent a lot if time writing tests which are no longer needed anymore. I woukd much rather prefer the dirty way to quickly go develop the first version and once management is happy then go fine tune it and then write tests.
Using production software to demonstrate functionality to customers is very expensive. Try spending more time during ideation and conceptualization on mockups, usability studies, prototypes to define the outcomes and address unknowns. Engineers should be involved from ideation to value delivered, and definitely avoid writing untested code.
He never tested the surface of the shelf or the wheels of the car. The wheels could of been super (or not so super) glued together by some awkward sh!&^&...
Nice and professional presentation. Love the example. But this doesn't really clarify the difference between *unit* testing versus *behavior* testing. It comes close with the use of the level, but the unit testing examples used the level as well, so this doesn't clarify the differences.
Agree that the distinction could be clearer. Think you found my other videos on TDD vs BDD which arguably do a better job: ua-cam.com/video/fsSMuqIpu_c/v-deo.html
I would say from this example that test driven development is suitable for people who don't have any experience in doing the task. Behavior driven testing is more suitable to someone who is experienced enough to know that the shelf may move a little when putting the screws in but knows how to quickly remedy any issue. The conclusion seems to be: if you don't trust your developers make them do test driven development, if you do trust them encourage them use their experience and test in a behavioral fashion.
By understanding the desired behavior [the shelf should be level], he was able to skip over the useless details of where the screws were supposed to be. Test what matters first.
The mistake you mad with this is that you can't easily correct the first hole in the wall that easily. Once the hole is drilled you would have to adjust the remaining 3 holes and make sure they are right.
I guess I don't understand why you couldn't combine TDD and BDD. Is the issue just that it creates more work than is necessary to properly test a thing? For example, couldn't you have your unit test for screw holes and your behavior test with the level. Hypothetically this might catch where the screw holes on the shelf itself are not level with each other.
Also am I the only one who noticed how trying to apply some of our made up terminology to real world concepts of building things physically instead of using code made TDD and BDD just sound like silly corporate fluff speak that way overanalyzes concepts of doing things instead of the actual doing of things?.. Like we spend a lot of time in the programming/dev world talking about and breaking down how we like to asses things instead of talking about what the best way to just build things. It's almost like a group of carpenters debating which way is the best way to cut wood. Yeah it could be important, might not matter at all though. But they don't hold conventions to debate this stuff.... That is what I took away from this.
Real world examples always make me a little weary these days. It makes it sound like developers have the solutions to everything. Everything can be agile. And maybe it can. Can war be agile? Should Russia have taken a more agile approach in this recent conflict?
behaviour driven testing = testing with functional usecases early on? This presentation did not clearly delineate anything because only a moron would've put up the shelf by screwing in more than 1 screw before testing for level.
I have watched so many video about TDD and BDD, but this 5:24 minute video helps me to understand the concept easily! Thank you and God bless!
Thank you very much!
How to decide whether BDD Or TDD for a particular project?
me to
Are you sure?
dannorth.net/introducing-bdd/ (from the inventor of BDD)
wiki.c2.com/?DeveloperTest (from the inventor of TDD)
TDD is not about Unit Tests, that is wrong; BDD is not about helping the developer, that is wrong too.
BDD is TDD, except that BDD focus on the interaction between actors and TDD focus on help to the developer.
Because of it, BDD requires a kind of "test" that describes the result at a high level (so everyone can discuss and agree on),
whereas TDD, which uses the same final test, requires steptests in the middle to advance steadily to the final result.
@@sumanam5318 It is not relevant, either are almost the same. The video is explaining it wrong. See the comment above.
Unit tests often help to reveal "small and stupid" mistakes in the code. When my unit test fails, I can quickly find the cause of this failure (at least, I know what part of my code contains a mistake). When my behavioral test fails, I sometimes need a little of debugging to find the cause.
Also behavioral tests tend to cover "happy paths" only.
But they're the most useful when we need to refactor an old system with tons of legacy code, so... I think, TDD and BDD are like left and right hand for right-hander: you use your right hand more often and its fine motor skills are better, but it's kinda difficult to live without a left hand, too :)
That's a very interesting point about "happy paths": there's no reason that behavioural tests can't cover "unhappy paths"... but there is a tendency to miss them out.
Like your left hand/right hand analogy. I may have to borrow that one ;)
"When my unit test fails, I can quickly find the cause of this failure [...]. When my behavioural test fails, I sometimes need a little of debugging to find the cause." >>> This exact point gets addressed in another video. Check it out: ua-cam.com/video/jrus212djPs/v-deo.html
Sorry I am lefty so......
Sir your explanation was more precise I see.
I'm not sure why you think behaviour driven development only cover happy paths ... they check the correct as well as incorrect inputs to all access points of a module don't they
Thank you, indeed it is a nice video representation, keep it up.
As far as i understand, behavior driven testing is more focused on the business use cases, whether the application is met the business purpose or not, if not met we have iteratively test each and every scenario and meet the business purpose in the application which is under development/or under test.
Where as, the unit testing is the one which is more focussed on testing the code at the unit by unit or segment by segment and to make sure all the functional test cases of the application are passed and is more focussed on quality and reliability of the application.
In unit testing the tester has the flexibility to write the negative test cases, perform regression and so on, where as in case of behavior driven testing, the tester is merely focussed on the business level use cases and check whether the purpose of the application is met or not.
This is as per my understanding on Test driven testing and Behaviour driven testing.
Yep - I'd a agree with that. Good summary!
OMG . Until watching this video I have been confused about TDD vs BDD now in 5 minute I understand very quickly. Thanks so much
You are most welcome!
@1:53 failed 1st test on the 1st drilled hole: reflect about what tested your test? Early testing helps for early correction, and in some cases you can choose between possibilities variants of correction methods and this should be taken into consideration when and how to test, to be able to make the best correction as possible.
Here I think the test result (1st positioned drilled hole) can be the result of a chain of all steps before (including measuring and marking the center of the hole to be drilled), but in this video point it looks like exactly 1 step in the process of drilling and screwing.
The mentioned waterfall approach have tests at the end, which is to late for intermediate correction steps as shown in the next minute.
BDD is a good choice for Agile teams. Agile requires less documentation and more working software, but this doesn't mean you cant have documentation at all. This is when BDD comes in handy, your Gherkin scenarios become the "detailed" documentation and even better if they are automated, they become live documentation.
From a Vertical End to End perspective, TDD and BDD might look a little redundant in some points, but I think they are complementary. One works at the code level and the other one at the actual feature level.
BDD helps us to achive things from the bussiness perspective, which is something TDD sometimes cant since is (usually) more oriented to the code.
Edit: I really liked this video! its a great way to explain BDD and TDD!
Both can be combined but we have to remember something.
What is the target of what we are doing?
- Put a shelf on the wall?
- Store my books?
- Or put a nail exactly at the right place?
And if I decide to use a screw for the last one? Will that cover my needs?
TDD helps the developper to develop. BDD helps the team to satisfy the requirements.
With TDD, what happend if the shelf by itself is not perfectly aligned with its own spécifications, and does not match the requirements?
TDD is forcing you to add integration tests. If not, at the end, it can not cover the complete target, and you will have to fix the complete system.
Using BDD, you will first think about your needs.
Maybe two nails will be enough.
Then if you have to reach better performances, as the storage of a bigger object, you will be able to add the two extra nails that you need.
Funny story, I once hung a shelf which passed all of the test driven development tests, but it turned out that the ceiling wasn't quite level. It was unnoticeable until you placed a level shelf not far beneath it. It stood out like a sore thumb so I altered the tests to ensure it was reasonably level but also visually aligned with the ceiling. This solved the problem.
I sometimes start with a behavioural test with gherkin syntax, which is the user story. I then build up the code using unit tests to verify it's going in the right direction. Finally when all the code is there, and the unit tests pass, the behavioural test usually passes as well. Bit more refactoring at this point, needing sometimes changes in the unit tests but they still guide the code. But it's a method I really enjoy.
Nice example for BDD & TDD and non-IT field. Thanks
I would go with TDD in an actual world, but BDD in this case of hanging a shelf is more practical and faster with a quick mallet touch and alignment check. I would think in most organizations is the lack of awareness of TDD which drives development/QA organizations to move to BDD. There is again the talk about white box and black box testing which also plays an important role as to whether development teams resolve to TDD or BDD. In deployment pipelines we also have Sonarqube which helps with coverage analysis but component/integration tests are usually black box tests written by QA organizations. TDD or BDD is a very debatable topic and past experience has told me that really depends on what the development/QA (engineering organization) are comfortable with to get latest code to customers asap.
For real life physical projects like hanging a shelf I would say behaviour driven all the way. With software unit tests happen really quickly however IRL if you have to install 500 shelves in a hotel you'll a real problem.
Very perfect example and explanation. How I take it as - I can keep continuing with TDD approach till my testable features are not ready (eg. Services, API) and once services are ready and integrated I can go for BDD approach. Would that make sense? Please advise.
I think I prefer TDD. It forces you to think differently and since we have automatic build tools these days, we don't need to worry about testing manually each time we write a bit of code. SSDs have also significantly improved the time it takes to commit your code to a local test server and have it test things for you while you plan your next step. You should not go for no longer than 5 minutes (maybe even 5 minutes is too much) into your code without a test. BDD is like a hack job, it gets the job done, but the results aren't always consistent. Another way to think of it, is how would you play chess? The best of players can take hours for a single game. Point being, thinking ahead means you face less troubles later on. The more experience you have, the easier TDD is to pull off.
That's a great comment. Was interest to see that you consider TDD to be more about "planning ahead" than BDD: think the BDD aficionados would take issue with that. Is there a danger, do you think, that TDD could lead you to elegant design... that provides no value?
Elegant design always has value regardless of long-term or short-term goals. If elegant design had no value, we wouldn't have new frameworks or languages, or improvements to those tools. If elegant design wasn't important, then adding or removing new features will eventually become major problems sooner or later. You become better at designing with experience, and it will waste less of your time as you gain more knowledge.
After learning a bit more about BDD, I see a place for it in front-end development and less important aspects of an application. I'm primarily focused on back-end, and making sure each component that is testable and tested, is important for stability in the long term; so there may be some bias in my opinions.
The only time I don't do TDD, are when I'm doing hobby projects that involve a GUI because it changes more regularly than the core logic and I'm terrible with front-end tools, so I do less automated tests and more manual tests in those areas (e.g. testing display of graphs and custom designed controls) - essentially BDD in theory, but not in code (correct me if I'm wrong, I'm no BDD expert).
I'm also a backend developer. And there's one specific area where I would apply BDD without hesitation: any system with an api. With tools like apiary, it's possible to start with an api definition (Api Blueprint, Swagger) and code against the definition.
The tests simultaneously test the code *and* the documentation.Very cool.
Of course, I'd be doing TDD at the same time ;)
Hi Gary, thanks for these informative videos 👍🏻
In this example both TDD and BDD has some +ve and -ve.
TDD has effort put upfront in through analysis and test case preparation while BDD had effort spread out throughtout the implementation.
I would prefer to go with BDD as it allows flexibility in terms of adjusting to enhancements or requirement changes and less effort wastage of upfront test case creation effort.
Would like to hear your thought ☺️
In this particular example, BDD emerges as a clear winner: did you notice that there's only ONE behavioural test (applied multiple times)? Contrast that with the numerous unit tests / a much lower level of reuse.
In the general case, the absence of unit tests would make me worry about underlying quality; in this particular example, I don't have that concern... but that's probably because the behavioural test is also a unit test!
I understood that if a behavioural test doesn't work you just need to use a mallet as big as your test and you're good to go!
😂 like it!
Technically the behavior test for the shelf is not the the spirit level but what you intend to place on it - the car. If it's slightly out a vase might not slide off but a ball bearing could possibly roll off. Is your shelf for vases, ball bearings or spirit levels?
In Engineering specification is everything. A brick layer does not require the same accuracy as a NASA Engineer who is checking the seal of an oxygen tank
There are a number of reasons to not use "the real thing" in testing: it's much more common - universal? - to use a proxy. But I do agree that the correct proxy in this case is not "just" a spirit level. But it could be a spirit level that has been calibrated to allow a range of angles (e.g., 2 degrees) from the horizontal.
Explain TLD ( test last Development)
Ooh. I feel a new video coming on...
Wonderfully explained. This example will always remain in the back of my mind. Thanks.
I think for me its simple , when your end goal is clear or say you are moving from legacy application to a new modern architecture then go for tdd . But when your end goal is blurry or say your team is developing a new application altogether , then go for bdd . Get the version 1 right and then come back and fine tune it. Agree ?
he is good short, simple straight to the point 👌
please do more on scrum like velocity, capability, metrics, burn down/up chart
I'll add them to the list!
Lovely explanation!
Originally BDD was designed to be a better way to teach TDD, I still hold to that a bit, because there is value to a behavioural approach to even the fine-grained TDD in my opinion. It helps limit the coupling between test and SUT. I also recognise that the conversation, and interpretation, has moved on.
I do like your style of describing things very simply with real-world, non-software, examples.
Thanks!
You surely need both. The problem is: does your technical stack provide you the tools? In the video, this seams implicit. Working with CakePHP 4, we had to start building the tools. Here is more on that:
ua-cam.com/video/PNA1Ck2-nVc/v-deo.html
So clearly explained. Great video
Really glad you liked it!
wow some people are just good at explaining. this is awesome
Thank you! That's very kind of you.
thanks!!! i am from argentina, this video is very easy to understand the topic!!!
Behavior is superior because the in between stages are [irrelevant] to the shelf user. The analogy is slightly unfair because you can write code twice but you MIGHT not have a pair of IDENTICAL wall brackets.
While we are at it, I would say that the wall CANT be damaged by the process and the shelf SHOULD be able to hold a few Kg ABOVE it's own weight.
Staying with your theme of interior-decoration, I recently saw a brand-new kitchen sink with a huge crack on the outside which strongly suggests the installers fitted it WRONG - The result FAILED to function as a water-proof container although that was OBVIOUSLY its purpose.
Agree that the analogy isn't perfect... and strongly agree with your first sentence. 👍
Very nicely done!
Thank you!
i like behavior driven way since it can be automated with feedbacks
I think we need both tests to run product development accurately. But i guess BDD will have a bigger shot of the pie since its all about customer needs and changing markets
+bankole dada - I'm with you. I think both have a place.
"Flat" and "Level" are not interchangeable. I can have a flat surface that is at a 45 degree angle to the floor. Consistency and adherence to the Universal Language of the domain (carpentry or construction) is required here!
Excellent point well made. 👍
Truth is Unit testing can be stressful, but it's worth it TDD all the way
Tdd is more prudent and requires less back-tracking and fewer holes in your wall.
I tried to understand TDD as being able to write in code or get confused as philosophical discussion.
I think the main take away that we know the end goal and the requirements exactly. Unfortunately in real software projects, the end goal is blurry. Management and clients often ask for a lot of modifications in first version or while developing, you find out the design architecture that you initially thought would not be the best fit and you spent a lot if time writing tests which are no longer needed anymore. I woukd much rather prefer the dirty way to quickly go develop the first version and once management is happy then go fine tune it and then write tests.
Agree with you 100%.
Using production software to demonstrate functionality to customers is very expensive. Try spending more time during ideation and conceptualization on mockups, usability studies, prototypes to define the outcomes and address unknowns. Engineers should be involved from ideation to value delivered, and definitely avoid writing untested code.
I would argue that the shelf is always flat ;) Thank's for these! I wish I seen your video's when I first started software testing
He never tested the surface of the shelf or the wheels of the car. The wheels could of been super (or not so super) glued together by some awkward sh!&^&...
What a Lucid explanation ❤️
Thank you! Nice of you to say so 👍
Very good learning video
Thank you!
Nice and professional presentation. Love the example. But this doesn't really clarify the difference between *unit* testing versus *behavior* testing. It comes close with the use of the level, but the unit testing examples used the level as well, so this doesn't clarify the differences.
Agree that the distinction could be clearer. Think you found my other videos on TDD vs BDD which arguably do a better job: ua-cam.com/video/fsSMuqIpu_c/v-deo.html
Wonderful explanation
for me bdd was more intutive.
Yes, it's super-easy to grasp. I guess that's why it got adopted quickly.
I would say from this example that test driven development is suitable for people who don't have any experience in doing the task. Behavior driven testing is more suitable to someone who is experienced enough to know that the shelf may move a little when putting the screws in but knows how to quickly remedy any issue. The conclusion seems to be: if you don't trust your developers make them do test driven development, if you do trust them encourage them use their experience and test in a behavioral fashion.
BDD is for business logic. TDD is for the code it self…
Yep, I'd agree with that.
By understanding the desired behavior [the shelf should be level], he was able to skip over the useless details of where the screws were supposed to be. Test what matters first.
Wonderful analogy ...brilliant.
Delighted that you liked it!
The mistake you mad with this is that you can't easily correct the first hole in the wall that easily. Once the hole is drilled you would have to adjust the remaining 3 holes and make sure they are right.
I believe test driven is a much better approach is a much better way.
Great Explanation. Thanks!
+Dev Raj - Many thanks!
I guess I don't understand why you couldn't combine TDD and BDD. Is the issue just that it creates more work than is necessary to properly test a thing?
For example, couldn't you have your unit test for screw holes and your behavior test with the level. Hypothetically this might catch where the screw holes on the shelf itself are not level with each other.
The video was designed to emphasise the differences. But you're right: there's no reason not to use both.
very well explained 👍
Thank you!
I think TDD is better on this situation. Have a great day.
👍
The best explanation you can get 🔥🔥
Thank you!
TDD for this one thanks for sharing
Wow, now I finally get it.
Today’s tdd is just a misunderstood bdd. Tdd is good for exercise, but through the tests away asap
Can you say more about that?
Development That Pays look at Ian cooper, Tdd, where did it all go wrong, it is an eye opener.
very nice video :). very nice example
Thank you!
I print 10+ times doing Leetcode problems and my friends laugh at me.
Did my guy just redrill a hole over another hole?
Also am I the only one who noticed how trying to apply some of our made up terminology to real world concepts of building things physically instead of using code made TDD and BDD just sound like silly corporate fluff speak that way overanalyzes concepts of doing things instead of the actual doing of things?.. Like we spend a lot of time in the programming/dev world talking about and breaking down how we like to asses things instead of talking about what the best way to just build things. It's almost like a group of carpenters debating which way is the best way to cut wood. Yeah it could be important, might not matter at all though. But they don't hold conventions to debate this stuff.... That is what I took away from this.
Seems the same to me. Seems like a distinction without a difference.
sooo coollll!!
Your BDD explanation look TDD for me.
TDD
I like bdd
Real world examples always make me a little weary these days. It makes it sound like developers have the solutions to everything. Everything can be agile. And maybe it can. Can war be agile? Should Russia have taken a more agile approach in this recent conflict?
you cant move holes, even by use of a mallet. This analogy is terrible.
Did you REALLY screw up hanging a shelf that was level? You gotta be paying no attention to pull that off man lol
What can I say: It's my superpower.
Baby, thz
behaviour driven testing = testing with functional usecases early on? This presentation did not clearly delineate anything because only a moron would've put up the shelf by screwing in more than 1 screw before testing for level.
I've had another go at "TDD vs BDD" that you may prefer. Check it out: ua-cam.com/video/fsSMuqIpu_c/v-deo.html