[Reading notes] from TDD to BDD
|
FREE Diabetes Recipes eBook! Click here to redeem. |
Recent study ruby, also used the rspec, the traditional xUnit is a product of the guiding ideology of TDD, but rspec is regarded as BDD (Behavior Driven Development) under the influence of the product.
Difference between TDD and BDD what exactly is it?
The first is the difference between the train of thought, the traditional TDD concern is whether the interface is correctly implemented, it is usually each interface has a corresponding unit test function. The BDD usually class as a unit, concerned about whether a class implements the behavior defined in the document.
Implementation of the specific point of view from the rspec, the main differences are as follows
1. Rspec can become part of the design, you design a class, usually the first to write what features need to implement this class, and then one by one to achieve needs, such as XmlParser, you will plan his first three features, from the string initialization, support the “==” symbol in support of serialized string, this time you can write the following test code
# Xml_parser_spec.rb
describe “XmlParser” do
it “should support init with string”
it “should support ==”
it “should can convert to string”
end
At this point you can run the following command to see the class act you plan
$ Spec-f n xml_parser_spec.rb
XmlParser
should support init with string (PENDING: Not Yet Implemented)
should support == (PENDING: Not Yet Implemented)
should can convert to string (PENDING: Not Yet Implemented)
…
The output of the above can clearly see the XmlParser need to support functions. You do not need these features in your head, not on your TODO list, directly put on the line here
2. Use of a sentence to describe the behavior you want to test, rather than simply repeat the name of the interface being tested, such as a typical test:
it “should return [Miniblog] with different id” do
Which “should return [Miniblog] with different id” is the description of this test
3. Multi-level context, to facilitate the behavior of the class assigned to multiple groups, and each group can have a different context (setUp tearDown), such as an xml parser, as shown in the test code can be divided into two acts group data in the face of legitimate behavior and the behavior encountered illegal data
describe XmlParser do
context “with valid data” do
before do
@ Valid_data = “ 123 ”
end
…
end
context “with invalid data” do
before do
@ Invalid_data = “ 123 ”
end
…
end
end
4. Support automatic documentation, can already be seen in a spec in support of the document to generate a brief description of your object, the following is an example of a relatively long used to describe Douban:: Authorize the function, the tree structure of the class functions assigned to multiple groups
5. Statements closer to the habit of natural language, such as the xUnit usually assertEqual (a, 1), and the frequent use of a.should == 1 rspec
Relative to the TDD, these are not exactly a revolutionary breakthrough. But the idea of change, allowing you to develop more smoothly.
First you can start in the design of writing the test code, after the development of the documentation generated by rspec to quickly browse all the features you are finished. These properties make the test-driven development can be more easily extended. From my work experience, for various reasons (such as no iteration cycle, the lack of code review system, there is no fixed target …), all the coverage requirements of the test code written very little. Help in rspec, rspec-generated documents directly to see urge everyone can make the whole test.
Sorry, the comment form is closed at this time.
Comments
No comments yet.