How are interface tests generally tested? Interface testing-what does mock testing look like?

1. What is an interface

Before discussing why we need to do interface testing, we can first understand a little bit about what an interface is?

The interface can be very inaccurately understood as dealing with resources. This resource may belong to this system or other systems.

For example, if we are developing a bug management system, the system needs to obtain the information of all developers and testers in the company, so that developers and testers can log in without registering. This should be easy to understand.

So where is the information about these people stored? Generally stored in the HR system. Now the demand is more clear. We need to go to the HR system to get personnel information and personnel resources in the HR system.

How to get it? There are many ways to directly copy the database of the HR system and put it into the bug management system, but this is not good because data synchronization will be a bit troublesome; you can also directly connect to the database of the HR system to check, which is not good either. , so we need to understand the data storage structure and logic of the hr system. Once the data fields of the hr system change, the bug management system will also need to do so for synchronization.

A better approach is for the HR system to expose some interfaces and obtain personnel information resources through these interfaces, so that the bug system does not need to care about the data storage implementation of the HR system.

  • These interfaces may be like this: login interface, provide the user name and password of the person, go to the HR system to determine whether the person exists, if there is a verification user name and password, if the verification is passed, a token will be returned, and the token belongs to this person Pass, you can log in to the bug management system through token;
  • The interface for obtaining personnel information returns the position of the personnel: testing or development, as well as user name, nickname and other information;

In summary: Interfaces can be understood as the means of resource exchange between different systems or modules;

2. Interface testing is actually black box testing

As a black box test, the basic testing idea is to judge the logic of the system or object under test through input and output.

To obtain the personnel’s information, I need to pass the personnel’s user name to the HR system interface, so that the HR system interface will return to me some more specific information about the user. The input here is the username and the output is the user’s details.

3. Why do we need to do interface testing

Since it is an interface to obtain and operate resources, and in most systems and products, resources are generally the core of the product. For example, the core resources of WeChat are address book relationship chains and chat records, so resources must be tested.

In addition, most of the content in the interface is data. Through data comparison, we can infer the logic of the system and product. Testing the interface is testing the logic.

Finally, the return in the interface is relatively simple. Unlike the web page, there are too many UI things in the HTML code. The UI is the most unstable and changes too fast. The interface is relatively stable, but there is less interference information in it, and it is relatively easy to make assertions. .

4. How to write interface test cases

It’s still the 3a principle, which I mentioned in my previous answer.

  • A: Arrange initializes the test data, which means creating data. The data here includes the data we input, as well as the resources involved in the target interface, such as user information in the HR system. We must first have several pieces of detailed information about personnel before we can test and obtain it. Personnel information interface (of course it is just a normal process, we sometimes need to clear the data to test the situation when the resource is empty);
  • A: act calls the interface and passes in input data;
  • A: assert asserts the returned resource information. For example, after the interface for obtaining user information returns the user information, we need to determine whether the returned user is the user we want. What we obtain is Li Lei’s information. The interface If Han Meimei is returned, then the logic of the interface is wrong;

5. What are the common interfaces

  1. When booking air tickets on Ctrip, air ticket information is generally obtained through the interfaces of major airlines;

  2. Taobao’s logistics information is generally obtained through the interfaces of various logistics companies;

  3. Third-party Weibo clients, individual users’ Weibo and other information are all obtained through the Weibo interface;

6. Common interface testing tools

  • Postman: Recommended. Basic functions are free. The simplest debugging and testing tool based on http interface;
  • jmeter: The post-processor combined with assertions can basically meet the interface testing requirements, but the test report needs secondary development.
  • Code yourself: Recommended. With a testing framework like xunit, it can basically meet all needs;
  • soapui: charged;
  • insomnia: Highly recommended. A weakened version of postman, the basic functions are free. The important thing is that the tool code is open source and you can modify it yourself;
  • paw: Highly recommended. It is the most powerful on Mac, and it seems like a hundred yuan to buy a license from Taobao;

7. mock

1.What is mock

Two systems are jointly debugged. A has completed the development of B. System A can also be tested without B having been developed. Mock data is the interface for simulating system B, allowing for rapid joint debugging.
To be precise: mock is a library in Python used to support unit testing. Its main function is to use mock objects instead of specified python objects to achieve the behavior of simulated objects.
You don’t need to care about the process of how to achieve it, just focus on the results.

2.Mock environment construction

In python3.x, integrated into unittest and imported directly

from unittest import mock
3.Advantages of mock

1. Parallel work: No need to wait for both to be developed, one can be tested after development
2. Simulate inaccessible resources
3. The system is isolated: it constructs virtual post requests and does not pollute the data in the database.
4. Improve coverage: simulate different types such as 500, 400, 301 etc.

4.mock composition

5. Methods in mock
from unittest.mock import Mock
mock_obj = Mock() # Instantiate Mock object
print(dir(mock_obj))
# ['assert_any_call', 'assert_called', 'assert_called_once', 'assert_called_once_with', 'assert_called_with', 'assert_has_calls', 'assert_not_called', 'attach_mock', 'call_args', 'call_args_list', 'call_count', 'called', 'configure_mock', 'method_calls', 'mock_add_spec', 'mock_calls', ' reset_mock', 'return_value', 'side_effect']
6.Construction method in Mock
from unittest.mock import Mock
print(dir(Mock))
# ['_NonCallableMock__get_return_value', '_NonCallableMock__get_side_effect', '_NonCallableMock__return_value_doc', '_NonCallableMock__set_return_value', '_NonCallableMock__set_side_effect', '__call__', '__class__', '__delattr__\ ', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattr__', '__getattribute__', ' __gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__\ ', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_call_matcher', '_extract_mock_name', '_format_mock_call_signature', '_format_mock_failure_message', '_get_child_mock', '_mock_add_spec', '_mock_call', '_mock_check_sig', ' _mock_return_value', '_mock_side_effect', 'assert_any_call', 'assert_called', 'assert_called_once', 'assert_called_once_with', 'assert_called_with', 'assert_has_calls', 'assert_not_called\ ', 'attach_mock', 'call_args', 'call_args_list', 'call_count', 'called', 'configure_mock', 'mock_add_spec', 'mock_calls', 'reset_mock', 'return_value', 'side_effect']

1.name

name:identification of the mock object

from unittest import mock
mock_obj = Mock(name = 'xxx')
print(f'name identification{mock_obj}')
# name identification<Mock name='xxx' id='4445533296'>

2.return_value (most commonly used)

return_value: This parameter specifies a value or object

from unittest import mock
mock_obj1 = mock.Mock(return_value=100)
print(f'return_value specified value{mock_obj1()}')
# return_value specifies the value 100

3.side_effect

side_effect: This parameter points to a callable object (usually a function)
When the mock object is called, if the return value of this parameter is the default DEFAULT, the mock object returns the value specified by return_value;
Otherwise, return the return value of the object specified by side_effect

from unittest import mock
mock_obj2 = mock.Mock(return_value=100, side_effect=None)
print(f'side_effect default value is None, output the value of return_values{mock_obj2()}')
# The default value of side_effect is None, and the value of return_values is 100.
 
mock_obj3 = mock.Mock(return_value=100, side_effect=[200, 300])
print(f'side_effect specifies the value {mock_obj3()}, the value of return_value is overwritten')
# side_effect specifies the value 200, return_value is overwritten
print(f'side_effect iteratively outputs the specified value {mock_obj3()}')
# side_effect iteratively outputs the specified value 300
7.mock assertion

1.assert_called_with()

assert_called_with(parameter arg): Check whether the function call parameters are correct

from unittest.mock import Mock
class Foo(object):
    value=20
    def f1(self, arg):
        return arg
mock_obj = Mock(spec=Foo)
# f1 Correct parameter passing posture
mock_obj.f1(222)
# mock_obj.f1.assert_called_with()
# Report error, no parameters passed
# mock_obj.f1.assert_called_with(11)
# When reporting an error, 222 should be passed, but 11 was passed.
# mock_obj.f1.assert_called_with(222)
# No error

2.assert_called_once_with()

assert_called_once_with(parameter arg): Check whether the function call parameters are correct, but only call it once

from unittest.mock import Mock
mock = Mock()
mock()
mock.assert_called_once_with()
# No error will be reported
mock()
mock.assert_called_once_with()
# AssertionError: Expected 'mock' to be called once. Called 2 times.

Thank you to everyone who read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:

This information should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you!Yes Friends who need it can click on the small card below to get it