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

7 жыл бұрын

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

7 жыл бұрын

"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: kzread.info/dash/bejne/nKap1ZRqYsfQgNY.html

5 жыл бұрын

Sorry I am lefty so......

@kirankamath5891

4 жыл бұрын

Sir your explanation was more precise I see.

@gamemusicmeltingpot2192

3 жыл бұрын

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

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

6 жыл бұрын

Thank you very much!

@sumanam5318

4 жыл бұрын

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

@premprakash7981

3 жыл бұрын

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.

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!

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.

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.

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

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.

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!

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!

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!

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

7 жыл бұрын

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!

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

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!

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.

Wonderful explanation

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

4 жыл бұрын

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

Great Explanation. Thanks!

@Developmentthatpays

6 жыл бұрын

+Dev Raj - Many thanks!

TDD for this one thanks for sharing

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

5 жыл бұрын

😂 like it!

Wonderful analogy ...brilliant.

@Developmentthatpays

5 жыл бұрын

Delighted that you liked it!

The best explanation you can get 🔥🔥

@Developmentthatpays

5 жыл бұрын

Thank you!

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

@Developmentthatpays

6 жыл бұрын

Thank you! That's very kind of you.

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

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

5 жыл бұрын

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 like behavior driven way since it can be automated with feedbacks

So clearly explained. Great video

@Developmentthatpays

3 жыл бұрын

Really glad you liked it!

very well explained 👍

@Developmentthatpays

6 жыл бұрын

Thank you!

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 ?

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.

Explain TLD ( test last Development)

@Developmentthatpays

3 ай бұрын

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

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

Very nicely done!

@Developmentthatpays

Жыл бұрын

Thank you!

Wow, now I finally get it.

Very good learning video

@Developmentthatpays

6 жыл бұрын

Thank you!

for me bdd was more intutive.

@Developmentthatpays

6 жыл бұрын

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

"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. 👍

What a Lucid explanation ❤️

@Developmentthatpays

2 жыл бұрын

Thank you! Nice of you to say so 👍

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: kzread.info/dash/bejne/mKeHr9eqedPbj8Y.html

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

very nice video :). very nice example

@Developmentthatpays

6 жыл бұрын

Thank you!

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

7 ай бұрын

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.

sooo coollll!!

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

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

2 жыл бұрын

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

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: kzread.info/dash/bejne/goJ1k6WkYpDUhsY.html

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

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.

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 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…

@Developmentthatpays

Жыл бұрын

Yep, I'd agree with that.

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

@Developmentthatpays

2 жыл бұрын

👍

Your BDD explanation look TDD for me.

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

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

I like bdd

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

@Developmentthatpays

3 жыл бұрын

Can you say more about that?

@mymacaintwag

3 жыл бұрын

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

Did my guy just redrill a hole over another hole?

TDD

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?

Or you can just put shelf against the wall and make 4 markings using holes in the shelf 🤫

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.

@Developmentthatpays

7 жыл бұрын

I've had another go at "TDD vs BDD" that you may prefer. Check it out: kzread.info/dash/bejne/mKeHr9eqedPbj8Y.html

Did you REALLY screw up hanging a shelf that was level? You gotta be paying no attention to pull that off man lol

@Developmentthatpays

5 жыл бұрын

What can I say: It's my superpower.

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