Changes between Version 37 and Version 38 of ProgrammingGuidelines


Ignore:
Timestamp:
07/12/11 16:21:46 (8 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProgrammingGuidelines

    v37 v38  
    147147=== Testing guidelines === 
    148148 1. Test cases should be simple. Reduce complexity in setup with generic setup functions and/or @Before. Reduce checking complexity and clarity with custom asserts. Avoid using conditional branches in tests cases. 
    149  1. Unit tests should be stand alone. If possible, don't use files, the network, databases and don't share data between test cases. Mockups/stubs/null objects can help here. 
     149 1. Unit tests should be stand alone. If possible, don't use files, the network, databases and don't share data between test cases. Mockups/stubs/null objects can help here. 
    150150=== Test class naming scheme === 
    151151Tests classes end with {{{Test}}}, integration test classes end with {{{IntegrationTest}}}, Abstract test classes start with {{{Abstract}}} (and end with {{{Test}}}). This differentiation between integration tests and unit tests allows us to use a quick health check of the code, running only the unit tests. 
     
    157157}}} 
    158158Does not communicate the values of expected and actual if an error occurs. One 
    159 solution is to use the string description of the assert. 
     159solution is to use the string description of the assertTrue: 
    160160{{{ 
    161161assertTrue(expected + "<>" + actual,expected==actual) 
     
    167167}}} 
    168168will give you information on actual and expected values if the assert fails. You 
    169 can write your own asserts for custom data types. Some HMI specic asserts 
     169can write your own asserts for custom data types. Some HMI specic asserts 
    170170(for example to assert Quat4f or Vec3f equality) are stored in HmiTestUtil. 
    171171[[ViewTopic()]]