Author: pekka.klarck
Date: Tue Jun 23 12:55:45 2009
New Revision: 2048
Modified:
wiki/HowToWriteGoodTestCases.wiki
Log:
i dont like this wiki format...
Modified: wiki/HowToWriteGoodTestCases.wiki
==============================================================================
--- wiki/HowToWriteGoodTestCases.wiki (original)
+++ wiki/HowToWriteGoodTestCases.wiki Tue Jun 23 12:55:45 2009
@@ -53,10 +53,8 @@
== Test case documentation ==
* Test cases normally don't need documentation
- * Suite's name and documentation and test's name should give enough
- background information
- * Test cases' structure should be clear enough without documentation
- or other comments
+ * Suite's name and documentation and test's name should give enough
background information
+ * Test cases' structure should be clear enough without documentation
or other comments
* Sometimes useful so don't be afraid to use it
== User keyword documentation ==
@@ -101,8 +99,7 @@
* One high-level keyword per test
* Different arguments create different tests
- * The keyword often contains similar workflow as workflow tests
- and is created in the same test case file
+ * The keyword often contains similar workflow as workflow tests and is
created in the same test case file
* Possible, and recommended, to name column headings
* Better to have separate tests than test multiple things in one test
* Easier to understand than for example looping
@@ -131,15 +128,13 @@
* Lower case with variables only available inside certain test or
keyword
* Upper case with others (global, suite or test level)
* Both space and underscore can be used as word separator
- * Recommended to list also variables that are set dynamically in the
- variable table
+ * Recommended to list also variables that are set dynamically in the
variable table
* Set typically using `Set Global/Suite/Test Variable` keywords
* The initial value should explain where/how the real value is set
== Passing and returning values ==
- * Common approach is to return values from keywords, assign them to
variables
- and then pass them as arguments to other keywords
+ * Common approach is to return values from keywords, assign them to
variables and then pass them as arguments to other keywords
* Clear and easy to follow approach
* Looks like programming
* Alternative approach is using `Set Test Variable` keyword
@@ -155,7 +150,6 @@
* Instead of sleep, use keyword that polls has certain action occurred
* Should have a maximum time to wait
* Keyword names often starts with `Wait Until ...`
- * Possible to wrap other keywords inside built-in keyword
- `Wait Until Keyword Succeeds`
+ * Possible to wrap other keywords inside built-in keyword `Wait Until
Keyword Succeeds`
* Sometimes sleeping is easiest but use with care
* Never use in keywords that are used often by tests or other keywords
