Author: pekka.klarck
Date: Tue Jun 23 13:25:03 2009
New Revision: 2049
Modified:
wiki/HowToWriteGoodTestCases.wiki
Log:
added some content from issue 148, fixed typos
Modified: wiki/HowToWriteGoodTestCases.wiki
==============================================================================
--- wiki/HowToWriteGoodTestCases.wiki (original)
+++ wiki/HowToWriteGoodTestCases.wiki Tue Jun 23 13:25:03 2009
@@ -30,8 +30,8 @@
* Try to use name that describes what is done
* Possibly an existing keyword
- * More abstract names acceptable if setup/teardown contain unrelatd steps
- * Listing steps in name is dublication and a maintenance problem (e.g.
`Login to system, add user, activate alarms and check balance`)
+ * More abstract names acceptable if setup/teardown contain unrelated steps
+ * Listing steps in name is duplication and a maintenance problem (e.g.
`Login to system, add user, activate alarms and check balance`)
* May need to use something generic like `Initialize system`
* Everyone working with these tests should always understand the name
@@ -47,7 +47,7 @@
* Better to not have at all if not needed
* Don't include too much details about test cases
* Tests should be clear enough to
- * Dublicate information is waste and maintenance problem
+ * Duplicate information is waste and maintenance problem
* Can contain links to more information
== Test case documentation ==
@@ -64,6 +64,17 @@
* Can be used to explain arguments and return values
* Visible in resource file documentations generated with libdoc.py
+
+= Test suite structure =
+
+ * Test in a suite should be related to each others
+ * Same setup/teardown is a good indicator
+ * Max 10 test cases unless they are data-driven
+ * Tests should be independent
+ * Initialization using setup/teardown
+ * Never have long chains of dependent tests (max 4-5)
+
+
= Test case structure =
* Test case should be easy to understand
@@ -77,7 +88,12 @@
== Workflow tests ==
- * Steps describe what test does
+ * Generally has these phases:
+ * Preconditions (optional, often in setup)
+ * Action (do something to the system)
+ * Verification (must have one!)
+ * Cleanup (optional, always in teardown)
+ * Keywords describe what test does
* Use clear keyword names and suitable abstraction level
* Should contain enough information to run manually
* Should never need documentation or commenting to explain what test
does
@@ -86,12 +102,13 @@
* End-to-end tests can be on very high level
* One test should use only one abstraction level
* Different styles
- * More techical tests for lower level details and integration tests
- * "Executable specifications" act as requiremens
+ * More technical tests for lower level details and integration tests
+ * "Executable specifications" act as requirements
+ * Use domain language
* Everyone (including customer/product owner) should always understand
* No complex logic
* No for loops or if/else constructs
- * Use variable assignements with care
+ * Use variable assignments with care
* Test cases should not look like scripts
* Max 10 steps, preferably less
@@ -119,6 +136,9 @@
= Variables =
+
+ * Encapsulate long and/or complicated values
+ * Pass information between keywords
== Variable naming ==
