Elegant test code-behavior-driven development (BDD)

Understandable Code It is very important, as is the test code. In my opinion, an important thing to do for good test code is to keep the test logic clear. A complete test case usually consists of three parts:
1. Setup
2. Exercise
3. verifiy
4. teardown
If we can clearly distinguish the three parts in a test case, it is half done. However, if we only do this, it is still a little far from our "understandable" test code. In my opinion, to make the test code understandable, The first thing to do is Enable Express the testing process of each test case in a concise and clear manner . We do not want to see a long method in a test case, because we need to understand what is going on after you call so many methods and perform so much processing? Of course, we do not want to see an extreme situation: a function call is displayed in a test case. This does make the test case concise on the surface, but it loses the opportunity to show internal details. We need to describe the testing process and method, such as what operations are performed, what data is input, what results are obtained, and how to compare them with the expected results. If You encapsulate all these into a method, others can only understand what you may do, but it is difficult to understand how you will do it. Second, In the case of fail, the problem can be clearly and accurately located. . In extreme cases, there should be only one asserted or checkpoint in a test case. Narrow testing granularity can help you locate problems quickly. Generally, when a test case is fail, we also need to identify whether the problem is the code to be tested or the code to be tested. This is an annoying process. The problem locating person is not necessarily the person who writes the test code. Even the person who writes the test code needs time to understand what the test case has done. In this case, a clear expression of the test process and method becomes particularly important.
Some people may think of expressing the test process and method through documents. In my opinion, this is not a good way. An idea in Agile development:" An outdated document is worse than no document ". Why do you need a document to clarify your testing process? It can only indicate that your test code is bad enough and cannot be understood. Even if a bad code was written with enough detailed instructions, as time went on, staff changes, code modifications and maintenance, and complex files and codes became increasingly out of sync. As a result, the Code becomes worse and more complex and documents become obsolete. The best documentation is actually code.
Let's take a look at the complete test case code written by a foreigner: @ Test
Public   Void Shouldbeabletoeditapage (){
Given. thatthe (Wiki). wasableto (beatthe (pointwhereithasbeen. just_installed ));
And. thatthe (User). wasableto (navigatetothehomepage ());

When. The (User). attemptsto (changethecontent (). ("Welcome to acceptance test driven development"));

Then. The (textonthescreen (). ofthe (User). shouldbe ("Welcome to acceptance test driven development");
}

I have not explained this test case before. I believe that everyone who has read this test case can easily understand the behavior of this test case, or even those who cannot get through the code. The above test code describes the testing process in almost natural language mode. People who know it must have seen that, in fact, this is behavior-driven development,Behavior driven development(BDD for short.
Behavior-driven development (behavior driven development)

Behaviour-driven development (BDD) is an evolution in the thinking behind testdrivendevelopment and acceptancetestdrivenplanning.

It brings together strands from testdrivendevelopment and domaindrivendesign into an integrated whole, making the relationship between these two powerful approaches to software development more evident.

It aims to help focus development on the delivery of prioritised, verifiable business value by providing a common vocabulary (also referred to as a ubiquitouslanguage) that spans the divide between business and technology.
BDD is almost similar Natural Language This method describes the behavior process of the Software. Therefore, it can be directly used as the requirement document of the software, or directly applied to the test as the standard document for testing. During unit tests, we often perform tests on a function or a class, but the tested function or the class may change frequently, our test cases also need to change frequently. Then, BDD describes the entire system behavior of the software, which is close to the requirement document and greatly reduces the variability. Therefore, the test case does not need to be changed much. At the same time, such test cases are most close to requirements and to actual system behavior.
The behaviors described by BDD are like stories ( Story ), System business experts, developers, and testers work together to analyze software requirements, and then write these requirements into stories one by one. Developers are responsible for filling in the content of these stories, and testers are responsible for testing the results of these stories. Generally, a story template is used to describe the story: As [X]
I want [Y]
So that [Z]

the same story may have different scenarios. After describing the story through the template above, you can use the following template to describe different scenarios:

code highlighting produced by actipro codehighlighter (freeware)
http://www.CodeHighlighter.com/

--> given some initial context (the Givens ),
when An event occurs,
then ensure some outcomes.

A classic example is an ATM instance. The story is described as follows: Title: Customer withdraws cash
As ACustomer,
I wantTo withdraw cash from an ATM,
So thatI don't have to WaiTInLine at the bank.

As a customer, I don't need to queue up to get money from an ATM. The same story may occur in different scenarios: Scenario 1 : Account Is   In Credit
Given The account Is   In Credit
And The card Is Valid
And The dispenser contains cash
When The customer requests cash
Then Ensure the account Is Debited
And Ensure cash Is Dispensed
And Ensure the card Is Returned

If you withdraw more than your deposit, it will be the following scenario: Scenario 2 : Account Is Overdrawn past the overdraft limit
Given The account Is Overdrawn
And The card Is Valid
When The customer requests cash
Then Ensure a rejection message Is Displayed
And Ensure cash Is Not dispensed
And Ensure the card Is Returned

With such a story and scenario description, the tester can convert the above story into a test code through some BDD testing frameworks (of course, it can also be directly completed by development, the tester is here to facilitate understanding). developers can implement the Product Code and ensure that the test code passes.
Common BDD frameworks

• Boo-Specter: A Tool written for the boo language, A. Net and mono programming language.

• C-cspec

• C ++-cppspec spec-CPP

• C #. Net-nspec

• . Net-nbehave

• . Net-nspecify (incomplete site)

• Delphi-dspec

• Groovy-gspec, http://easyb.org easyb, tspec a non-English BDD framework with Thai syntax.

• Java-jbehave, jdave, beanspec, instinct

• Javascript-jsspec

• Php-phpspec

• Python-specipy, spec plugin for nose

• Ruby-rspec, shoulda, test-spec & bacon, cucumber

• Scala-specs

Back to question

Just now, I learned about a new technology or direction. I will go back and think about the significance of BDD for testing. Through the above understanding, we know that behavior-driven development is more than just a test behavior. In fact, it is a behavior done by Product Requirement analysts, developers, and tests. BDD is also a very idealistic process. Most companies cannot even achieve TDD. As testers, we are not complaining. We should be gladAs test developers, we have the opportunity to use cutting-edge and most advanced technologies to solve problems.. Development cannot achieve TDD. We can implement TDD for our own test code. We can try different languages and then select the most elegant way to implement it. Similarly,We can use the natural language description method used by BDD to compile our test cases. This is actually the key of my article.
To use behavior-driven development, we also need to break the traditional courage. Almost no one will tell you that a function is named shouldxxx (), and there are no classes or functions such as when, then, and. When you get used to it, it will become very fun.
The use of behavior-driven development can make our case description logic clearer. It can be imagined that people who maintain your code will like you very much in the future, because it saves most of his time to understand the code.
Using behavior-driven development, you can build a bridge between automated testing and manual system testing. It may be possible to form a model where manual testers are responsible for designing stories and scenarios, while automated testers are responsible for implementing stories and scenarios. With such contact, manual testers can better understand the content of automated testing, thus avoiding unnecessary repetitive work.
With behavior-driven development, you can make your tests more close to actual user behavior and locate system problems.
No silver bullet

《No silver bullet"(No silver bulletFred Brooks, the father of IBM's big computer, published a classic paper on Software Engineering in 1987. This discussion emphasizes that the real silver bullet does not exist due to the complexity of the software; the so-called "no silver bullet" means that no technology or method can increase the productivity of software engineering by ten times in ten years. The advantages of using behavior-driven development just mentioned, however, improper use may often be counterproductive. We use the joins such as when and then as functions, which does not mean that we can name them as needed. For example, if you use this or these as the function name, the action should be to return one or more objects, rather than doing other things. As you can imagine, if the name of a function is these, what a terrible thing would be for code maintainers to execute a file copy operation.
In fact, I only have a brief understanding of behavior-driven development. This article only expresses some of my personal thoughts. I hope you can point out any mistakes. Finally, what I want to achieve is:

Beautiful test code is a beautiful story.

References:
Http://behaviour-driven.org/
Http://dannorth.net/introducing-bdd
Http://www.javaworld.com/javaworld/jw-09-2008/jw-09-easyb.html