Nodejs Learning notes test driver _node.js

Share chapter Two, about test drivers. The test here is primarily for web backend testing-Why do you write test cases (that is, if test case refinement is a waste of time), how to refine your test cases, how code design simplifies the writing of test cases, and some later ideas.

1. Why do you write test cases

This habit is often thought of as an act of delaying development, and you need to spend almost the same amount of time developing your code to gradually refine your test case. But in the development process, when the development of the completion of a piece of code, if responsible rather than the complete problem to the tester to find out, this time will usually do some manual tests. For example:

Perform certain methods in your code to see if the output values are as expected.
Modify the database/cache, and then execute some methods to see if the database changes are expected.
Use tool emulation to request some interfaces to see if the return value of the interface/database change is expected.
If there is a front-end page, it will also involve the front and back end of the joint, that is, the front-end page through the front-end interaction, to see whether the front-end feedback to meet expectations, to indirectly verify the correctness of the backend code.
Modern test tools are trying to abstract these manual test behaviors into pieces as much as possible, and when you are conscious of doing manual testing, you are actually beginning to try to test the behavior of the use cases. Since you can test it manually, why do you need to use code to implement the test?

Code can be reused or more functionality can be achieved after simple refactoring, but when you choose to manually, each time you need to start over.
A mature workflow should include a code review process, a number of ways to audit your code, read your code step by step, or check the integrity and correctness of your test code, and then run your test cases. The latter is much simpler.
When code changes, such as fixing bugs, it's hard to guarantee that your changes will affect other parts of your code that depend on you. In the era of manual testing there is a regression test, which is to test your system again after you fix the Bug. But if you already have a perfect test case, just execute the command to get it done.
When you refactor the code, ditto.

2. How to improve your test cases

Before you go into the perfect phase, tell me how you will implement the test case.

Describe Meme do

 before does
  @meme = meme.new
 end

 describe "when asked about Cheeseburgers" do
  it "must Respond positively "
   do @meme. I_can_has_cheezburger? Must_equal "ohai!"
  End

 -describe "when asked about blending possibilities" does
  it "won ' t say no" do
   @meme. will_it_blend ?. Wont_match/^no/i end end

The code above comes from Ruby's minitest. Before contains code blocks that are to be done before executing the following test cases, and typically support a corresponding method that executes after the test case. There are a few small judgments in each use case.

The first paragraph mentions some of the tests that are often involved in manual tests, with 2 and 3 of them described here. When you perform database-related tests, you need to insert a test data into the before and delete the test data in after. In the intermediate test case, by executing the appropriate method, after execution: Check the data changes/check for expected exceptions/return expected results to confirm the correctness of the code. If it is an interface, it is through the code to initiate the corresponding request, and then check whether the returned content returned to the expected, if necessary, to see if the data in the database to meet the expected changes.

There are now test cases, but there is a special case that needs to be considered. I now write a relatively perfect test case for a function, ran all pass, and found that the online log there is still a function of the error. Check the discovery of a branch of the function before the test is not tested, just a certain situation on the line to run to this branch, the result of a very obvious syntax error errors, there is no way to ensure that all the code has been tested? What needs to be introduced here is a concept called test case coverage, and basically every language will have a response implementation. Through test case coverage, quantify how your test cases run out of all the code in So-and-so files, and what you need to do is to keep your coverage as close to 100% as possible.

In a sense, test cases and test coverage are tools used to improve the confidence of developers in their own code. However, they are not omnipotent. The likelihood that some parameters may be omitted from the test case of course, there is no code for this possibility in your code, the final test case coverage can only tell you that you write the code we have to help you tested the test, for you do not take into account the possibility, expressed powerlessness. So write strict code as much as possible in JavaScript, such as using = = = instead of = =, using strongly typed programming specifications, and so on, which reduces the potential risk associated with too much of the accepted parameter range.

3. How code design simplifies the writing of test cases

The entire web (and not limited to the Web) usually includes three levels of code-pure data processing and computing, involving databases, and specific network protocols. One of the simple data operations in the processing of ordinary operations or other code, involving the database is the traditional sense of MVC inside the M, involving specific network protocol is corresponding to C. These three-block tests correspond to the first three of the regular test content in section one.

Because the C level is usually also related to page rendering and the corresponding protocol simulation, so usually the focus of the test on the function and database-related code can reduce the complexity of test case code, which requires Controller code as little as possible. Some current recommendations for higher-complexity applications:

The base checksum of the data is placed on the M layer, and ActiveRecord and mongoid provide a handy validation feature if you are developing it using Ruby.
Try to use the pub/sub pattern in your code to match some of the hooks provided in the ORM to achieve communication between model. For example, when a message is posted when a is created, B changes one of his own property values after hearing the message.
Use Command mode to extract some business-independent features from the system, such as sending mail.
Reference to the above suggestions: Laravel wisper resque

4. Conception

The above content avoids the front and back end need to adjust the test case, the following content is mainly for this piece. Ruby has some more elegant implementations in this direction, and it's interesting to see the capybara directly first.

With the popularity of a range of browser drivers, including Selenium Phantomjs and Watir based on the former, using code-controlled browsers is no longer a complicated matter. On the basis of this ability, you can try to divide the test based on the front-end into four steps:

Wait for a sign element to appear (for example, wait for the page to load to play, or a content to appear asynchronously)
Simulate user actions, where operations include and are not limited to user clicks, user input
Waiting for feedback in the presence of the iconic element (e.g., a certain input box appears)
Determine whether the content is in line with expectations
Based on this process, most front-end tests can be solved. However, simply relying on this process is not enough, because the page may appear such as the verification code blocking elements, without modifying the code, you can try to access the content through the database/cache. Similarly, as with the Test interface, it also involves inserting test data into the database before the test, the data changes in the critical database after the test case is executed, and deleting the test data after all the tests have been completed. Ultimately, the implementation of this test case code requires a certain understanding of the front-end backend. At present, the design of a more general scheme is also considered on the basis of drawing on the capybara.

End up with a section of Capybara code:

Feature "Signing in" does
 background do
  user.make (: Email => ' user@example.com ',:p assword => ' Caplin ')
 End

 scenario "signing in with correct credentials" does
  visit '/sessions/new ' within
  ("#session") do
   fill _in ' Email ',: With => ' user@example.com '
   fill_in ' Password ',: With => ' Caplin '
  end
  Click_button ' Sign in '
  expect (page). To Have_content ' Success '
 end

 given (: Other_user) {user.make (: email => ' Other@example.com ',:p assword => ' Rous ')}

 scenario "Signing in as another user" do
  visit '/sessions/new ' 
   within ("#session") do
   fill_in ' emails ': with => other_user.email
   fill_in ' Password ',: With => Other_ User.password
  End
  Click_button "Sign in"
  expect (page). To Have_content ' Invalid email or password ' End End