What a data-driven test means:
The explanation on the Baidu Encyclopedia is:
Data-driven testing, the black box test (Black-box testing), also known as functional testing, is the test object as a black box. When using the Black box test method for dynamic testing, it is necessary to test the function of the SOFTWARE product without testing the internal structure and process of the SOFTWARE PRODUCT. Data-driven testing focuses on the functional requirements of testing software, which means that data-driven testing enables software engineers to derive input criteria for all functional requirements of the program.
The explanations on the Microsoft website are:
A data-driven unit test is a unit test that runs repeatedly for each row in the data source.
A common scenario for data-driven unit testing is to test the API with multiple input values. Instead of writing multiple unit tests that call the API (each with a new set of inputs), or creating an array in a unit test and using loop code, you can write a single unit test method that executes the API. You can then retrieve the data from the rows of the database table in order to pass successive calls to the test method. You can use this technique to test applications that are used by different users (each user has a different role). For each user, a row in the data source indicates the expected response based on the role. The test will then test the application by running the feature against each user and verify that the resulting response is consistent with the expected response.
In the test work, for an API interface, or a user interface input box, you need to design a large number of related use cases, each use case contains the actual input of the various possible data. The usual practice is to store the test data in a data file, read from the data file, loop through the test data in the script, and validate the results. The implementation, as explained by the Microsoft Web site, does not belong to data-driven testing. So what is data-driven testing? Next we look at an example, it is clear.
Environment readiness for data-driven testing:
The UnitTest framework consists of a test fixture,test Fixture consisting of three parts, Setup,testcase and teardown. The setup process is the initialization process before the test case executes, the teardown process is the process of releasing and reclaiming the resources after the test case executes, and TestCase is the specific test case.
- The introduction of the DDT framework requires the installation of DDT modules from the DDT website. After installing the DDT module, using a test-driven framework requires only the following lines of code:
Import Unittestimport ddt@ddt.ddtclass mytestcase (unittest. TestCase): def setUp (self): ' TestCase init ... : return: ' print (' setUp ') @ Ddt.data ([' T1 ', ' R1 '], [' T2 ', ' R2 ']) @ddt. Unpack def test_sth (self, TestData, Expectresult): " C12/>must use test_*** : return: ' Print ( ' Test something ') print (Colored ('%s-%s '% (TestData, Expectresult), ' Blue ') def TearDown (self): "' testcase release ... : return: ' Print (' teardown ') print () if __name__ = = ' __main__ ': unittest.main ()
First, DDT was introduced in the head, followed by the use of DDT (@ddt. DDT) before the test class; The third step is to use @ddt.data and @unpack to decorate before testing the method. And the test data, in the database to fill in, the demo, there are two test data, each measured data has two fields, the first one is the test data, the second is the desired test results. From the code, you can see that we are not using loops in the entity of the test case. So what's the effect after the execution?
Setuptest Somethingt1-r1teardown.setuptest SOMETHINGT2- R2teardown.----------------------------------------------------------------------Ran 2 tests in 0.000sOK
As you can see, the test results have two test cases executed, not one test case. The test framework, which automatically scores the test data in two test cases. By debugging the print statement, we can also see the output of the two use cases when they are executed.
Examples of data-driven tests:
Above, we introduce the use of data-driven, and then we'll look at how it's applied at work. Current data-driven, is used in the Search app automated test execution process. The application of the scene is that the test needs to open in the app different vertical search, and verify that the corresponding vertical search page is open normally, at this time need to pass in two fields, one is the name of the search, and the second is to open the search page, the special logo, in this, we choose the HTML5 page XPath. The specific code examples are as follows:
Before the data-driven framework was used, each vertical search implemented a single test case, which had 18 vertical searches, so that the previous 18 test cases had a high amount of duplicated code. With a data-driven framework, you only need to implement one test case to meet your requirements, and you will write a low amount of code. With regard to data-driven, there are many other solutions on the web, such as writing test data to excel and reading data from Excel. And this process, you need to write a certain code, the use of the framework, completely eliminate the process.
import unittestfrom DDT import DDT, data, Unpackimport Csvfrom Pprint Import pprintdef Add (A, B): Print (' * ', A, b) C = a + b print (' C ', c) return Cdef Addstr (A, b): c = A + B return cdef get_csv_data (): Value_rows = [] with open ('./mfile.csv ') as F:f_csv = Csv.reader (f) # Ignore table header next (f_csv) for R in F_csv:value_rows.append ([Int (i) for I in R]) Pprint (Value_ro WS) return Value_rowsdef Write_csv_data (): Pass@ddtclass Test (unittest. TestCase): @data ((1, 1, 2), (1, 2, 3)) @unpack def test_addnum (self, A, B, expected_value): self.assertequ Al (Add (A, b), Expected_value) @data (*get_csv_data ()) @unpack def test_addstr (self, A, B, expected_value): Self.assertequal (Add (A, b), expected_value) if __name__ = = "__main__": Suite = unittest. Testloader (). Loadtestsfromtestcase (Test) unittest. Texttestrunner (verbosity=2). Run (Suite)
What it means to use a data-driven framework:
-High code reuse rate. The same test logic is written once, can be reused by multiple test data, improve the reuse rate of test code, and can improve the efficiency of writing test scripts.
-High efficiency of abnormal troubleshooting. The test framework generates one test case per data based on the test data, and the use case execution is isolated from each other, without affecting the other test cases in the case of one failure.
-The code is highly maintainable. The clear testing framework facilitates reading by other test engineers and improves the maintainability of the code.
Python data-driven unittest + DDT