Test Driven vs Behaviour Driven Development

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"

= = = = = = = = = = = =


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)

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

[МаксимМарич-гы]

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

[cyrusbesabella]

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!

[justinjuner]

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.

[MAMajidApril]

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.

[dilbabajon]

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

[CarlosRamirez-jttm]

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!

[yutubl]

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

[xerotolerant]

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.

[CookRacingUK]

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.

[BinhNguyen-nndk]

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

[luk]

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.

[prashantsalgaocar]

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.

[prgosavi]

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.

[mickaelarazor]

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.

[ariz]

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 ?

[davefarley]

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!

[UjjwalPrakashSinha]

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

[LrCloud]

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

[es-tekes-tek]

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!

[ademolaadeagbo]

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