Test Driven vs Behaviour Driven Development

Подписаться 74 тыс.

Просмотров 163 тыс.

50% 1

Can the principles of Test Driven Development (TDD) and Behaviour Driven Development (BDD) be applied to a simple DIY challenge?
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmen...
= = = = = = = = = = = =
Grab your free TDD vs. BDD Cheatsheet: www.developmen...
Can the principles of Test Driven Development (TDD) and Behaviour Driven Development (BDD) be applied to a simple DIY challenge?
In a previous episode, I employed a Waterfall approach to hang a shelf - and I made a right mess of it. In this episode, I repeat the process, this time adopting a "test first" approach.
- 0:44 - Test Driven Development (TDD)
- 2:55 - Behaviour Driven Development (BDD)
Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186
-------------------
41. Test Driven vs Behaviour Driven Development
#DevelopmentThatPays
I tried to hang this shelf on this wall. I made a mess of it. The shelf was wonky. Could Test Driven Development - or even Behaviour Driven Development - have saved the day Shelving ---- A couple of episodes ago, I went through the process of hanging a shelf in what looked suspiciously like a Waterfall process: I did all of the measuring all of the transferring all of the drilling popped in all of the wall plugs and brute-forced the screws in. Alas, the end result was not good: the shelf was not level. But it got me thinking. Could tests have saved the day Is it possible to hang a shelf in a test-driven way Is it possible to hang a shelf in a behaviour-driven way I think we should find out. Test Driven Development (TDD) --- Here's me hanging a shelf in my waterfall-like style. Let's stop it... there. Here's an opportunity for a test: I could come back at any time and check that the line really is level. That could be the first unit test. More marking and measuring. Stop there. Lots of opportunities for unit tests here: one for each of these measurements. What happened next Oh yes... I drilled all the holes. I popped in all the wall plugs. Stop. This is certainly a point where the unit tests could - and should - be performed. But it's actually a few steps too late. I've done far too much work between tests. Lets rewind a bit. Drill one hole (only). And perform the "unit tests" to ensure the hole went in in the right place. If the test fails - if the hole has gone in the wrong place - now's the time to fix it: there's no point in continuing until all the tests pass. Once the tests are passing, we can move on. Drill another hole. Run the tests. Correct as necessary. And so on until we have all four holes drilled - and tested. In with the four plugs. No harm in repeating the "unit tests"... but it's most likely that all would pass. And we're now in a position to finish the job. In go the screws. Unfortunately, it's no longer trivial to run our unit tests. But there is another test we can run: we can check for level. And given that we've had "green lights" up to this point, the chances are that this test will pass too. And it does. The shelf is perfectly flat. Behaviour Driven Development (BDD) -- So much for Test Driven Development; what about Behaviour Driven Development A shelf is a bit passive. It doesn't have have much in the way of behaviours. But if we are generous with our definitions, we could say that a desirable behaviour is that anything that are put on it should not slide off. Or put it another way, the shelf should be level. It can be argued, then, that testing the shelf for level is not only a unit test; it's also a behavioural test. In the sequence we've been through, this "behavioural test" was the last thing that we did. AFTER all the work had been done. The very opposite of "behaviour driven". Is behaviour driven development even possible in this case Turns out that the method my dad used to hang a shelf looks a lot like a behaviour-driven process: First step is marking the centre of the shelf. We could have a test for that - to verify that the mark really is in the centre of the shelf. That would be a unit test. (It's the first and last time we'll come across a unit test in the sequence.) Moving on... Check for level. That's the behavioural test. There it is again. This time it fails. Again, no point in continuing until "all the tests are passing". A quick tap with a mallet. Run the tests again - this time passing. Which means we can move on. There's the behavioural test again. And again one final time. Success! -- Would you believe it: It is possible to hang a shelf in
• Test Driven vs Behavio...
• BDD vs TDD (explained)

Опубликовано:

1 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 123

@МаксимМарич-г5ы 8 лет назад

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 :)

@Developmentthatpays 8 лет назад

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 ;)

@Developmentthatpays 8 лет назад

"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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jrus212djPs.html

6 лет назад

Sorry I am lefty so......

@kirankamath5891 4 года назад

Sir your explanation was more precise I see.

@gamemusicmeltingpot2192 4 года назад

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

@cyrusbesabella5938 7 лет назад

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!

@Developmentthatpays 7 лет назад

Thank you very much!

@sumanam5318 4 года назад

How to decide whether BDD Or TDD for a particular project?

@premprakash7981 4 года назад

me to

@DavidRodenas 3 года назад

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.

@DavidRodenas 3 года назад

@@sumanam5318 It is not relevant, either are almost the same. The video is explaining it wrong. See the comment above.

@MAMajidApril84 6 лет назад

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.

@Developmentthatpays 6 лет назад

Yep - I'd a agree with that. Good summary!

@olasoderlind5685 Год назад

Explain TLD ( test last Development)

@Developmentthatpays 8 месяцев назад

Ooh. I feel a new video coming on...

@anjaneyaprasadjasti92 6 лет назад

for me bdd was more intutive.

@Developmentthatpays 6 лет назад

Yes, it's super-easy to grasp. I guess that's why it got adopted quickly.

@xerotolerant 7 лет назад

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.

@alejandrosoto9633 2 года назад

I think TDD is better on this situation. Have a great day.

@Developmentthatpays 2 года назад

👍

@julian_handpan Год назад

BDD is for business logic. TDD is for the code it self…

@Developmentthatpays Год назад

Yep, I'd agree with that.

@prgosavi 7 лет назад

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.

@prashantsalgaocar 4 месяца назад

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.

@mickaelarazor5260 7 месяцев назад

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.

@kotholan3435 6 лет назад

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.

@justinjuner2624 2 года назад

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.

@UjjwalPrakashSinha 8 лет назад

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 ☺️

@Developmentthatpays 8 лет назад

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!

@MobiusCoin 2 года назад

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?

@davefarley77 4 года назад

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!

@yutubl 3 месяца назад

@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.

@ariz9626 2 года назад

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 ?

@CarlosRamirez-jt7tm 3 года назад

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!

@Infinity2u 10 месяцев назад

I believe test driven is a much better approach is a much better way.

@04bhatta 3 года назад

I tried to understand TDD as being able to write in code or get confused as philosophical discussion.

@ornelfranck 2 года назад

Very nicely done!

@Developmentthatpays 2 года назад

Thank you!

@L8rCloud 6 лет назад

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

@Developmentthatpays 6 лет назад

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.

@bankoledada 7 лет назад

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

@Developmentthatpays 7 лет назад

+bankole dada - I'm with you. I think both have a place.

@BinhNguyen-nn5dk 4 месяца назад

Nice example for BDD & TDD and non-IT field. Thanks

@es-tekes-tek4049 6 лет назад

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!

@Developmentthatpays 6 лет назад

😂 like it!

@mahmoudelsonbati8673 4 года назад

i like behavior driven way since it can be automated with feedbacks

@tsfto 4 года назад

"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!

@Developmentthatpays 4 года назад

Excellent point well made. 👍

@pabloinberlin 3 года назад

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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PNA1Ck2-nVc.html

@codyleaf7186 4 года назад

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.

@lawrencerosen7113 3 года назад

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.

@Developmentthatpays 3 года назад

Agree that the analogy isn't perfect... and strongly agree with your first sentence. 👍

@justingiovanetti 3 года назад

Seems the same to me. Seems like a distinction without a difference.

@qonf 4 года назад

you cant move holes, even by use of a mallet. This analogy is terrible.

@dilbabajon7754 Год назад

OMG . Until watching this video I have been confused about TDD vs BDD now in 5 minute I understand very quickly. Thanks so much

@Developmentthatpays Год назад

You are most welcome!

@silentlessons4221 6 лет назад

wow some people are just good at explaining. this is awesome

@Developmentthatpays 6 лет назад

Thank you! That's very kind of you.

@98luk45 7 лет назад

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.

@Developmentthatpays 7 лет назад

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?

@98luk45 7 лет назад

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).

@Developmentthatpays 7 лет назад

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 ;)

@backester_singhaman6914 5 лет назад

he is good short, simple straight to the point 👌 please do more on scrum like velocity, capability, metrics, burn down/up chart

@Developmentthatpays 5 лет назад

I'll add them to the list!

@urosciric8030 4 года назад

Did my guy just redrill a hole over another hole?

@CookRacingUK 5 лет назад

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.

@ademolaadeagbo9011 3 года назад

Truth is Unit testing can be stressful, but it's worth it TDD all the way

@tirtaadi2430 3 года назад

Your BDD explanation look TDD for me.

@eloisairibarren3254 4 года назад

thanks!!! i am from argentina, this video is very easy to understand the topic!!!

@mymacaintwag 4 года назад

Today’s tdd is just a misunderstood bdd. Tdd is good for exercise, but through the tests away asap

@Developmentthatpays 4 года назад

Can you say more about that?

@mymacaintwag 4 года назад

Development That Pays look at Ian cooper, Tdd, where did it all go wrong, it is an eye opener.

@TheJmiktutt 5 лет назад

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.

@Developmentthatpays 5 лет назад

The video was designed to emphasise the differences. But you're right: there's no reason not to use both.

@gauravsharma8220 7 лет назад

Very good learning video

@Developmentthatpays 7 лет назад

Thank you!

@lancerkind 7 лет назад

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.

@Developmentthatpays 7 лет назад

Agree that the distinction could be clearer. Think you found my other videos on TDD vs BDD which arguably do a better job: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fsSMuqIpu_c.html

@piby1802 3 года назад

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.

@Developmentthatpays 3 года назад

Agree with you 100%.

@underdog578 Год назад

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.

@ajinzrathod 3 года назад

What a Lucid explanation ❤️

@Developmentthatpays 3 года назад

Thank you! Nice of you to say so 👍

@mrjokioo 3 года назад

Tdd is more prudent and requires less back-tracking and fewer holes in your wall.

@aniramibanerjee 3 года назад

I like bdd

@ym2239 3 года назад

So clearly explained. Great video

@Developmentthatpays 3 года назад

Really glad you liked it!

@johndee3301 4 года назад

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.

@suayshjust4u 2 года назад

Wonderfully explained. This example will always remain in the back of my mind. Thanks.

@zuowang5481 4 года назад

I print 10+ times doing Leetcode problems and my friends laugh at me.

@poonkinlap5470 4 года назад

Baby, thz

@installtekzdotcom9777 5 лет назад

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

@pow9606 5 лет назад

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!&^&...

@samsungs7634 7 лет назад

TDD for this one thanks for sharing

@Mars9807 7 лет назад

very nice video :). very nice example

@Developmentthatpays 7 лет назад

Thank you!

@vaibhavglasgow 5 лет назад

Wonderful explanation

@MintOutdoors 7 лет назад

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.

@vaibhavglasgow 5 лет назад

Wonderful analogy ...brilliant.

@Developmentthatpays 5 лет назад

Delighted that you liked it!

@adtorresitpro 8 лет назад

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.

@Developmentthatpays 8 лет назад

I've had another go at "TDD vs BDD" that you may prefer. Check it out: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fsSMuqIpu_c.html