Unit Test Module Interface test

Unit testing is the most important tool for code correctness verification, and is the most important part of system testing. is also the only test method that requires code to be written for testing. In the standard development process, the Code of the Unit test is of equal importance to the code of the actual program. Each unit test is used to target the correct data for the corresponding unit of the test.

Unit testing has a few benefits

1, can assist the programmer to find the specific location of the bug as soon as possible 2, can let the programmer more confidence in their own program 3, can let the programmer before submitting the project to become more robust 4, can help programmers to develop a better 5, can show other programmers how to call your program Ii. unit testing tasks include 1. Module Interface Test The following factors should be considered when testing the interface correctly(1), the actual parameters of the input and the number of formal parameters are the same;
(2), the actual parameters of the input and the properties of the formal parameters are matched;
(3), the actual parameters of the input and the dimension of the formal parameters are consistent;
(4), when invoking other modules, the number of actual parameters is the same as the number of parameter of the module;
(5), when invoking other modules, the properties of the actual parameters are matched with the parameter attributes of the modulated module;
(6), when invoking other modules, the dimension of the actual parameter is consistent with the shape parameter of the module;
(7), the number of parameters used to invoke the predefined functions, the attributes and the order is correct;
(8) Whether there are parameter references unrelated to the current entry point;
(9), whether to modify the read-only parameters;
(10), the definition of the whole variable is the same as the module;
(11), whether to pass some constraints as parameters. (12), whether the document has been opened before use;
(13), whether to deal with the end of the document;
(14), whether to handle the input/output errors;
(15), the output information whether there is a textual error;
2. Module local data structure testThe local data structure is checked to ensure that the information stored temporarily in the module is complete and correct during the execution of the program. Local data structures are often the source of errors, and test cases should be carefully designed The following factors should be considered(1), inappropriate or incompatible type description;
(2), the variable has no initial value;
(3), variable initialization or the error of the default value;
(4), incorrect variable name (misspelled or improperly truncated);
(5), overflow, underflow, and address anomalies.
3. All independent test execution in the module The following factors should be considered(1), misunderstanding or using the wrong operator priority;
(2), mixed type operation;
(3), variable initial value error;
(4), the accuracy is not enough;
(5), the expression symbol is wrong. (6), the comparison between objects of different data types;
(7), using logical operators or precedence incorrectly;
(8), due to the limitations of the computer representation, the expectation is equal in theory and in fact unequal two quantities;
(9), comparison operation or variable error;
(10), cyclic termination conditions or impossibility of appearing;
4, the module error handling test The following factors should be considered(1), the output error information is difficult to understand;
(2), the error recorded is not in accordance with the actual errors encountered;
(3), the system has been involved before the program's custom error-handling section runs;
(4), improper handling of abnormal;
(5), Error statement failed to provide sufficient location error information.
Three, the commonly used test method 1. Test ExceptionIt is possible to test the method directly or to test the simulated object abnormally, but it is seldom used to test the simulated object, so the anomaly test of the method is introduced here. Consider the following code, which throws an exception when the user name is empty. For exampleC # codeCopy

public bool Valid (string userName, String PassWord)

   {       if (string. IsNullOrEmpty (UserName)) throw new ArgumentNullException ("UserName is null");       var IsValid = UserName = = "Admin" && PassWord = = "123456";       Log.write (userName);       return isValid;   }

The test code is as follows

C # codeCopy

[Test]

[ExpectedException (typeof (ArgumentNullException))]

public void Vaild_throw_test ()

  {      MyLogin L = new MyLogin ();      L.valid ("", "123456");  }

The feature "ExpectedException" is required here, meaning that an exception is expected to be thrown. There is no need to assert again, and after throwing an exception, the subsequent code will not execute.

2. Test return value

This is mainly about testing the return value of the mock object. Here is a Lastcall class, more commonly used, some of the functions of the auxiliary test, are in this class.

The test code is as follows

C # codeCopy

[Test]

public void Valid_return ()

{    mockrepository mock = new Mockrepository ();    var log = mock. Dynamicmock<ilog> ();    using (mock. Record ())    {        log. Writelog ("admin");        Lastcall.return (0);    }    var returnvalue = log. Writelog ("admin");    

3. Test the parameter passing of a simulated object

When invoking a mock object, it may be necessary to pass parameters, and if the values of the parameters are different, it will cause the test to fail, for example: I need to pass a string containing a guid+username, where the GUID may not be emulated, so, when testing the parameters, You just need to test username.

The method code is as follows:

C # codeCopy

    public bool Valid_paramter (string userName, String PassWord)

    {        log.write (guid.newguid () + userName);        return userName = = "Admin" && PassWord = = "123456";    }

The test code is as follows:

C # codeCopy

[Test]

public void Valid_paramter ()

{     mockrepository mock = new Mockrepository ();     var log = mock. Dynamicmock<ilog> ();     using (mock. Record ())     {         log. Write ("admin");         Lastcall.constraints (Rhino.Mocks.Constraints.Text.Contains ("admin"));     }     MyLogin login = new MyLogin ();    Login. log = log;    var valid = login. Valid_paramter ("admin", "123456");    Assert.AreEqual (valid, true);    Mock. Verifyall (); }

Unit Test Module Interface test