Revision: 4653
Author: [email protected]
Date: Mon Feb 28 17:30:47 2011
Log: Edited wiki page TestStructure through web user interface.
http://code.google.com/p/robotframework/source/detail?r=4653
Modified:
/wiki/TestStructure.wiki
=======================================
--- /wiki/TestStructure.wiki Mon Feb 28 17:24:00 2011
+++ /wiki/TestStructure.wiki Mon Feb 28 17:30:47 2011
@@ -8,20 +8,23 @@
= Should my keyword be in this file or library or some shared resource
file? =
-* If your keyword has complicated logic -> In a library!
+ * If your keyword has complicated logic -> In a library!
+ * When things seem too complicated in Robot Framework, its best not to
force it
<table>
-<tr><th>`invalid_login_should_fail.txt`</th><th>`invalid_login_should_fail.txt`</th></tr>
+<tr><th>`handle_steps.txt`</th><th>`handle_steps.py`</th></tr>
<tr><td>
{{{
*** Keywords ***
Get Step Message [Arguments] ${step}
- ${init result} Run Keyword If ${step}==0 System Initialization
- ${step result} Run Keyword If ${step}>0 Call System Step ${step}
+ ${init result} = Run Keyword If ${step}==0
+ ... System Initialization
+ ${step result} = Run Keyword If ${step}>0
+ ... Call System Step ${step}
${illegal result} Run Keyword If ${step}<0 Illegal Step
- ${result} = Set Variable If ${step}==0 ${init result}
- ... ${step}>0 ${step result}
- ... ${illegal result}
+ ${result} = Set Variable If ${step}==0 ${init result}
+ ... ${step}>0 ${step result}
+ ... ${illegal result}
[Return] ${result}
}}}
</td>
@@ -87,24 +90,25 @@
= In which suite should my test be? =
- - new case into a folder with 10 suite files. Which one to
choose?
- - Should One file be for one team? One Feature? One
Userstory?
-- Usually best structure comes from tests with same setup/teardown being
in the same file.
- - So look at setups/teardowns, if same = same suite!
-
- - tags can be used for tagging features/teams/whatever you
otherwise would use filenames for
-
- - One suite file for 1-20 test cases. Preferably no more than 10.
-
-If you have tests with very heavy setups and teardowns, they can be made
depend on each other
- - generally should be avoided
- - if done, they should be in the same file
- - Never have long chains of dependent tests (max 4-5).
- - Consider verifying the status of the previous test using ${PREV
TEST STATUS} and ${PREV TEST NAME} variables.
-
-Example of tests depending from each other:
-
-Before:
+
+ * New case into a folder with 10 suite files. Which one to choose?
+ * Should One file be for one team? One Feature? One Userstory?
+ * Usually best structure comes from tests with same setup/teardown being
in the same file.
+ * So look at setups/teardowns, if same = same suite!
+ * Tags can be used for tagging features/teams/whatever you otherwise
would use filenames for
+ * One suite file for 1-20 test cases. Preferably no more than 10.
+
+ * If you have tests with very heavy setups and teardowns, they can be
made depend on each other
+ * Generally should be avoided. Tests should be independent.
+ * If needed, the tests should be in the same suite file
+ * Never have long chains of dependent tests (max 4-5).
+ * Consider verifying the status of the previous test using ${PREV TEST
STATUS} and ${PREV TEST NAME} variables.
+
+
+<table>
+<tr><th>`slow_tests.txt`</th><th>`slow_tests.py`</th></tr>
+<tr><td>
+{{{
Heavy test 1
Setup system
Do a long heavy workflow
@@ -115,8 +119,10 @@
Do a long heavy workflow
Second heavy workflow
Check system status is OK
-
-After:
+}}}
+</td>
+<td>
+{{{
Heavy test 1
Setup system
Do a long heavy workflow
@@ -127,3 +133,6 @@
Should Be Equal ${PREV TEST NAME} Heavy Test 1
Second heavy workflow
Check system status is OK
+}}}
+</td></tr>
+</table>
