TDD vs BDD. The giants of test go head-to-head (2)

This time, we'll be focusing on Code Coverage, Maintainability and Portability. And crowning a winner. Will it be TDD or BDD?

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

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"

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


It's time to bring the TDD vs BDD battle to a bruising conclusion. Which will emerge victorious?

Will Test Driven Development be pinned to ropes? Or will Behavior Driven Development be out for the count?

ROUNDS:
- 2:18 - Round 5: Code Coverage
- 2:54 - Round 6: Maintainability
- 4:07 - Round 7: Portability

PREVIOUS EPISODE:

-------------------
63. TDD vs BDD. The giants of test go head-to-head (2)
# #DevelopmentThatPays

Previously... TDD and BDD went head to head. Round 1 [Focus] was a narrow win for BDD. Round 2 [Writer/Reader] was a decisive win for BDD. But then the tide turned: Round 3 [Speed] went to TDD. And Round 4 [Specificity] went the same way. That's two rounds a piece. But this bout is far from over. Go live ------- Welcome to Development That Pays. I'm Gary Straughan. And welcome back to second and final part of our TDD vs BDD battle. Before we get back to the fight, there's the small matter of the question I left you with last time. Here's a quick reminder: "You're responsible for a major system. It has excellent test coverage, with a full complement of Unit Tests and Behavioural Tests. A major deadline is looming and you're gearing up for the release. Vexingly, there's one failing test. And the Development Team say they won't be able to fix it in time for the planned release Question 1: Do you go ahead and release to live Question 2: Does your answer to question 1 depend on the TYPE of test that is failing." So what do you think. Would you release Alistair, you were clear... "If there is a failing test then the system is not production ready. I would argue that it (almost) never depends." Although you did go on to say that might be mitigating circumstances, such as the value of the new features in the release outweighing negative impact of a bug. Andrew, you were more bullish. And I liked that you expected the Product Owner to be part of the Go / No Go decision My answer Well, I'm not a brave man, so I probably wouldn't... But let's dig just a little bit deeper. If all of the Unit Tests are passing, and one Behavioural Tests is failing This is bad news. A failing Behavioural Test means that the "contract" has been broken. That's a clear DON'T RELEASE situation in my book. The other case - all the Behavioural Tests passing and one Unit Test failing - is more nuanced. If all the behavioural test are passing, then the contract is intact. Everything that the system promises to do, it does. Whatever is failing is having no impact* on the external functionality. One possibility is that application code covered by the failing test doesn't do anything. So the question becomes: "Why NOT go live " Did you spot the asterisks These arguments only hold water ONLY if the level of code coverage is very high. Which brings us right back to our bout. Round 5: Code Coverage. -------- A high level of code coverage is a good thing. The higher the level, the better you sleep at night. But 100% code coverage is rare and difficult - especially where unit tests are concerned. Levels of 70% and 80% would be considered by many to be good. For BDD, the picture is rosier - the code coverage percentages tend to be higher. For a microservice with a well-defined API, there's no reason NOT to have 100% code coverage. Round 6: Maintainability -------- The only constant is change. So a good question to ask is what will cause the tests to change. Any change to the functionality of the code is going to require the unit tests to change. And by the way, if the functionality Is to change, then the tests change first. A change is still development, and the development is still test driven! What about on the BDD side Not all functional changes impact the external behaviour. Going back to the cash machine example for a moment: I could exchange the card transport mechanism for another model. I could exchange the screen for one with better resolution. I could upgrade the keyboard None of these substitutions would require a change to this Behavioural Test. For the sake of fairness, I should say that the the inverse situation is possible: If new and di

[davidofug]

I don't know why you are not having a billion followers. Thank you

[heitoralthmann]

Simply THANK YOU for all your videos! What a great production, method and synthesis in a short time! They clearly outstand the majory of other tech teaching videos on YT. Thank you once again! :D

[nidhigupta]

Just loved the way the concept made clearer... Thanks!!!

[laurie]

Thank you so much. Your videos are such an inspiration. Please do sprint simulation videos. How to use Jira in a typical work day...

[IsaacSerafino]

Coverage: 100% is probably not desirable, even if it would be feasible. Also, I feel it is probably very much easier to achieve higher coverage with unit tests than with functional tests. That is because functional tests cover the big picture of execution through the code in a limited number of predetermined paths. Unit tests cover the fine-grained details of each unit; to achieve something similar with functional testing would require sets of functional conditions with exponentially more permutations in various details of each.

[brentonkelly]

Well presented Gary. Interesting outcome and summary.

[julianagrutzmann]

Amazing series with outstanding quality! Thank you for producing these videos!

[yasmin_jsmn]

you're super awesome, I really loved the way you explain concepts

[jialieyan]

Very helpful and good video! You made the concept very clear! Thanks

[hristoborislavov]

Why don't you upload new videos? They are great and helped me a lot with starting a wholly different position in the IT sector from Sales.

[pow]

Can you summarise how BDD is implemented? What tools? I have used those testing tools that test the behaviour of the GUI interface at run-time. There is no way they are portable if the application is rewritten. They change far more than unit tests. Units tests only change when the class/method/function interface changes. It could be argued that if the interface changes then their should be a another version of the method with new unit tests. As a developer I would rather work on an application that has unit tests by a country mile.

[doosrajawad]

Can you go live with a failing behavior test? Yes, sometimes. I rode my motorbike to the store today, even though the clock on the handlebar failed its behavior test. The new ATM machine gave me the right amount of cash but said "Thank yoo" in the end. Maybe the bank decided that this was less embarrassing than an "down for maintenance" sign. There are no absolutes; just tradeoffs.

[MarkGavrilov]

An amazing explanation, but. End of the day, both of methodologies are good for specific scenarios and purposes. It is not math, it is more of approach to cover specific functionality. If Developer or QA Engineer deliver something to production and both of methodologies passed, but not catched a bug, who responsible in this case for missing a bug/bugs? Methodology, approaches, vision? Especially today, when everything in agile prospective, both of methodologies give you a added value to reach a goal.

[genctasbasi]

Great content, presented very well. A rear duo, well done.

[MikeJonesTechno]

Gary, just curious what was your objective in this series suggesting a battle that one was 'better' than the other? As you point out, applications should contain unit tests, UI tests - and other contract / component / integration test levels of the test automation pyramid. Did you mean to be controversial to incite more YouTube viewers or have you experienced this test rivalry in a real work place? :-(

[BDYH-eykd]

Feel like BDD is a must to finish a project. Also to start. Any other way is bad management and amateur's company.
Yes the company manger I work for just like to 'put bandages' on bleeding wounds, that the entire method.

[MatthewRalston]

Uhhhh... i liked the series and the comparison, nice work and all... but you can't take BDD tests out of a language context. You could argue that all that is required for a BDD test is the feature specification (Given, When, Then) as you are doing. On the other hand, what makes this high-level, human language specification actually serve as a test for a feature of code in a programming language... is that BDD frameworks (rspec, mocha, etc.) all include code. Further more, you can't divorce BDD tests from additional abstraction layers and interfaces including headless browsers. Since we are all talking about code, given that we are developers, then we can all agree that TDD unit tests and BDD (acceptance/integration?) tests are similarly portable, if you define portability as cross-platform usage or reliance on frameworks. BDD isn't magically more portable than TDD. You're talking about generalization at the specific abstraction layer that BDD is designed to test around. You can write BDD tests for functions... it doesn't really matter that the abstraction level is low. If your testing framework has multiple language support, then your specs should still translate. Alternatively, you could write BDD tests for web UIs, and then change the whole API layer or web service layer and the BDD tests should still work. BDD is only as portable as the abstraction layer with which it is used.