Difference between revisions of "QA/test automation rules"

From Apache OpenOffice Wiki
< QA
Jump to: navigation, search
(→‎Best practice rules for JUnit 4)
Line 80: Line 80:
 
</source>
 
</source>
 
'''Rule.''' Avoid too complex test. One test should not contain too many asserts. Consider breaking the test scenario into multiple, shorter test scenarios.  <br />
 
'''Rule.''' Avoid too complex test. One test should not contain too many asserts. Consider breaking the test scenario into multiple, shorter test scenarios.  <br />
−
'''Rule.''' Avoid external dependencies. Others can simply select one test and then run it without extra configurations. e.g. Data file should be placed in the svn with test code, so that newcomers don't need to manually prepare it.<br />
+
'''Rule.''' Avoid external dependencies. Others can run test by a single command or a one button click without extra configurations. e.g. Data file should be placed in the svn with test code, so that newcomers don't need to manually prepare it.<br />
 
''Bad''
 
''Bad''
 
<source lang="java">
 
<source lang="java">
Line 96: Line 96:
 
</source>
 
</source>
 
'''Rule.''' Make test method indepdent, not affect or be affected by others. Test methods can be executed in any particular order. So do necessary setup/teardown in @Before/@BeforeClass/@After/@AfterClass method to avoid side effects.<br />
 
'''Rule.''' Make test method indepdent, not affect or be affected by others. Test methods can be executed in any particular order. So do necessary setup/teardown in @Before/@BeforeClass/@After/@AfterClass method to avoid side effects.<br />
−
'''Rule.''' Don't us random. That makes test uncertain, hard to debug and maintain. Instead of it, prepare enough special test data to cover boundary conditions.<br />
+
'''Rule.''' Log the generated data when you use random. <br />
 
'''Rule.''' Name tests properly. "testLoadFileFromServer" is better than "test".<br />
 
'''Rule.''' Name tests properly. "testLoadFileFromServer" is better than "test".<br />

Revision as of 04:30, 15 August 2012


Best practice rules for JUnit 4

Documentation caution.png MUST READ THE SECTION BEFORE COMMITTING AUTOMATION CODE

Rule. Recommend to follow Java code conventions
Rule. Don't miss assertions. One test method should include at least one assertion, otherwise the test will always pass.
Rule. Use assertions with an informative message.
Bad 

assertEquals(expected , actual);
assertNull(actual);
assertNotNull(actual);
assertTrue(actual);
.

Good 

assertEquals("actual should equals expected", expected , actual);
assertNull("actual should be null", actual);
assertNotNull("actual should not be null", actual);
assertTrue("actual should be true", actual);

Rule. Don't use assertTrue wrongly.
Bad 

assertTrue("actual should be same with expected", expected == actual);
assertTrue("actual should equals expected", expected.equals(actual));
assertTrue("actual should be null", actual == null);
assertTrue("actual should not be null", actual != null);

Good 

assertSame("actual should be same with expected", expected, actual);
assertEquals("actual should equals expected", expected, actual);
assertNull("actual should be null", actual);
assertNotNull("actual should not be null", actual);

Rule. Use assertArrayEquals instead of assertEquals for array data.
Bad 

assertEquals("actual[0] should equals expected0", expected0, actual[0]);
assertEquals("actual[1] should equals expected1", expected1, actual[1]);
assertEquals("actual[2] should equals expected2", expected2, actual[2]);

Good 

String[] expected = {"0", "1", "2"};
String[] actual = someMethod();
assertArrayEquals("actual should equals expected", expected, actual);

Rule. Avoid negation in an assertTrue or assertFalse test.
Bad 

assertTrue("not empty", !r.isEmpty());

Good 

assertFalse("not empty", r.isEmpty());

Rule. Don't catch unexpected exceptions.
Bad 

public void testCalculation() {
    try {
        deepThought.calculate();
        assertEquals("Calculation wrong", 42, deepThought.getResult());
    }
    catch(CalculationException ex) {
        Log.error("Calculation caused exception", ex);
    }
}

Good 

public void testCalculation() throw CalculationException {
    deepThought.calculate();
    assertEquals("Calculation wrong", 42, deepThought.getResult());
}

Rule. Avoid too complex test. One test should not contain too many asserts. Consider breaking the test scenario into multiple, shorter test scenarios.
Rule. Avoid external dependencies. Others can run test by a single command or a one button click without extra configurations. e.g. Data file should be placed in the svn with test code, so that newcomers don't need to manually prepare it.
Bad 

public void testFile() {
    String testFile = "C:\\test\\test.odt";
    //Do test against on testFile
}

Good 

public void testFile() {
    // test.odt is placed with test code together. Given a relative path, prepareData will return the file's real absolute path.
    String testFile = prepareData("test.odt");
}

Rule. Make test method indepdent, not affect or be affected by others. Test methods can be executed in any particular order. So do necessary setup/teardown in @Before/@BeforeClass/@After/@AfterClass method to avoid side effects.
Rule. Log the generated data when you use random.
Rule. Name tests properly. "testLoadFileFromServer" is better than "test".

Retrieved from "https://wiki.openoffice.org/w/index.php?title=QA/test_automation_rules&oldid=204623"
Personal tools