In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-21 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/02 Report--
This article mainly explains "what TDD, ATDD, BDD&RBE are respectively". The explanation content in this article is simple and clear, easy to learn and understand. Please follow the idea of Xiaobian and go deep into it slowly to study and learn "what TDD, ATDD, BDD&RBE are respectively"!
Among the current popular agile development models (such as extreme programming, Scrum method, etc.),"Test Driven Development (TDD)" is advocated-a development practice of testing first and coding later. TDD is different from the previous "code first, test later" development process, but before programming, write test scripts or design test cases. TDD is known as test-first programming in agile development and test-first design in IBM Rational Unified Process (RUP). All of this emphasizes "testing first," which gives developers enough confidence in the design or code they write, and at the same time has the courage to quickly refactor the design or code, which is conducive to rapid iteration and continuous delivery. The prerequisite for refactoring is that testing is ready. In this case, the risk of refactoring is very low, otherwise there is a relatively high risk.
TDD implementation process can be seen as two levels, as shown in Figure 1:
At the code level, writing test scripts before coding can be called Unit Test Driven Development (UTDD).
At the business level, acceptance criteria for requirements (e.g., user stories) are determined during requirements analysis, i.e., Acceptance Test Driven Development (ATDD).
Figure 1 Two different levels of TDD
Let's discuss UTDD first, as shown in Figure 2. Before you add a new feature, don't rush to write code. Think about the specific conditions, boundary values, context, etc. your program might encounter. Write test scripts for the code you want to write (classes or methods). Then, use the integrated development environment or corresponding test tools to execute this test case, the result is naturally failed (fail). Use feedback on failed tests to understand why code failed test cases and add code step by step. In order for the test case to pass, it is necessary to supplement and modify the code until the code meets the requirements of the test case and passes. All test cases were successfully executed, indicating that the newly added function passed the unit test and can enter the next link. Such a process is also suitable for code modification or refactoring. When it is actually executed, it will not strictly follow such a process, but the most basic requirement is: write the test script (code) first, then write the product code and pass the test. According to the UTDD approach, instead of writing the product code class first and then writing the test class, write the test class first and then write the product class.
Figure 2 UTDD Execution Process
UTDD fundamentally changed the attitude of developers in programming. Developers could not write code at will as in the past. Each line of code they wrote was required to be valid code. Writing all the code meant that they had truly completed the coding task. Before that, the code is written, in fact, only half of the work is completed, far from finished, because the unit test has not been executed, many errors may be found, once the defects are more numerous, the defects are more difficult to locate and correct. UTDD encourages developers to think about application scenarios, exceptions, or boundary conditions for functional features, write better code, and avoid making more mistakes. Secondly, it also ensures that the test is independent and not affected by realization thinking, ensuring that the test is objective and comprehensive. This is necessary for developers to test their code. If the reverse were true, writing product code first (i.e., feature implementation first) and testing later, testing would be influenced by implementation thinking. For example, when we examine the articles we write ourselves, we sometimes fail to discover obvious problems, which are influenced by realization thinking. In general (and in most cases), there are two barriers to developers testing their own code: mental barriers and psychological barriers. A mental block is when a developer doesn't chase after his code, and when he finds a flaw, he's likely to stop. We know that in fact the more defects there are, the more risk there is, and the more adequate testing is required. Finally, UTDD also ensures that all code is testable, that every line of code is tested, and that the (micro) quality of the code is more thoroughly ensured.
Many R & D personnel are not used to UTDD, and it will be difficult to implement UTDD. The implementation of TDD can be moved to the business layer, and ATDD can be implemented. That is, before designing and writing code, the acceptance criteria of system functional characteristics are clearly defined, which is easier to popularize and implement. For example, in agile development, the description of each user story is too simple to be testable. For example, develop an online travel network that can provide transportation, hotel, ticket booking services, etc., with a basic user story:
A user story like this is easy to develop and implement without acceptance criteria, deleting a record in a database table and modifying the corresponding flag bit in other associated tables. But the actual business will not be so simple, say cancel cancel? Don't you need a timing lead? Is the cancellation guaranteed to succeed? Do you charge related fees? Is offline processing time required? Do you need to notify users? By what means is the cancellation notified of success or failure? To answer these questions, add "acceptance criteria" to the user story, such as:
Users need to be reminded to reconfirm before canceling
Canceled 24 hours in advance.
It takes 4 hours to know if the cancellation is successful.
10% of the total amount will be charged for this cancellation
Regardless of whether the cancellation is successful or not, double notification by email and SMS is adopted.
Users can query cancelled related records afterwards
Need to keep logs of bidirectional operations between customers and travelnet
This way, the user story is testable, the developer knows how to implement the user story, and the results achieved are not too different from the results expected by the product manager.
A specific development model evolved from ATDD is BDD (Behavior Driven Development). BDD only clarifies the acceptance criteria, which can be regarded as the instantiation of ATDD, that is, lists the application scenarios that the user story may encounter, and specifies the expression mode of this application scenario as GWT format, namely:
BDD takes it a step further and is Requirements By Example (RBE), which clarifies the specific representation of requirements. Again, using the user story above as an example, you can create requirements instantiations similar to the following.
The clearer the requirements, the more consistent the understanding between users, product managers, development and testing, etc. will be, the less bias and misunderstanding will occur, which will facilitate the work of development and testing. Based on RBE, developers can write product code, testers can write test code independently, and the work of product managers will become easier, without too much explanation and no need to answer various questions about development and testing.
From the perspective of requirements, BDD and requirements instantiation clearly define requirements, unify the understanding of users, product managers, development and testing, etc., so that everyone is on a level and R & D work is more efficient.
From the testing point of view, requirements are tests, product requirements are test requirements, requirements can be executed, that is, in one step, requirements into automated test scripts, developed functional characteristics can be automatically verified at any time.
TDD changes the way of thinking of destructive testing in the past, testing first, coding later, more in line with the idea of "defect prevention." As a result, the way coding thinks has changed a lot, writing high-quality code to pass these tests, thinking about the real needs of users, application scenarios and some exceptions when making every design and writing every line of code, ensuring that the functional characteristics of the implementation meet expectations and are robust. Testing has also shifted from a destructive approach to a constructive one. Under the influence of this positive attitude, the productivity of developers and the quality of products will be significantly improved, and the goal of "Quality is built in" will be truly realized.
Thank you for your reading. The above is the content of "TDD, ATDD, BDD&RBE respectively." After studying this article, I believe everyone has a deeper understanding of TDD, ATDD, BDD&RBE respectively. The specific use situation still needs to be verified by practice. Here is, Xiaobian will push more articles related to knowledge points for everyone, welcome to pay attention!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 212
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.