Revision: 3891
Author: jussi.ao.malinen
Date: Tue Aug 24 11:37:09 2010
Log: minor fixes
http://code.google.com/p/robotframework/source/detail?r=3891
Modified:
/trunk/doc/userguide/src/CreatingTestData/AdvancedFeatures.txt
/trunk/doc/userguide/src/CreatingTestData/CreatingTestCases.txt
/trunk/doc/userguide/src/CreatingTestData/CreatingTestSuites.txt
/trunk/doc/userguide/src/CreatingTestData/CreatingUserKeywords.txt
/trunk/doc/userguide/src/CreatingTestData/Variables.txt
/trunk/doc/userguide/src/ExecutingTestCases/BasicUsage.txt
/trunk/doc/userguide/src/ExecutingTestCases/TestExecution.txt
=======================================
--- /trunk/doc/userguide/src/CreatingTestData/AdvancedFeatures.txt Mon Mar
29 05:53:23 2010
+++ /trunk/doc/userguide/src/CreatingTestData/AdvancedFeatures.txt Tue Aug
24 11:37:09 2010
@@ -48,7 +48,7 @@
Scopes alone are not a sufficient solution, because there can be
keywords with the same name in several libraries or resources, and
-additionally, they provide a mechanism to use only the keyword of the
+thus, they provide a mechanism to use only the keyword of the
highest priority. In such cases, it is possible to use *the full name
of the keyword*, where the keyword name is prefixed with the name of
the resource or library and a dot is a delimiter.
@@ -243,7 +243,7 @@
Normal for loop
'''''''''''''''
-In a normal For loop, one variable is assigned into a list of values,
+In a normal For loop, one variable is assigned from a list of values,
one value per iteration. The syntax starts with :name:`:FOR`, where
colon is required to separate the syntax from normal keywords. The
next cell contains the loop variable, the subsequent cell must have
@@ -283,8 +283,8 @@
For loops are most useful and also clearest when they are used with
`list variables`_. This is illustrated by the example below, where
-:var:`...@{elements}` contains an arbitrary long list of element names
-and :name:`Start Element` is used with all of them.
+:var:`...@{elements}` contains an arbitrarily long list of element names
+and keyword :name:`Start Element` is used with all of them.
.. table:: For loop with a list variable
:class: example
@@ -303,8 +303,7 @@
It is also possible to use several loop variables. The syntax is the
same as with the normal For loop, but all loop variables are listed in
the cells between :name:`:FOR` and :name:`IN`. There can be any number of
loop
-variables, but their number must match the number of loop
-values. The number of values must be evenly dividable by the number of
+variables, but the number of values must be evenly dividable by the number
of
variables.
This syntax naturally works both with and without list variables. In
@@ -379,7 +378,7 @@
Repeating single keyword
''''''''''''''''''''''''
-For loops can be an overkill in situations where there is only a need to
repeat a single keyword. In these cases
+For loops can be excessive in situations where there is only a need to
repeat a single keyword. In these cases
it is often easier to use `BuiltIn keyword`_ :name:`Repeat Keyword` which
was added in Robot Framework 2.0.4.
This keyword takes a keyword and how many times to repeat it as arguments.
The times to repeat
the keyword can have an optional postfix `times` or `x` to make the syntax
easier to read.
=======================================
--- /trunk/doc/userguide/src/CreatingTestData/CreatingTestCases.txt Tue Aug
24 00:41:18 2010
+++ /trunk/doc/userguide/src/CreatingTestData/CreatingTestCases.txt Tue Aug
24 11:37:09 2010
@@ -403,7 +403,7 @@
- Tags are shown in test reports_, logs_ and, of course, in the test
data, so they provide metadata to test cases.
- Statistics__ about test cases (total, passed, failed are
- automatically collected based on tags.
+ automatically collected based on tags).
- With tags, you can `include or exclude`__ test cases to be executed.
- With tags, you can specify which test cases are considered `critical`_.
@@ -421,9 +421,8 @@
`Default Tags`:opt: in the Setting table
Test cases that do not have a :opt:`[Tags]` setting of their own
- get these tags. If it used in the test suite initialization file,
- it is interpreted as a default value for :opt:`Default Tags` in
- lower-level test suites.
+ get these tags. Starting from Robot Framework version 2.5 default
+ tags are no longer supported in test suite initialization files.
`[Tags]`:opt: in the Test Case table
A test case always gets these tags. Additionally, it does not get the
=======================================
--- /trunk/doc/userguide/src/CreatingTestData/CreatingTestSuites.txt Tue
Jun 8 16:40:31 2010
+++ /trunk/doc/userguide/src/CreatingTestData/CreatingTestSuites.txt Tue
Aug 24 11:37:09 2010
@@ -133,7 +133,7 @@
Test suite name and documentation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The test suite name is got from the file or directory name. The name
+The test suite name is constructed from the file or directory name. The
name
is created so that the extension is ignored, possible underscores are
replaced with spaces, and names fully in lower case are title cased. For
example, :path:`some_tests.html` becomes :name:`Some Tests` and
=======================================
--- /trunk/doc/userguide/src/CreatingTestData/CreatingUserKeywords.txt Sun
Apr 25 14:27:28 2010
+++ /trunk/doc/userguide/src/CreatingTestData/CreatingUserKeywords.txt Tue
Aug 24 11:37:09 2010
@@ -147,7 +147,7 @@
Positional arguments are probably sufficient in most
situations. However, sometimes it is useful to be able to have a
keyword that takes a different number of arguments and has default
-values for those that are not given. Also user keywords allow this,
+values for those that are not given. User keywords also allow this,
and the needed new syntax does not add very much to the already
discussed basic syntax. In short, default values are added to
arguments, so that first there is the equals sign (:code:`=`) and then
@@ -199,15 +199,16 @@
Variable number of arguments
''''''''''''''''''''''''''''
-Sometimes, but more and more seldom, even default values are not
-enough and there is a need for a keyword accepting any number of
-arguments. User keywords support also this. All that is needed is
-having `list variables`_ such as :var:`...@{varargs}` as the last
-argument in the keyword signature. This syntax can be combined with
-the previously described positional arguments and default values, and
-at the end the list variable gets all the leftover arguments that do
-not match other arguments. The list variable can thus have any number
-of items, even zero.
+Sometimes even default values are not enough and there is a need
+for a keyword accepting any number of arguments. User keywords
+support also this. All that is needed is having `list variable`__
+such as :var:`...@{varargs}` as the last argument in the keyword signature.
+This syntax can be combined with the previously described positional
+arguments and default values, and at the end the list variable gets all
+the leftover arguments that do not match other arguments. The list
+variable can thus have any number of items, even zero.
+
+__ `list variables`_
.. table:: User keywords accepting variable number of arguments
:class: example
@@ -234,12 +235,14 @@
value instead of the default value. This happens even if the given
value is empty. The last example also illustrates how a variable
number of arguments accepted by a user keyword can be used in a `for
-loops`_. This combination of two rather advanced functions can
+loop`__. This combination of two rather advanced functions can
sometimes be very useful.
Again, Pythonistas probably notice that the variable number of
arguments syntax is very close to the one in Python.
+__ `for loops`_
+
Embedding arguments into keyword name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -252,7 +255,7 @@
keywords like :name:`Select dog from list` and :name:`Selects cat from
list`, but all such keywords must have been implemented
separately. The idea of embedding arguments into the keyword name is
-that all you need is a keyword with name like :name:`Selects ${animal}
+that all you need is a keyword with name like :name:`Select ${animal}
from list`.
.. table:: An example keyword with arguments embedded into its name
@@ -275,15 +278,15 @@
mandatory to use all these arguments inside the keyword, and they can
thus be used as wildcards.
-This kind of keywords are also used the same way as other keywords
+These kind of keywords are also used the same way as other keywords
except that spaces and underscores are not ignored in their
names. They are, however, case-insensitive like other keywords. For
-example the keyword in the above example could be used like
+example the keyword in the example above could be used like
:name:`select x from list` but not like :name:`Select x fromlist`.
Embedded arguments do not support default values or variable number of
-arguments similarly as traditional arguments. Using variables when
-calling these keyword is possible but that can reduce readability.
+arguments like traditional arguments do. Using variables when
+calling these keywords is possible but that can reduce readability.
Notice also that embedded arguments only work with user keywords.
Embedded arguments matching too much
=======================================
--- /trunk/doc/userguide/src/CreatingTestData/Variables.txt Thu May 27
23:44:21 2010
+++ /trunk/doc/userguide/src/CreatingTestData/Variables.txt Tue Aug 24
11:37:09 2010
@@ -180,13 +180,12 @@
to assign a name for a larger data set. While list variables normally
contain only strings, other content is also possible.
-When you use a list variable in test data, then the cell that contains
-the variable is replaced with the content of the variable. Thus, if
-the list variable contains two elements, the cell containing the list
-variable is turned into two cells with the content of the list
-variable. Note that cells with list variables should not contain other
-content. The list variable syntax, :var:`...@{name}`, is borrowed from
-Perl.
+When you use a list variable in test data, then the elements of the list
+are inserted as new cells in the test data. Thus, if the list variable
+contains two elements, the cell containing the list variable is turned
+into two cells with the content of the list variable. Note that cells
+with list variables should not contain other content. The list variable
+syntax, :var:`...@{name}`, is borrowed from Perl.
Assuming that the list variable :var:`...@{user}` is set to the value
:code:`['robot','secret']`, the following two test cases
@@ -255,10 +254,10 @@
List variables can be used only with some of the settings__. They can
be used in arguments to imported libraries and variable files, but
library and variable file names themselves cannot be list
-variables. They work exactly the same way also with setups and
-teardowns, and with tag related settings they can be used
-freely. Using scalar variables is possible also in those places where
-list variables are not supported.
+variables. Also with setups and teardowns list variable can not be used
+as the name of the keyword, but can be used in arguments. With tag related
+settings they can be used freely. Using scalar variables is possible in
+those places where list variables are not supported.
.. table:: Using list variables with settings
:class: example
@@ -756,7 +755,7 @@
variables it imports. All these variables are available for files that
import this resource file.
- Notice that variables imported from resource and variable files are not
+ Note that variables imported from resource and variable files are not
available in the Variable table of the file that imports them. This
is due to the Variable table being processed before the Setting table
where the resource files and variable files are imported.
=======================================
--- /trunk/doc/userguide/src/ExecutingTestCases/BasicUsage.txt Thu Jun 10
02:51:44 2010
+++ /trunk/doc/userguide/src/ExecutingTestCases/BasicUsage.txt Tue Aug 24
11:37:09 2010
@@ -2,7 +2,7 @@
-----------
Robot Framework test cases are executed from the command line, and the
-end result is, by default, an output file in the XML format and an HTML
+end result is, by default, an output file in XML format and an HTML
report and log. After the execution, `output files`__ can be combined and
otherwise `post-processed`__ with the :prog:`rebot` tool.
@@ -268,7 +268,7 @@
the values does not always work too well, Robot Framework has its own
generic escaping mechanism. Another possibility is using `argument
files`_ where options can be specified in the plain text format. Both of
-these mechanisms work both when executing tests and when
+these mechanisms work when executing tests and when
post-processing outputs, and also some of the external supporting
tools have the same or similar capabilities.
@@ -515,7 +515,7 @@
same test manually, if possible, may also reveal more information
about the issue.
-Failures caused test cases themselves or by keywords they use can
+Failures caused by test cases themselves or by keywords they use can
sometimes be hard to debug. If the error message, for example, tells
that a keyword is used with wrong number of arguments fixing the
problem is obviously easy, but if a keyword is missing or fails in
=======================================
--- /trunk/doc/userguide/src/ExecutingTestCases/TestExecution.txt Tue Aug
24 06:52:04 2010
+++ /trunk/doc/userguide/src/ExecutingTestCases/TestExecution.txt Tue Aug
24 11:37:09 2010
@@ -23,7 +23,7 @@
options :opt:`--test`, :opt:`--suite`, :opt:`--include` and
:opt:`--exclude`. Suites containing no tests are ignored.
-The execution stars from the top-level test suite. If the suite has
+The execution starts from the top-level test suite. If the suite has
tests they are executed one-by-one, and if it has suites they are
executed recursively in depth-first order. When an individual test
case is executed, the keywords it contains are run in a
@@ -40,8 +40,7 @@
Setups and teardowns
''''''''''''''''''''
-Setups and teardowns on `test case`__ and `test suite`__ level have
-some effect on the test execution flow.
+Setups and teardowns can be defined on `test case`__ and `test suite`__
level.
__ `Test setup and teardown`_
__ `Suite setup and teardown`_
@@ -58,7 +57,7 @@
Suite setups are often used for setting up the test environment.
Because tests are not run if the suite setup fails, it is easy to use
-suite setups for verifying that the environment is in state that the
+suite setups for verifying that the environment is in state in which the
tests can be executed.
Suite teardown
