BDD - working method or TDD in a fashionable wrapper?
The two approaches to development through testing cause particularly much controversy - because of some methodological similarities, TDD (Test Driven Development) and BDD (Behavior Driven Development) are often confused even by professionals. Alfa-Laboratories senior testing automation engineers Yulia Kovaleva and Anna Chernysheva tell basic things about the similarities and differences between the two popular methods and what approach they use in the company itself.
Yulia Kovaleva, senior Java autotest developer at Alfa Laboratories
Dedicated to testing for more than 4 years, now she is developing a library of steps for scaling test automation using Cucumber and Selenide.
')
Anna Chernysheva, senior Java autotest developer at Alfa Lab
She worked in large e-commerce projects, participates in the creation and support of several BDD frameworks, and also deals with the implementation of engineering and DevOps practices.
- What is the main difference between TDD and BDD?
Anna Chernysheva : Understanding the techniques of TDD and BDD differs in different companies, we will talk about how things work in the Alpha Laboratory. The concepts of both approaches are similar, first the tests run and only then the development begins, but their purpose is completely different. TDD is more about programming and testing at the level of technical implementation of the product, when the developers themselves create tests. BDD is intended to be described by a tester or analyst of user scripts in natural language - in the language of business, so to speak.
- Is BDD just a buzzword or a fundamentally new approach to developing through testing? It differs from TDD only by using natural languages ​​to describe tests?
Yulia Kovaleva: BDD is indeed a buzzword, but not everyone knows how to “cook” it correctly. At Alpha Laboratory, we had to take a comprehensive approach to solving problems and completely change many aspects of the functioning of the whole team, which allowed us to significantly reduce the cost of the testing process. It is much easier to hire someone who can describe test scripts in Russian than to find a specialist who can implement these tests, for example, in Java.
The BDD approach together with engineering practitioners allowed us to abandon legacy documentation containing irrelevant information and receive new documentation on the fly, store it with the project, which allowed analysts and testers to be closer to the code.
- Not only testers are involved in the development of BDD scenarios, is the need for automation automated?
Yulia Kovaleva: Of course, leaving only testers without automation systems in the team is rather short-sighted. It will take some tools and a person who owns them in order to realize the technical component that the tester cannot do on his own.
Anna Chernysheva : The need for a team of experts in automation of testing decreases, because there are frameworks that testers can use. The automator adds new functionality to the test framework, and it immediately becomes available to all teams.
- In addition to the traditional for TDD unit-tests when using the BDD-approach are also carried out behavior tests. Does the testing process end there or is it more complicated?
Anna Chernysheva: Everything is much more complicated, since BDD is more likely a process whose goal is to reduce the cost of implementing new features. Even at the start of development, we get important artifacts. For example, understandable to support the documentation. This documentation allows all interested parties to form their own ideas about the product and user behavior scenarios, which should be implemented during development iterations. With the BDD approach, we also reduce the threshold for entry into the project of new participants.
- Many people believe that BDD can be seen as a transition from development based on unit-tests to development based on integration testing. And how is the situation really?
Yulia Kovaleva: We conducted such an experiment. An attempt to use BDD-tools for writing unit-tests was not successful, after some time the developer refused to write behavioral tests. When we talk about automation, BDD fits perfectly into this story, but it didn’t cost to apply such an approach to unit testing, it didn’t do us any good. With integration testing, the benefits of BDD will be significant - here we look at the entire product as a whole.
- In which cases the BDD approach is used for testing and why is it better than the more traditional TDD?
Anna Chernysheva: BDD is mainly used to test the interaction of different components of the system; this, as already mentioned, is the level of integration testing — it is behavioral and checks various business cases. TDD is used for development through unit testing directly by programmers who write code through this approach. In general, if in a simple way, TDD checks only modules, and BDD - user scenarios.
- Why did we need new BDD frameworks, is it not easier to put BDD into a set of recommendations for writing TDD and use existing ones?
Julia Kovaleva: BDD appeared to make the development team closer to the business, to organize a dialogue between business, developers and testers. With the TDD approach, you need to write tests in formal programming languages. Tests and code lie in one place, they are quite difficult to maintain, and even a tester or business analyst will hardly climb to see what we wrote there. The two most popular BDD frameworks are JBehave and Cucumber. How to use them correctly, we will tell at the next conference Heisenbag 2017 Piter .
Anna Chernysheva: This confusion between TDD and BDD went from a common idea for different approaches: first, tests are written, and then development takes place. With all the similarities, they are designed for different purposes and require the use of various tools.
- That is, BDD can not be considered an extension of TDD?
Anna Chernysheva: Yes, we think that way. Instead of a test model, we have custom scripts that we automate in one sprint with the development. Moreover, in the “Alpha-Laboratories” the BDD-approach is organically incorporated into engineering practices.
- QA is considered a female profession. What do you think, what is the reason and how true? Is there any concept of female and male profession in IT?
Anna Chernysheva: Now they are trying to get away from this, but women's thinking is more abstract, and specific details are important for men - this, of course, is all individual, but if you take Alpha Laboratory, then the number of female testers is somewhat higher. Maybe testing requires creativity, and girls - more creative natures?
Yulia Kovaleva: You can conduct an experiment and calculate how many girls and men will come to Heisenbag.
At Heisenbag 2017, Yulia Kovaleva and Anna Chernysheva will compare Cucumber and JBehave. Which BDD framework has more features? How to “prepare” them correctly and what difficulties will be encountered during testing - the competition of the leading autotest developers at Alfa Laboratories will be held in the best traditions of Mortal Kombat.
BDD Girls Battle: Cucumber vs. Jbehave
The full conference program is available on the website .
Yulia Kovaleva, senior Java autotest developer at Alfa Laboratories Dedicated to testing for more than 4 years, now she is developing a library of steps for scaling test automation using Cucumber and Selenide.
')
Anna Chernysheva, senior Java autotest developer at Alfa Lab She worked in large e-commerce projects, participates in the creation and support of several BDD frameworks, and also deals with the implementation of engineering and DevOps practices.
- What is the main difference between TDD and BDD?
Anna Chernysheva : Understanding the techniques of TDD and BDD differs in different companies, we will talk about how things work in the Alpha Laboratory. The concepts of both approaches are similar, first the tests run and only then the development begins, but their purpose is completely different. TDD is more about programming and testing at the level of technical implementation of the product, when the developers themselves create tests. BDD is intended to be described by a tester or analyst of user scripts in natural language - in the language of business, so to speak.
- Is BDD just a buzzword or a fundamentally new approach to developing through testing? It differs from TDD only by using natural languages ​​to describe tests?
Yulia Kovaleva: BDD is indeed a buzzword, but not everyone knows how to “cook” it correctly. At Alpha Laboratory, we had to take a comprehensive approach to solving problems and completely change many aspects of the functioning of the whole team, which allowed us to significantly reduce the cost of the testing process. It is much easier to hire someone who can describe test scripts in Russian than to find a specialist who can implement these tests, for example, in Java.
The BDD approach together with engineering practitioners allowed us to abandon legacy documentation containing irrelevant information and receive new documentation on the fly, store it with the project, which allowed analysts and testers to be closer to the code.
- Not only testers are involved in the development of BDD scenarios, is the need for automation automated?
Yulia Kovaleva: Of course, leaving only testers without automation systems in the team is rather short-sighted. It will take some tools and a person who owns them in order to realize the technical component that the tester cannot do on his own.
Anna Chernysheva : The need for a team of experts in automation of testing decreases, because there are frameworks that testers can use. The automator adds new functionality to the test framework, and it immediately becomes available to all teams.
- In addition to the traditional for TDD unit-tests when using the BDD-approach are also carried out behavior tests. Does the testing process end there or is it more complicated?
Anna Chernysheva: Everything is much more complicated, since BDD is more likely a process whose goal is to reduce the cost of implementing new features. Even at the start of development, we get important artifacts. For example, understandable to support the documentation. This documentation allows all interested parties to form their own ideas about the product and user behavior scenarios, which should be implemented during development iterations. With the BDD approach, we also reduce the threshold for entry into the project of new participants.
- Many people believe that BDD can be seen as a transition from development based on unit-tests to development based on integration testing. And how is the situation really?
Yulia Kovaleva: We conducted such an experiment. An attempt to use BDD-tools for writing unit-tests was not successful, after some time the developer refused to write behavioral tests. When we talk about automation, BDD fits perfectly into this story, but it didn’t cost to apply such an approach to unit testing, it didn’t do us any good. With integration testing, the benefits of BDD will be significant - here we look at the entire product as a whole.
- In which cases the BDD approach is used for testing and why is it better than the more traditional TDD?
Anna Chernysheva: BDD is mainly used to test the interaction of different components of the system; this, as already mentioned, is the level of integration testing — it is behavioral and checks various business cases. TDD is used for development through unit testing directly by programmers who write code through this approach. In general, if in a simple way, TDD checks only modules, and BDD - user scenarios.
- Why did we need new BDD frameworks, is it not easier to put BDD into a set of recommendations for writing TDD and use existing ones?
Julia Kovaleva: BDD appeared to make the development team closer to the business, to organize a dialogue between business, developers and testers. With the TDD approach, you need to write tests in formal programming languages. Tests and code lie in one place, they are quite difficult to maintain, and even a tester or business analyst will hardly climb to see what we wrote there. The two most popular BDD frameworks are JBehave and Cucumber. How to use them correctly, we will tell at the next conference Heisenbag 2017 Piter .
Anna Chernysheva: This confusion between TDD and BDD went from a common idea for different approaches: first, tests are written, and then development takes place. With all the similarities, they are designed for different purposes and require the use of various tools.
- That is, BDD can not be considered an extension of TDD?
Anna Chernysheva: Yes, we think that way. Instead of a test model, we have custom scripts that we automate in one sprint with the development. Moreover, in the “Alpha-Laboratories” the BDD-approach is organically incorporated into engineering practices.
- QA is considered a female profession. What do you think, what is the reason and how true? Is there any concept of female and male profession in IT?
Anna Chernysheva: Now they are trying to get away from this, but women's thinking is more abstract, and specific details are important for men - this, of course, is all individual, but if you take Alpha Laboratory, then the number of female testers is somewhat higher. Maybe testing requires creativity, and girls - more creative natures?
Yulia Kovaleva: You can conduct an experiment and calculate how many girls and men will come to Heisenbag.
At Heisenbag 2017, Yulia Kovaleva and Anna Chernysheva will compare Cucumber and JBehave. Which BDD framework has more features? How to “prepare” them correctly and what difficulties will be encountered during testing - the competition of the leading autotest developers at Alfa Laboratories will be held in the best traditions of Mortal Kombat.
BDD Girls Battle: Cucumber vs. Jbehave
The full conference program is available on the website .
Source: https://habr.com/ru/post/329468/
All Articles