Until finally eleven, I have time to write a blog, ready to take advantage of these eleven days vacation to finish this series of blog
This series of articles I intend to write three blog
First: introduce automated testing framework python unittest
The second: The django framework library that implements the interface test + request
Part III: The use Jenkins to achieve continuous integration
Today into the first chapter, unittest framework introduced
A, unittest brief
unittest is a unit testing framework python language in official documents in python, unit testing framework for unittest a detailed introduction, interested readers can go to https://www.python.org/doc
website to understand; Benpian application blog focuses on unittest unit testing framework in automated test
unittest Unit testing framework provides a way to create test cases, test suites, and batch execution of test cases, after the python installation is successful, unittest unit testing framework can be used directly import, he belongs to
the python standard library; as a unit testing framework, unittest an agile testing framework of the test unit but also to the minimum module proceedings. In the automated test i in, although we do not need to do white-box testing,
but you must know the language used in unit testing framework, it is because the back of our test cases will encounter problems with the organization, although the object-oriented programming and functional programming providing reconstruction of the code, but for the
each test preparation, it is impossible to write a function to invoke execution; frame using the test unit, can create a class that inherits the unittest TestCase, so that each can TestCase seen as
a minimum unit, organized by the test suite, the runtime can be directly executed, but may be introduced into the test report. If the relationship between the various components unittest
TestCase -------------------------------> TestFixture (test firmware)
|
|
|
|
|
|
|
|
|
TestSuite (test kit) -----------------------> TestRunner (test execution) ------------------- -> TestReport (test report)
TestCase #
# class must inherit unittest.TestCase
# class inherit a class unittest.TestCase, it is a test case. Examples of a TestCase is a test case, it is a complete testing process.
# Including former test environment preparation setUp () | setUpClass (), execute code run (), tearDown reduction after testing environment () | tearDownClass ().
# Unittest.TestCase inherited from class, the name of the test method should start with test. And only the execution method (test case) to the beginning of the test definition.
Second, the test firmware (TestFixture)
In the framework of the test unit unittest, test firmware for processing operation is initiated, for example, prior to testing Baidu search, first need to open a browser and enters Baidu home; end of the test,
the need to close the browser; tests mentioned firmware Oh features two forms of execution, each one is a test case execution, test firmware will be executed once; it is another matter how many use cases i, test firmware will execute
the line again
# Prepare for a test environment and destruction of reduction.
# Before each execution of test cases need to prepare for the test environment, test after each test is completed to restore the environment, such as a database connection before performing, open the browser, etc., need to restore the database after the execution is complete, close the browser and other operations.
# This time you can enable testfixture.
# SetUp (): Prepare the environment, performing pre-conditions for each test case;
# the tearDown (): reducing environment, performing post-conditions for each test case;
# setUpClass (): @classmethod must decorator, all case execution of pre-conditions, run only once;
# tearDownClass (): You must use @classmethod decorator, all case run after run only once;
1, the test firmware each time execution
unittest Unit testing framework provides testing of the firmware called setUp the tearDown. Let's look at an example by writing test firmware implementation, test code as follows
Import. 1 the unittest
2
. 3 class Test1 (of unittest.TestCase):
. 4
Preconditions # 5 of the test fixture
. 6 DEF the setUp (Self):
. 7 Print ( "It is a precondition" ) 8 after Test # 9 firmware-conditions 10 def the tearDown (Self): . 11 Print ( "it postcondition" ) 12 is 13 is DEF test_case1 (Self): 14 Print ( "test_case1" ) 15 16 DEF test_case2, (Self):. 17 Print ( "test_case2," ) 18 is. 19 20 is IF == the __name__ '__main__' : 21 is unittest.main (the verbosity = 2)
Execution results are as follows
His execution order is performed setUp method, performed by a particular embodiment, the method performed last tearDown
2, the test is performed only once firmware
Although the setUp and tearDown hooks are often used, but in automated testing, a test system up to thousands, performed once every setUp and tearDown methods will spend a lot of performance,
in the framework of the test unit unittest also be Another test using firmware to solve this problem, he is setUpClass and tearDownClass method, the test firmware method is a class method, the method requires
surface plus decorators @classmethod, using the test firmware, no matter how many use cases, test firmware is performed only once, specific code as follows
Import. 1 the unittest
2
. 3 class Test1 (of unittest.TestCase):
. 4 # DEF the setUp (Self):
. 5 # Print ( "It is a precondition")
. 6 #
. 7 # DEF the tearDown (Self):
. 8 # Print ( "It is postcondition ")
. 9
10 @classmethod
. 11 DEF setUpClass (CLS): 12 is Print (" it is a precondition class method " ) 13 is 14 @classmethod DEF 15 tearDownClass (CLS): 16 Print (" this is the opposite method of the class conditions " ). 17 DEF 18 is test_case1 (Self): Print. 19 (" test_case1 " ) 20 is DEF 21 is test_case2, (Self): 22 is Print (" test_case2, " ) 24 25 IF 23 is the __name__ == '__main__' :26 unittest.main(verbosity=2)
The results are as follows
3, the coexistence of two test firmware
Import the unittest
class Test1 (of unittest.TestCase):
DEF the setUp (Self):
Print ( "It is a precondition" )
DEF the tearDown (Self): Print ( "It postcondition" ) @classmethod DEF setUpClass (CLS): print ( "this is the precondition class method" ) @classmethod DEF tearDownClass (CLS): print ( "this is a class method postcondition" ) DEF test_case1 (Self): print ( "test_case1" ) DEF test_case2, (Self): Print ( "test_case2," ) IF the __name__ == '__main__' : unittest.main (the verbosity = 2)
Execution results are as follows
The results showed that the first execution is @classmethod decorator decoration test firmware, in performing common test firmware
Third, test execution
In the above case, a test is performed can be seen in the main function, the unittest is called main, the following code, TestProjram or a class, then look class constructor, as follows
= main test program
TestProjram or a class, then look class constructor, as follows
class TestProgram(object):
"""A command-line program that runs a set of tests; this is primarily
for making test modules conveniently executable.
"""
# defaults for testing
module=None
verbosity = 1
failfast = catchbreak = buffer = progName = warnings = None
_discovery_parser = None
def __init__(self, module='__main__', defaultTest=None, argv=None, testRunner=None, testLoader=loader.defaultTestLoader, exit=True, verbosity=1, failfast=None, catchbreak=None, buffer=None, warnings=None, *, tb_locals=False): if isinstance(module, str): self.module = __import__(module) for part in module.split('.')[1:]: self.module = getattr(self.module, part) else: self.module = module if argv is None: argv = sys.argv self.exit = exit self.failfast = failfast self.catchbreak = catchbreak self.verbosity = verbosity self.buffer = buffer self.tb_locals = tb_locals if warnings is None and not sys.warnoptions: # even if DeprecationWarnings are ignored by default # print them anyway unless other warnings settings are # specified by the warnings arg or the -W python flag self.warnings = 'default' else: # here self.warnings is set either to the value passed # to the warnings args or to None. # If the user didn't pass a value self.warnings will # be None. This means that the behavior is unchanged # and depends on the values passed to -W. self.warnings = warnings self.defaultTest = defaultTest self.testRunner = testRunner self.testLoader = testLoader self.progName = os.path.basename(argv[0]) self.parseArgs(argv) self.runTests()
main methods included in the unittest module, the test module can easily be transformed into test scripts can be run. Use unittest.TestLoader main class to automatically find and load the test within the module, TestProgram class code as the portion of
def createTests(self):
if self.testNames is None:
self.test = self.testLoader.loadTestsFromModule(self.module)
else:
self.test = self.testLoader.loadTestsFromNames(self.testNames,
self.module)
When performing the test, added to the verbosity = 2 in the main process, as follows
if __name__ == '__main__':
unittest.main(verbosity=2)
The following section explain verbosity, default verbosity is the total number of test results and the overall execution of 1.0 representatives, detailed information on behalf of 2
Fourth, the test suite, TestSuite
TestSuite #
# above simple test will have two questions, can you control the order of execution of test cases test? If do not want to execute a test case, there is no way to skip?
# For the order of execution, the default, in accordance with the method az AZ test of. To perform the use case has relations by themselves prepared, we need to use testSuite.
# Multiple test cases together, perform together, is testSuite. testsuite may also contain testsuite.
# Generally added to the suite by addTest () or addTests (). the execution order and added to the case in order Suite is consistent.
1, direct execution case
We define addition, subtraction four test functions in this file func.py
#Auther Bob
#--*--conding:utf-8 --*--
def add(a,b):
return a + b
def minus(a,b):
return a - b
def multi(a,b):
return a * b def divide(a,b): return a / b
Then define our test code myunittest.py file used here assertion, we will be back on
from test1 import func
class Test2(unittest.TestCase):
def setUp(self):
print("前置条件")
def tearDown(self):
print("后置条件") def test_add(self): self.assertEqual(3,func.add(1,2)) def test_minus(self): self.assertEqual(4,func.minus(5,1)) def test_multi(self): self.assertEqual(4,func.multi(2,2)) def test_divide(self): self.assertEqual(10,func.divide(100,10)) if __name__ == '__main__': unittest.main(verbosity=2)
Execution results are as follows
2, add the case to a test suite
Above simple test will have two questions, can you control the order of execution of test cases test? If do not want to execute a test case, there is no way to skip?
For the order of execution, the default, in accordance with the method az AZ test of. To perform the use case has relations by themselves prepared, we need to use testSuite.
The multiple test cases together, perform together, is testSuite. testsuite may also contain testsuite.
Is generally added to the suite by addTest () or addTests (). the execution order and added to the case in order Suite is consistent.
If you use the test suite TestSuite, you'll need to write test code, But do not execute
we also define our test code myunittest.py file
from test1 import func
class Test3(unittest.TestCase):
def setUp(self):
print("前置条件")
def tearDown(self):
print("后置条件") def test_add(self): self.assertEqual(3,func.add(1,2)) def test_minus(self): self.assertEqual(4,func.minus(5,1)) def test_multi(self): self.assertEqual(4,func.multi(2,2)) def test_divide(self): self.assertEqual(10,func.divide(100,10))
We introduced a test case in test_suit.py file, and then add the test to the test suite TestSuite class method by addTests
Import the unittest
from test1.myunittest Import the Test3
# Import from the Test3 test1.myunittest2 T3 AS
IF the __name__ == '__main__' :
# output to the console
# instantiate a class TestSuite
Suite = unittest.TestSuite ()
# cases to be executed in a list in tests = [the Test3 ( "test_add"), the Test3 ( "test_minus"), the Test3 ( "test_multi"), the Test3 ( "test_divide" )]
# added to instantiate good test case suite suite. addTests (tests) # t = [ t3 ( "test_add"), t3 ( "test_minus"), t3 ( "test_multi"), t3 ( "test_divide")] # suite.addTests (tests) # instantiates a parameter execution class = Runner (unittest.TextTestRunner the verbosity = 2 ) # test execution instance of the class execute a test suite runner.run (suite)
We are adding more case file of a test case, we can also add multiple files in case of a test suite, then you can perform this test suite
Import the unittest
from test1.myunittest Import the Test3
from test1.myunittest2 Import the Test3 T3 AS
IF the __name__ == '__main__' : # output to the console
# instantiate a class TestSuite Suite = unittest.TestSuite ()
# cases need to perform the discharge in a list of tests = [the Test3 ( "test_add"), the Test3 ( "test_minus"), the Test3 ( "test_multi"), the Test3 ( "test_divide" )] # cases to add a good example of a test suite suite.addTests (tests) # add another test case file to the test suite = t [T3 ( "test_add"), T3 ( "test_minus"), T3 ( "test_multi"), T3 ( "test_divide" )] suite.addTests (t) # instantiates a parameter execution class = Runner (unittest.TextTestRunner the verbosity = 2 ) # test execution instance of the class execute a test suite runner.run (suite)
The above implementation is the output to the console, we can also export the results to a file
import unittest
from test1.myunittest import Test3
from test1.myunittest2 import Test3 as t3
if __name__ == '__main__':
# 输出信息到txt文件中
suite = unittest.TestSuite()
tests = [Test3("test_add"), Test3("test_minus"), Test3("test_multi"), Test3("test_divide")] suite.addTests(tests) t = [t3("test_add"), t3("test_minus"), t3("test_multi"), t3("test_divide")] suite.addTests(t) with open('UnittestTextReport.txt', 'a') as f: runner = unittest.TextTestRunner(stream=f, verbosity=2) runner.run(suite)
3, the test class is added directly to the test suite
Add a case of a quite troublesome, we can directly add a test class to test suite
Using the following test method of loading a class
unittest.TestLoader().loadTestsFromTestCase(t3)
Import the unittest
from the unittest Import TestLoader
from test1 Import myunittest
from test1.myunittest2 Import the Test3 T3 AS
IF the __name__ == '__main__' : Suite = unittest.TestSuite () = Loader TestLoader () = test_cases1 . unittest.TestLoader () loadTestsFromTestCase (T3) # is a class parameter, and this must be the class or subclass unittest.TestCase Sun class suite.addTests (test_cases1) = unittest.TextTestRunner Runner (the verbosity = 2 ) runner.run (Suite)
4, a module loaded directly into the test suite, if there is more than one class of this module will be the test case for all classes loaded into the test suite
unittest.TestLoader().loadTestsFromModule(myunittest)
Import the unittest
from the unittest Import TestLoader
from test1 Import myunittest
from test1.myunittest2 Import the Test3 T3 AS
IF the __name__ == '__main__' : Suite = unittest.TestSuite () = Loader TestLoader () = test_cases1 . unittest.TestLoader () loadTestsFromModule (myunittest) # is a parameter module, this module will load all incoming case suite.addTests (test_cases1) = unittest.TextTestRunner Runner (the verbosity = 2 ) runner.run (Suite)
I will give you a look at the screenshot
5, case by case name added to the test suite
test_cases1 = unittest.TestLoader().loadTestsFromName('test1.myunittest2.Test3.test_minus')
import unittest
from unittest import TestLoader
from test1 import myunittest
from test1.myunittest2 import Test3 as t3
if __name__ == '__main__':
suite = unittest.TestSuite() loader = TestLoader() test_cases1 = unittest.TestLoader().loadTestsFromName('test1.myunittest2.Test3.test_minus') # 加载某个cese runner = unittest.TextTestRunner(verbosity=2) suite.addTests(test_cases1) runner.run(suite)
I give you a look at the directory structure Screenshot
Fifth, ignoring case execution
In the actual project, some cases we may need to perform temporarily, if there is such a problem, how can we do, unittest framework has provided a solution for our
1, unconditionally skip this case, the modified case to be executed by the decorator, the case will be ignored does not perform
@unittest.skip("do not exec")
unittest.skip @ ( "do Not Exec" )
# unconditionally skips execution of the case
DEF test_add (Self):
self.assertEqual (. 3, func.add (1,2))
2, a condition is met only skips the case
@unittest.skipIf(4 > 3,"2 > 3 do not exec")
unittest.skipIf @ (4> 3, "2> 3 do not Exec" )
# skip certain conditions are met before execution
DEF test_minus (Self):
self.assertEqual (4, func.minus (5,1))
3, does not meet certain conditions before skipping Case
@unittest.skipUnless(4 < 3,"hahah")
unittest.skipUnless @ (4 <3, "hahah" )
# does not meet certain conditions before skipping execution
DEF test_multi (Self):
self.assertEqual (4, func.multi (2, 2))
4, we can also define ignored in the case of the implementation of this case inside
def test_divide(self):
self.skipTest("wydd")
self.assertEqual(10,func.divide(100,10))
Sixth, the assertion
Assertion is to determine whether the actual test results with the expected results are identical, then the test passes, otherwise fail. Therefore, automated testing, test cases no assertion is invalid, because when a functional automation have all been implemented in each version of the iteration when performing the test case, the results of implementation must be authoritative, that automation test case execution results should be no functional or logical problems in automated testing is the most taboo automated testing use cases, although through, but the function being tested is problematic, often used in automated test cases in regression testing the problem found is not particularly large, there is a problem if the test results on the function of the input parameters of automated manpower to do it does not mean much, so each test case must be asserted; the results of the tests, only two possible, one is performed by, another is failed, i.e. a functional problem, a method is provided in assert TestCase class to check and report a failure, common methods include
self.assertEqual (. 3, func.add (1,2 ))
# determines whether or equal
self.assertNotEqual ()
# determines whether or not equal
self.assertTrue ()
# determines whether a Boolean True self.assertFalse () # Analyzing Boolean whether False self.assertIs () # determines whether or not the same type self.assertIsNot () # determines whether different types self.assertIsNone () # determines whether None self.assertIsNotNone () # determines whether or not None self.assertIn () # is determined within a certain range self.assertNotIn () # determines whether or not a range self.assertIsInstance () # determines whether an instance of a class self.assertNotIsInstance ()