TDD or BDD When It Comes To Automated Testing?

If you are just starting on your automated testing journey, it can sometimes be difficult to know where to start. There's a common argument amongst software engineers in the form of TDD vs BDD, but I'm not sure that argument even really makes sense.

Sos a Better question is - So should you start with TDD or BDD?

-

🖇 LINKS to Videos Referenced in this Episode:

🎓 FREE REFACTORING TUTORIAL:

🎓 FREE TDD TUTORIAL:

🎓 FREE ATDD GUIDE
How to Use Acceptance Testing to define what you want from your software

-

⭐ PATREON:

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

#softwareengineer #software #developer

[imqqmi]

I once bolted on unit tests that wrapped behavior of the app as a first step, that way I could capture about 80% af all the paths through the software as tests. We abused unit test framework to create large general tests, not what it was designed for but it did the trick. From there it made it easier to lift out code, SoC it, and write granular tests for it while comparing it to the large test. If the outcome was still the same it passed.
That gave us a good stepling stone for refactoring strategically parts that were monolithic or intertwined so much that separate testing was impossible. So a SoC step came next. As confidence grew we started to more and more rely on the automated testing, and start writing new code with TDD/BDD. It wasn't perfect but a lot better than it was. We caught a few high impact bugs way before the code hits production. Some minor ones slipped through but were easily fixed or roller back.

[stephendgreen]

To start TDD on new code it is useful to use modules for a modular monolith architecture. Then the TDD code can coexist alongside existing code but separated into new modules (e.g. new projects, DLLs, etc)

[Torsan]

So much gold here. To use your own words. This resonates with me!

[christianbaer]

it is really nice, that your sponsors are well aligned with the goals of your channel. Who really should sponsor you, is your shirt vendor! I absolutely love most of your shirts and if I hadn't about 70 t shirts already, I probably would buy that R2-D40 one immediately.

[rogeralmengor]

Love your videos! and your shirts... is there a merchandising page to get some of those? :)

[trafficface]

I wrote a tool to compare your staged code to a issue tracker ticket using CGP to give you a accuracy score of your solution. I think this is the first ever system test to prove the business goals align with your solution.

[CurlyCow]

My one question here is - you write a DSL, but don't you then need to test the DSL? Do you do that with basic unit tests written before writing the DSL? In other words, who tests the test-men?

[DoCLov]

I think there is a common misconception that BDD = Automated Acceptance Testing in gherkin (often at the end to end flow). I think many people make this mistake and end up with tests which are still long running, brittle and hard to maintain. Yes, it may force you to start discussing a business domain and design a dsl but the reality many people write their gherkin in hard to maintain way barely resembling a DSL. BDD has discovery, formulation and only afterwards automation. And automation could happen at any level. So I think this video adds to the confusion and people should start with TDD and do it at any level: unit, integration, system, end-to-end, for legacy systems. I love your videos and I love the topic but I think the advice has to be adjusted here. Dan North has a great video: BDD is not about testing as well. :)

[wolfphantom]

I would really love to learn how to move forward with either testing paradigm on highly database dependent micro-services. My biggest perceived hurdle is creating good, clean, reusable test data to build the tests against.

[lkedves]

TDD adds to Agile the same as V-model to Waterfall: somewhat more reliable _quality control to the production line._ The mistake is the same: they assume that the initial analysis and design decisions were correct. They are not. The real benefit of TDD as explained here is that it enforces _creating and properly managing the DSL_ (hopefully on module level), on which you should have focused from day 1. Unfortunately, this lecture still talks about the testing and tooling instead of the process of understanding: building and improving those DSLs.

This is in stark contrast with a previous video stating that IT is about problem solving. TDD has nothing to do with general problem solving, it only asks you to translate the "god given" requirements to test and production codes and run them against each other. The problem that this approach solves is the human error in this translation process, which should not be solved if can be avoided. See also, CMMI levels and low code/no code goals, or the ROI of _maintaining_ the test codes, keeping them in sync with changing or configurable requirements. In many cases, they become a dead weight and become obsolete (that's where you don't want to be).

[Nocturnal]

TDD seems straight forward for backend development, but, how to do it for the frontend?

[fragge]

Interesting video! @ContinuousDelivery
Is there a good video/guide/article on how to implement BDD on mainframe development?
I'm a mainframe developer and I'm looking into BDD, but it's hard to vision an implementation since COBOL doesn't seem to be built for that way of working.

[colemichae]

tdd is ok when you know the final item required, no one really does, so BDD is ok for most, unit testing of each item that will be changed, and integrated testing is best. Unit tests that each item provides what you need and integrated testing covers where it all comes together.

[hesperaux]

Hi Dave. I've been developing a framework for several years now that is used for automating testing (NOT software test - physical test automation). The framework was not born out of any requirements and has continuously evolved as I learn what the company actually needs. I attempted to use TDD for a while but gave up after repeatedly ripping up and rewriting huge modules of the code base. The tests were just getting in my way at that point.
Can you provide any advice for how to effectively use TDD in a scenario like this? And what is a good way to test a framework? As you know, frameworks have a lot of modular dependencies and most of their behavior is defined as interactions between components, not actions within them.

[practicalcoding]

Don’t wait for others to do it, start doing it yourself, it may then catch on

[edgeeffect]

Bearing in mind that a test isn't a test unless it verifies the behaviour of a system. And that we don't know if a system has a specific behaviour unless we test it... Is there really any difference between TDD and BDD apart from a very basic semantic one anyway? You may actually say this in the video... but it's hiding behind two un-skippable adverts so verification will have to wait until Google change their advertising policy.

[szeredaiakos]

Still sceptical..
I am on UI so there is always a problem with implementation details. There is the constant need to ID interactables which is not a particularly interesting problem but when an entire flow changes then the tests needs to change. I am on the way of solving that issue by decoupling implementation dependent test code from actual tests. But the implementation problem never really goes away.

On the upsides, if you have an obsessively decoupled app, it is fairly safe to not have automated tests. If there is no reach along the domain fault-lines and modules which change often you can pretty much go apeshit crazy and you have the guarantee wont have any problems with the rest of the application. There is a simple rule for that:

Let's say you have a task which involves 2 modules. During the span of a month you have diferent task which also involves 2 modules. If there is a 1 module overlap between the 2 tasks then you duplicate the overlapping module if you have divergent afferent coupling within that module.

Glaringly obvious example is an index file. You build a Page and you import it into the index, build a DifferentPage and you also import it into the index. At this point if someone fucks up your index file, the whole application goes to shit. If integration fails on the index file the whole application goes to shit. Natural solution: 2 index files.

That being said, on the backend I can probably noodle for a couple of hours before I feel the need to write some tests. On user interfaces you can .. interface, that is what those things do. Manual testing is very simple and fast. But not so much on things which you can't see or touch. Applications where problems are not shown immediately (aka backend) test code is mandatory regardless if it's automated or not. But it is easier to automate and to ignore implementation details. So .. can't see why not?

Regardless, properly decoupled structure based on stakeholder requests and market strategy is by far the most potent firewall against failure. BDD is certainly second.

The hardest thing of testing, i learned, is asking the right questions.There is the happy flow and quite literally nobody gives a fuck about that nor should they. If you can't satisfy that, open up a bakery instead. Asking the "what could go wrong" question is where the meat on this *DD bone is. From the data I could find, less than 10% of the developers have more than 10 years of experience. Nobody can expect the right questions from, essentially, an apprentice level programmer. That might also skew the situation against this wonderful experiment. But, completely unjustified.

[theodorealenas]

I don't get the disagreements in TDD. I'm in Uni, I practiced TDD on my own, and it's comfy. It doesn't line up with the culture of "woo I'm a rally driver", or with this odd pride some people have for feeling tired, but it's cozy and kinda nice, it's equivalent to basic disciplines in drawing.

[Hofer]

Can TDD be used for the specification? I read a book about Z. Because Z is not executable, I have no idea how to test the specifiations written in Z.

[DuartePapel]

In your opinion, is manual testing going to disappear? And is there room for manual testing in a modern, fully CI/CD software team/project?