Changes between Version 36 and Version 37 of ProgrammingGuidelines


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

--

Legend:

Unmodified
Added
Removed
Modified
  • ProgrammingGuidelines

    v36 v37  
    143143software you want to redirect logs from software which has few log statements at performance critical places (this holds for odejava). 
    144144 
    145  
     145== Unit and integration testing == 
     146Elckerlyc uses the [[http://www.junit.org/|JUnit]] framework for its automatic testing.  
     147=== Testing guidelines === 
     148 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. 
     150=== Test class naming scheme === 
     151Tests 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. 
     152=== Test assertions === 
     153Use assertions, that, when they fail communicate the failure as clearly as possible. If your test case is full of {{{System.out.println's}}} (or log messages), this is an indication of the assertions not being clear enough.  
     154For example: 
     155{{{ 
     156assertTrue(expected==actual) 
     157}}} 
     158Does not communicate the values of expected and actual if an error occurs. One 
     159solution is to use the string description of the assert. 
     160{{{ 
     161assertTrue(expected + "<>" + actual,expected==actual) 
     162}}} 
     163But, ofcourse we're lazy and we don't want to write error messages with each 
     164assert. Custom asserts in JUnit or other libraries can help us. For example: 
     165{{{ 
     166assertEquals(expected,actual) 
     167}}} 
     168will give you information on actual and expected values if the assert fails. You 
     169can write your own asserts for custom data types. Some HMI specic asserts 
     170(for example to assert Quat4f or Vec3f equality) are stored in HmiTestUtil. 
    146171[[ViewTopic()]] 
    147172!^[[ElckerlycDocumentation]]