Revision: 3978
Author: jussi.ao.malinen
Date: Sat Aug 28 08:09:32 2010
Log: Fixed API examples and minor cleanup
http://code.google.com/p/robotframework/source/detail?r=3978
Modified:
/trunk/doc/userguide/src/ExtendingRobotFramework/CreatingTestLibraries.txt
/trunk/doc/userguide/src/ExtendingRobotFramework/InternalAPI.txt
=======================================
---
/trunk/doc/userguide/src/ExtendingRobotFramework/CreatingTestLibraries.txt
Fri Aug 27 01:51:24 2010
+++
/trunk/doc/userguide/src/ExtendingRobotFramework/CreatingTestLibraries.txt
Sat Aug 28 08:09:32 2010
@@ -623,8 +623,8 @@
contain either string :code:`true` or :code:`false`. Coercion is only
done if the original value was a string from the test data, but it is
of course still possible to use variables containing correct types with
-these keywords. With keywords having conflicting signatures using
-variables is the only option.
+these keywords. Using variables is the only option if keywords have
+conflicting signatures.
.. table:: Using automatic type coercion
:class: example
@@ -878,8 +878,7 @@
several `scalar variables`_ at once, into `a list variable`__, or
into scalar variables and a list variable. All these usages require
that returned values are Python lists or tuples or
-Java arrays. If there is a need, support for other iterables can be
-added in the future.
+in Java arrays, Lists, or Iterators.
__ `List variables`_
@@ -1014,8 +1013,9 @@
After a library is implemented, documented, and tested, it still needs
to be distributed to the users. With simple libraries consisting of a
single file, it is often enough to ask the users to copy that file
-somewhere and set the `library search path`_ accordingly. With more
-complicated libraries, package them to make the installation easier.
+somewhere and set the `library search path`_ accordingly. More
+complicated libraries should be packaged to make the installation
+easier.
Since libraries are normal programming code, they can be packaged
using normal packaging tools. With Python, good options include
@@ -1090,7 +1090,7 @@
~~~~~~~~~~~~~~~~~~~
The dynamic API is in most ways similar to the static API. For
-example, reporting the keyword status, logging and returning values
+example, reporting the keyword status, logging, and returning values
works exactly the same way. Most importantly, there are no differences
in importing dynamic libraries and using their keywords compared to
other libraries, so you do not even need to know what APIs the
@@ -1282,8 +1282,8 @@
It is possible to write a formal interface specification in Java, as
below. However, remember that libraries *do not need* to implement
-any explicit interface, because Robot Framework directly checks if the
-library has the required :code:`get_keyword_names` and
+any explicit interface, because Robot Framework directly checks with
+reflection if the library has the required :code:`get_keyword_names` and
:code:`run_keyword` methods. Additionally,
:code:`get_keyword_arguments` and :code:`get_keyword_documentation`
are completely optional.
@@ -1437,11 +1437,11 @@
print '*HTML* Output written to <a
href="results.txt">results.txt</a>'
The only catch with using methods from :code:`BuiltIn` is that all
-:code:`run_keyword` method variants must be handled specially. What
-needs to be done is registering methods that use these methods to be *run
-keywords* themselves using :code:`register_run_keyword` method
-in :code:`BuiltIn` module. This method's documentation explains why
-this needs to be done and obviously also how to do it.
+:code:`run_keyword` method variants must be handled specially.
+Methods that use :code:`run_keyword` methods have to be registered
+as *run keywords* themselves using :code:`register_run_keyword`
+method in :code:`BuiltIn` module. This method's documentation explains
+why this needs to be done and obviously also how to do it.
The plan is to document all the internal modules better so that it is
easier to decide which can be used and how they should be used. If you
@@ -1530,7 +1530,7 @@
Getting active library instance from Robot Framework
''''''''''''''''''''''''''''''''''''''''''''''''''''
-Robot Framework 2.5.2 added by BuiltIn_ keyword :name:`Get Library
+Robot Framework 2.5.2 added new BuiltIn_ keyword :name:`Get Library
Instance` that can be used to get the currently active library
instance from the framework itself. The library instance returned by
this keyword is the same as the framework itself uses, and thus
=======================================
--- /trunk/doc/userguide/src/ExtendingRobotFramework/InternalAPI.txt Tue
Mar 31 02:34:03 2009
+++ /trunk/doc/userguide/src/ExtendingRobotFramework/InternalAPI.txt Sat
Aug 28 08:09:32 2010
@@ -64,20 +64,20 @@
Parsed test data
~~~~~~~~~~~~~~~~
-This API consists of a factory method for getting a :code:`TestSuite`
-object that contains parsed test data. The method is used like
-:code:`TestSuite(*datasources)`, where :code:`datasources` are paths to
-files and directories containing the test data:
+Package :code:`robot.parsing` contains tools for parsing and handling test
data.
+:code:`TestCaseFile` and :code:`TestDataDirectory` classes can be
instantiated
+with parameter :code:`source` to start parsing existing test data. Example
below
+shows how to parse names of tests from a test file. For more details please
+see the source code of Robot Framework directly.
.. sourcecode:: python
- from robot.parsing import TestSuite
-
- suite = TestSuite('path/to/tests.html')
- print suite.name
- for test in suite.tests:
- print test.name
-
+ from robot.parsing import TestCaseFile
+
+ suite = TestCaseFile(source='path/to/tests.html')
+ print 'Suite: ', suite.name
+ for test in suite.testcase_table:
+ print test.name
Runnable test data
~~~~~~~~~~~~~~~~~~
