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.
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)
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.
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?
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. :)
Yeah, I’ve seen it at the end, and that’s what I would just call a TDD approach with tests as examples of behaviour. Nowadays BDD is an agile methodology and it might be confusing to focus solely on testing.
@DoCLov BDD is TDD done right. And the fact that many people thinks that Gerkin/Cucumber/SpecFlow is BDD just shows how easily misconceptions spread in our industry.
My point exactly. You either describe how to do TDD right and leave BDD to be an agile methodology with multiple stakeholders with 3 stages of discovery, formulation and automation. ruclips.net/video/6nSwRSbc27g/видео.html
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.
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.
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).
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.
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.
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.
My ATDD training course covers this in more depth, but I'd advise that you always generate the data that you need for a test within the test, get the system into precisely the state it needs to be in to run this test. The other part to this to enable fine-grained TDD is to abstract the data storage and access, make it as simple as possible so that it does just enough to support the service createCustomer(...) findCustomer(...) etc. then fake to those abstractions to test the rest. The last trick is to ensure test isolation so that there is no shared data between test cases, that allows you to run them in any order and in parallel. There are 3 strategies for this detailed in the training course.
@@ContinuousDelivery I will take some time to look at your ATDD course you mentioned above, and thank you for your response. I conceptually understand the approach you've outlined; however, I fear the volume/interconnectivity of the data I need for some tests creates too high a barrier to repeat for each test.
@@wolfphantom I have seen this done for some pretty big data sets. The alternative is pretty difficult, because the tests are interdependent, and so you are NOT effectively controlling the variables in each test run. I think it works best to think in terms of test-isolation and then solve the problems that are related to your system to achieve that test isolation.
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.
It is in the description for the video, but try here: I get my Tee Shirts from Qwertee 🔗 Check out their collection HERE: ➡ bit.ly/3vTkWy3 🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
I've used tests to reflect my understanding of specifications, before writing implementation code. It's nice in every way, a few comments where tests can't explain things and good to go. Now, I'm in Uni, that was a team project, and here's 2 things about team projects: 1. Nobody likes an early proof that they made mistakes 2. Nobody understands what an automated test tries to say So from now on, I'll demonstrate automated tests, see the teammate's reactions, and see it from there.
@@theodorealenas3171 Tests aren't there to please your teammates. Make a competition with another team. Both teams get the same conflicting requirements. The client rejejcts all solutions, which are not perfect. Your team is not allowed to use any tests.
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.
The approach I recommend works well for Mainframe systems. I cover the design ideas in a, sorry, paid-for training course, here courses.cd.training/courses/atdd-from-stories-to-executable-specifications it is a bit more detailed than fits sensibly on RUclips. I do have this episode though ruclips.net/video/gXh0iUt4TXA/видео.html I also recommend that you check the "Acceptance Testing & BDD" Playlist for more ideas.
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.
The usual mistake in this scenario is to concentrate on the testing, rather than on the design. You should be writing tests that express what your code needs to do, and NOT how it does it, Kent Beck made a good comment recently, "TDD focuses us on the design of the interfaces between the parts of our code, and then once you have tests that define the interfaces, they also, as a side-effect, assert that you implementation choices actually work. The trap that many people fall into is to think that the goal of the tests is to test the implementation detail. Good tests have no direct dependency on implementation, which means that we can change the implementation without invalidating the tests.
@@ContinuousDelivery thank you for the reply. I will try to take another look at this in 2024. Have a happy new year sir and thanks for the helpful content.
@@ContinuousDelivery That's the point I wanted to make. _You call this method Test Driven Development,_ introduce DSLs in a side note and say that focusing on testing is a mistake. Then why don't you call it Design Driven Development? The additional benefit is a much better question: if your test code mostly depends on the DSL and properly modularized (tests the what and not the how), why your production code is different? The goals and benefits are the same... This rabbit hole is deep but this is how it all started. ruclips.net/video/8pTEmbeENF4/видео.html
@@lkedves a bunch of us tried doing that a few years ago and introduced BDD (Behaviour Driven Development) which morphed into meaning something else, I use the term TDD because people will then think that they understand what I am talking about, even if they don't. TDD is not really the wrong name, but it is misinterpreted all the time, but my experience is that that is true of every idea that becomes popular. Most people think that Continuous Delivery means continuously pushing things intro production! and that Continuous Integration means running a copy of Jenkins or TeamCity
@@ContinuousDelivery Agree, precise and agreed terminology (aka DSL) is essential for constructive communication, in contrast to the much easier and more popular chatting... 🙂 In this case I would point out that _Behaviour Driven is not Design Driven Development._ Behaviour answers "what it does" while "Design" answers "what it is", or more precisely, what DSLs you must create to describe the target system's state and behaviour. The latter then becomes expressions and scripts using the DSLs - equally for test and production logic. Am I right on that? TL;DR Background: ~10 years ago I built a Java framework to create automated configurable SWQA reports in automotive environment. It could execute business logic either from compiled source code through reflection, text scripts using the MVEL engine or workflow graphs defined in JSON. That forced me asking which is "the ultimate form" (but the first is less convenient as the others can be changed runtime), so returned to the university with the research topic "Software as a Data Structure". That gradually turned to a broader model of learning and led me to the results of forgotten heroes of informatics (Bush, Licklider, Engelbart, etc.) and away from what "most people think"... 🙂
Manual testing excels at exploratory testing and cases where brain power is required. No one wants to test a log-in screen. It simply doesn't need a living human to exercise it. So, yeah, the need for manual testing will (probably) go down, but it is unlikely to disappear.
Yes, not all processes are worth automating. Writing End to End tests for web apps, desktop apps is actually not that easy and very time intentsive. It is not economically viable or does not make business sense to spend time on automating everything except several most important features/complicated.
TDD is an overrated overused term. I worked for 6 different large companies in the UK. All of them interviewed me with TDD heavily involved. When it came to action none of them were actually implementing it in day to day work.
TDD is also overrated because in reality there are many cases where it is not useful and yet TDD gurus want you to use TDD everywhere. They are so silly.
@@tongobong1 But surely there's at least one or two cases where TDD is useful. I've spent 10 years in the business and not seen a single instance of it being used, even if it's very clearly applicable. A lot of us aren't proposing to use it everywhere all the time, having someone actually give it a chance once in a blue moon would be a huge step.
No , I find TDD to be underrated in many teams. Because in those projects that use TDD , the development is much more fun and easier , than in projects not using TDD. The problem lies in bad habits and lack of discipline of the developers responsible. That is my experience. Today I simply will decline and are declining working in non-TDD projects at all, it is too painful for me.
Could never go back to TDD. Worked with it for two years, and didn't realize how useless it was until I went somewhere else that didn't use it. Such a waste of energy compared to other testing approaches.
Hahahaha, exactly the same words I've been listening for years from people who turned out never used it and didn't know how to use it. Educate yourself.
@@thomasmoores3512 if you think you can do TDD the proper way then please tell me how many unit test you deleted while doing TDD. Those that keep all or almost all unit tests while doing TDD don't know how to do TDD the proper way.
It is wrong to differentiate tests by sizes - the number of lines they test. We should differentiate by speed and how independent they are from other tests. Unit tests should be very fast and totally independent from other tests so we can run them in paralel mode while integration tests can be slow and independent so we can only run them is sequence. This is the proper differentiation between unit and integration tests so please stop writing silly small unit tests that test just few lines of code.
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.
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)
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.
They do actually sponsor us, in a way… check out the description for money off! 👍
@@ContinuousDelivery Thanks! My wife is not going to be happy that I basically *have to* spend more money on T-Shirts now 😂
Good luck 😅
I WANT that shirt!
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?
So much gold here. To use your own words. This resonates with me!
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. :)
Dave Farley shown his BDD style tests and they weren't using gerkin. Instead it uses just a programming language with a DSL layer that is code too.
Yeah, I’ve seen it at the end, and that’s what I would just call a TDD approach with tests as examples of behaviour. Nowadays BDD is an agile methodology and it might be confusing to focus solely on testing.
@DoCLov BDD is TDD done right. And the fact that many people thinks that Gerkin/Cucumber/SpecFlow is BDD just shows how easily misconceptions spread in our industry.
My point exactly. You either describe how to do TDD right and leave BDD to be an agile methodology with multiple stakeholders with 3 stages of discovery, formulation and automation. ruclips.net/video/6nSwRSbc27g/видео.html
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.
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.
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).
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.
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.
TDD seems straight forward for backend development, but, how to do it for the frontend?
Don’t wait for others to do it, start doing it yourself, it may then catch on
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.
My ATDD training course covers this in more depth, but I'd advise that you always generate the data that you need for a test within the test, get the system into precisely the state it needs to be in to run this test. The other part to this to enable fine-grained TDD is to abstract the data storage and access, make it as simple as possible so that it does just enough to support the service createCustomer(...) findCustomer(...) etc. then fake to those abstractions to test the rest. The last trick is to ensure test isolation so that there is no shared data between test cases, that allows you to run them in any order and in parallel. There are 3 strategies for this detailed in the training course.
@@ContinuousDelivery I will take some time to look at your ATDD course you mentioned above, and thank you for your response. I conceptually understand the approach you've outlined; however, I fear the volume/interconnectivity of the data I need for some tests creates too high a barrier to repeat for each test.
@@wolfphantom I have seen this done for some pretty big data sets. The alternative is pretty difficult, because the tests are interdependent, and so you are NOT effectively controlling the variables in each test run. I think it works best to think in terms of test-isolation and then solve the problems that are related to your system to achieve that test isolation.
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.
Love your videos! and your shirts... is there a merchandising page to get some of those? :)
It is in the description for the video, but try here:
I get my Tee Shirts from Qwertee
🔗 Check out their collection HERE: ➡ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
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.
I've used tests to reflect my understanding of specifications, before writing implementation code. It's nice in every way, a few comments where tests can't explain things and good to go.
Now, I'm in Uni, that was a team project, and here's 2 things about team projects:
1. Nobody likes an early proof that they made mistakes
2. Nobody understands what an automated test tries to say
So from now on, I'll demonstrate automated tests, see the teammate's reactions, and see it from there.
@@theodorealenas3171 Tests aren't there to please your teammates. Make a competition with another team. Both teams get the same conflicting requirements. The client rejejcts all solutions, which are not perfect. Your team is not allowed to use any tests.
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.
The approach I recommend works well for Mainframe systems. I cover the design ideas in a, sorry, paid-for training course, here courses.cd.training/courses/atdd-from-stories-to-executable-specifications
it is a bit more detailed than fits sensibly on RUclips. I do have this episode though ruclips.net/video/gXh0iUt4TXA/видео.html
I also recommend that you check the "Acceptance Testing & BDD" Playlist for more ideas.
Thank you! @@ContinuousDelivery
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.
The usual mistake in this scenario is to concentrate on the testing, rather than on the design. You should be writing tests that express what your code needs to do, and NOT how it does it, Kent Beck made a good comment recently, "TDD focuses us on the design of the interfaces between the parts of our code, and then once you have tests that define the interfaces, they also, as a side-effect, assert that you implementation choices actually work.
The trap that many people fall into is to think that the goal of the tests is to test the implementation detail. Good tests have no direct dependency on implementation, which means that we can change the implementation without invalidating the tests.
@@ContinuousDelivery thank you for the reply. I will try to take another look at this in 2024. Have a happy new year sir and thanks for the helpful content.
@@ContinuousDelivery That's the point I wanted to make. _You call this method Test Driven Development,_ introduce DSLs in a side note and say that focusing on testing is a mistake. Then why don't you call it Design Driven Development? The additional benefit is a much better question: if your test code mostly depends on the DSL and properly modularized (tests the what and not the how), why your production code is different? The goals and benefits are the same... This rabbit hole is deep but this is how it all started. ruclips.net/video/8pTEmbeENF4/видео.html
@@lkedves a bunch of us tried doing that a few years ago and introduced BDD (Behaviour Driven Development) which morphed into meaning something else, I use the term TDD because people will then think that they understand what I am talking about, even if they don't. TDD is not really the wrong name, but it is misinterpreted all the time, but my experience is that that is true of every idea that becomes popular. Most people think that Continuous Delivery means continuously pushing things intro production! and that Continuous Integration means running a copy of Jenkins or TeamCity
@@ContinuousDelivery Agree, precise and agreed terminology (aka DSL) is essential for constructive communication, in contrast to the much easier and more popular chatting... 🙂 In this case I would point out that _Behaviour Driven is not Design Driven Development._ Behaviour answers "what it does" while "Design" answers "what it is", or more precisely, what DSLs you must create to describe the target system's state and behaviour. The latter then becomes expressions and scripts using the DSLs - equally for test and production logic. Am I right on that?
TL;DR Background: ~10 years ago I built a Java framework to create automated configurable SWQA reports in automotive environment. It could execute business logic either from compiled source code through reflection, text scripts using the MVEL engine or workflow graphs defined in JSON. That forced me asking which is "the ultimate form" (but the first is less convenient as the others can be changed runtime), so returned to the university with the research topic "Software as a Data Structure". That gradually turned to a broader model of learning and led me to the results of forgotten heroes of informatics (Bush, Licklider, Engelbart, etc.) and away from what "most people think"... 🙂
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?
Dave has a video on the role of QA/QE.
I've found one called "quality assurance in Agile development". Is that the One?
Manual testing excels at exploratory testing and cases where brain power is required. No one wants to test a log-in screen. It simply doesn't need a living human to exercise it. So, yeah, the need for manual testing will (probably) go down, but it is unlikely to disappear.
@@DuartePapel m.ruclips.net/video/jYuklM3prbI/видео.html
Yes, not all processes are worth automating. Writing End to End tests for web apps, desktop apps is actually not that easy and very time intentsive. It is not economically viable or does not make business sense to spend time on automating everything except several most important features/complicated.
Manual regression testing? In a CD/CI environment? You've got to be kidding. I make it a policy to try to automate everything.
I thought you know better. TDD and BDD is the same. It’s all about behavior. If you really want to learn this, follow Ian Cooper and Dan North.
Good video, but when has testing not been automated in the last 40 years?
TDD is an overrated overused term. I worked for 6 different large companies in the UK. All of them interviewed me with TDD heavily involved. When it came to action none of them were actually implementing it in day to day work.
This is a reality that the people working at SaaS multinationals like to gloss over.
TDD is also overrated because in reality there are many cases where it is not useful and yet TDD gurus want you to use TDD everywhere. They are so silly.
@@tongobong1 But surely there's at least one or two cases where TDD is useful. I've spent 10 years in the business and not seen a single instance of it being used, even if it's very clearly applicable. A lot of us aren't proposing to use it everywhere all the time, having someone actually give it a chance once in a blue moon would be a huge step.
@@salvatoreshiggerino6810 I've spent 20+ years in the business and never saw it being used except by me when it makes sense to use it.
No , I find TDD to be underrated in many teams. Because in those projects that use TDD , the development is much more fun and easier , than in projects not using TDD. The problem lies in bad habits and lack of discipline of the developers responsible. That is my experience. Today I simply will decline and are declining working in non-TDD projects at all, it is too painful for me.
Could never go back to TDD. Worked with it for two years, and didn't realize how useless it was until I went somewhere else that didn't use it. Such a waste of energy compared to other testing approaches.
Would you mind sharing what approach you use now? :)
Hahahaha, exactly the same words I've been listening for years from people who turned out never used it and didn't know how to use it. Educate yourself.
@@thomasmoores3512 if you think you can do TDD the proper way then please tell me how many unit test you deleted while doing TDD. Those that keep all or almost all unit tests while doing TDD don't know how to do TDD the proper way.
It is wrong to differentiate tests by sizes - the number of lines they test. We should differentiate by speed and how independent they are from other tests. Unit tests should be very fast and totally independent from other tests so we can run them in paralel mode while integration tests can be slow and independent so we can only run them is sequence. This is the proper differentiation between unit and integration tests so please stop writing silly small unit tests that test just few lines of code.
Testing one’s code is annoying. Ship it !!
Psychopath! :D