TDD or BDD When It Comes To Automated Testing?

these days it's my impression that most people would agree that they'd prefer to work on software with good automated tests than not there are some people out there still who find objections to this we'd like to do it but ours is a special case but they're wrong even so I think that even these people would prefer it if they could see the results of their changes in a few minutes rather than the more normal few few weeks or months that you get if your releases are dependent on manual regression testing of course of course there are some teams that don't test their software at all before releasing but there's no accounting for psychopaths so the problem isn't really should we automate testing it's more how should we automate testing so that's our topic for [Music] today hi I'm Dave Farley of continuous delivery welcome to my channel we've been producing content here now for nearly 3 years and and we've released over 250 videos I hope that you've enjoyed some of them the channel has significantly exceeded our original expectations in its growth but it would mean a lot to me if you could help us to reach even more people by sparing a second or two to register your support So if you haven't already please do hit subscribe and if you are already a a subscriber then thank you but please do check that you've also clicked on the Bell notification icon so that YouTube will keep you informed when we release new content and finally if you enjoy the video today hit like as well I was talking to a client recently and we ended up having a replay of a conversation that I've had many times before they said we'd like to improve our game at testing we find it hard to get automated testing right so we end up relying way too much on manual testing because it seems easier maybe we should start tdd or bdd where do you think we should begin these are good questions reducing the Reliance on slow expensive unpredictable manual testing is perhaps one of the most consequential changes that you can make to your development process the problem here though is that the ideal answer is that you need both fine grained test rthm development and the more specification focused process of behavior-driven development to do the best job of this I am certainly guilty of standing up this ideal picture as the goal sometimes because I think it is really the goal but practically you're not going to be able to achieve that in a single giant leap so where should you begin to improve your automated testing approach I've said here many times before that I think that test driven development is an immensely valuable tool in software development it gives us the fastest clearest feedback on the design of our systems that we can get and as a side effect of organizing our work this way by always starting from a test we also end up with lots of tests that are nicely decoupled from our code so don't break to it easily when the implementation detail changes meaning that we can run them all to confirm that our code still works when we change it let me pause there and say thanks to our sponsors we are sponsored here by equal experts tric centers and transic and are very fortunate all of these companies offer products and services that are very well aligned with the topics that we discuss here every week so if you're looking for excellence in continuous delivery and software engineering in general please do click on their links in the description below the value of test driven development is not to be dismissed lightly and I think is one of the most valuable tools to help us build great software if you want to increase your skills as an individual developer I'd really seriously recommend that you learn test driven development but if you want to increase your Effectiveness as an organization or team test driven development is not the easiest place to begin the problem is that test driven development while it does have a big impact on the quality of our designs that means that code written with test driven development looks different it's better the problem is that with this it means that if you want to retrofit test driven development to existing code that code is almost certainly going to be the wrong shape so adding tdd is a complicated disruptive thing to do at this stage so in general I don't recommend it as a starting point it's much easier to adopt test driven development for new code rather than trying to force fit it back onto Old code there are techniques that can help you to get old code into a better more testable shape take a look at my free tutorial on refactoring for some advice but this is always a long slow process and to be honest you're never going to end up with a beautiful wonderfully easy to maintain system this way it will just be better than it was before I recommend that every developer learns the skills of tdd I think it will make you a better developer whatever your skill level I've got a free tutorial for that too but most of us are not starting out with a blank sheet we are in organizations with histories surrounded by software that wasn't built in this way and so is already the wrong shape so what do we do now well step one is that if you are starting on a brand new project start off full bore with continuous delivery test driven development continuous integration behavior-driven development deployment pipelines the lot from day one this is the easiest time to adopt these new more effective practices while your code is still in simplest possible state in that it doesn't even exist yet start new things as you mean to go on full-blown continuous delivery here's a video on how to start a project like that for the rest of us though I think that behavior driven development also known as acceptance test driven development is most often the more effective starting point to introduce better automated testing to our projects bdd is an easier retrofit to existing code I I've known teams to adopt it for ancient Legacy Mainframe systems as well as large complex code bases written with more modern Technologies and lots of other projects of all shapes and sizes and Technology mixes too my view is that as long as you can fake some inputs to a system and collect some outputs from it you can test pretty much everything that you need to we'll talk about the tricky bits later think of this approach in terms of eliminating your dependence on manual regression testing rather than on aiming for some form of testing Perfection aim for something more practical good enough testing that you can run all of the time our goal with automated testing is not to be perfect and to test everything it's to replace the need for humans doing regression testing so we only need to be good as good as they were to be gaining an advantage because once what they were doing is automated as a test we can run those tests as many times as we like so we'll get faster feedback on problems than any army of humans could ever possibly deliver and our tests will be more repeatable too because we can simply rerun them whenever we need to computers are good at being repetitive people aren't so start your journey to better testing by learning how you determine the releasability of your software now and then use the techniques of acceptance test driven development and bdd to build a domain specific language that makes it easy for you to script scenarios for the behaviors of your system start with a simple evaluation of some core behavior of your system that would tell you that the system's simply up and running correctly and build this first version of your DSL around that scenario to achieve this you'll need to automate the deployment of the system but once again this step is a significant one on the journey to gaining more stability and control overall the test cases themselves should only describe what the system does not how it does it it I describe this approach in more detail in this video once you have this first scenario up and running add more all the time growing the capabilities of your DSL along the way with the aim of being able to capture scenarios of use of the system easily and quickly these are your test cases learn from whoever currently determines the releasability of your system and use what they do as a guide to finding useful scenarios get these people inv involved in helping you to Define what you need to test to determine releasability but do be cautious of getting too lost in implementation detail it's quite common for people that are focused on testing to think in terms of complete this form and push this button rather than what you are really interested in the user needs to try and achieve this goal if you follow this approach very quickly you'll find that you get to a stage when most scenarios that you can think of are already supported by the DSL so now now they are very easy to write indeed as you discover new areas of functionality that the DSL doesn't yet support use the four- layer approach to add them in a way that maintains a clean separation of concerns that keeps your test cases independent of the implementation details of your system I tend to play a little game whenever I'm writing a test case and I ask myself does my system Express what my system does in a way that I can imagine completely replacing my existing system with a wholly different one based on entirely different Technologies if we're building a webbased system I imagine changing it to work via voice control or thought control instead without needing to change the test scripts at all obviously I'm going to need to change the lower layers in my four layer approach because the protocol drivers are the place that know how the actual system works but the rest is focused on what the system does not how it works which means that the rest should remain the same whatever the nature of the technology ology if I can write my test case like that then I've achieved the right level of abstraction if not my tests are already too tightly coupled to the implementation detail of the system and therefore will break more easily this is an exceedingly effective and high value step because now it's simple to capture the scenarios that my system supports and as soon as you've have these tests written you can start running them all of the time so getting much faster and more effective feedback into the development process the biggest technical barrier here is usually down to problems of repeatability in the tests if you don't accurately and effectively control the variables of for your system under test you may get different results each time you run the same test but if that's the case then the same is true if you're doing manual testing you'll get different results every time you run the test the slight advantage that manual testing has if that's the correct word is that you've got smart humans interpreting the results they can judge the differences is uh after each run and make a subjective decision on whether the system's now releasable or not people are certainly currently better than machines at these sorts of subjective guesses but they are still guesses our aim is to move Beyond guessing though and exert enough control to make more objective cause on the state of systems releasability so use the creation of these acceptance tests as a platform on which to build to increase the determinism of the system as a whole use infrastructure code techniques to Version Control and deploy the system build tests and test domain specific language to support getting the system more accurately into well-controlled States as part of the setup of each test I describ several more techniques of how to better control the variables and avoid flaky tests in this video this approach is much more achievable in practice than I think most people believe I'm going to make an extravagant claim but even if this was only slightly true it would still be worth the try it's my belief that once you have the barebones of an acceptance testing DSL in place the work of only a few days for most systems then for approximately the same amount of time it takes you to do the manual testing once maybe twice you can replace the manual testing with automated tests if you'd like to learn more about this approach I have a free guide for that too check this out that out in the links thank you very much for watching I hope you've enjoyed today's video I'd also like to say thank you to all of our patrons for their support and if you'd like to become a patreon member there's links for that in the description below too thanks again and [Music] bye-bye

Channel: Continuous Delivery

Views: 20,555

Keywords: tdd, bdd, tdd vs bdd, automated testing, test driven development, behavior driven development, behaviour driven development, how to start automated testing, how to use bdd in software engineering, how to use tdd in software engineering, software engineering, software development, programming, software testing, dave farley, continuous delivery

Id: Z9fGG1k6P40

Length: 12min 44sec (764 seconds)

Published: Wed Dec 27 2023