[KSS-checkins] r53421 - kukit/kss.demo/branch/1.4-kss-test/kss/demo
reebalazs at codespeak.net
reebalazs at codespeak.net
Sun Apr 6 11:07:42 CEST 2008
Author: reebalazs
Date: Sun Apr 6 11:07:41 2008
New Revision: 53421
Modified:
kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_layers.txt
kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_suites.txt
kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_testcases.txt
Log:
Reformat paragraphs
Modified: kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_layers.txt
==============================================================================
--- kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_layers.txt (original)
+++ kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_layers.txt Sun Apr 6 11:07:41 2008
@@ -117,10 +117,10 @@
...
TypeError: The <class 'kss.demo.resource.KSSSeleniumTestCase'> suite class can be used only from inside a class definition.
-As the error message says, we must define the class from inside another
-class. This is used to locate files relatively from the module where the
-definition is. So we have to define them from a dummy plugin (however the plugin
-itself play no role in testing).
+As the error message says, we must define the class from inside
+another class. This is used to locate files relatively from the
+module where the definition is. So we have to define them from a
+dummy plugin (however the plugin itself play no role in testing).
>>> class DummyPlugin(object):
...
@@ -130,8 +130,8 @@
... )
>>> aSuite = DummyPlugin.aSuite
-The layers whose tests are active, will build a tree to compute the
-optimal setup-teardown order.
+The layers whose tests are active, will build a tree to compute
+the optimal setup-teardown order.
>>> from kss.demo.selenium_layer import LayerTree
@@ -139,10 +139,11 @@
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=1', '@@resource?path=...setDevMode.html', '@@resource?path=ta', '@@resource?path=...setProdMode.html', '@@resource?path=ta', '@@resource?path=2')
-As we can see in the above results, the tests are generated properly with setup and teardown.
+As we can see in the above results, the tests are generated
+properly with setup and teardown.
-If more cases use the same layer, they are grouped. They also just need to change
-the production mode twice:
+If more cases use the same layer, they are grouped. They also
+just need to change the production mode twice:
>>> class DummyPlugin2(object):
...
@@ -190,31 +191,33 @@
>>> d2Suite = DummyPlugin3.d2Suite
>>> eSuite = DummyPlugin3.eSuite
-And see what happens if only suite "d" is selected. We can see that the setup and teardown sequence is correct.
+And see what happens if only suite "d" is selected. We can see
+that the setup and teardown sequence is correct.
>>> tree = LayerTree((dSuite, ))
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=1', '@@resource?path=7', '@@resource?path=9', '@@resource?path=...setDevMode.html', '@@resource?path=td', '@@resource?path=...setProdMode.html', '@@resource?path=td', '@@resource?path=10', '@@resource?path=8', '@@resource?path=2')
-Replay this with a bunch of other tests added. Setup and teardown is executed ideally.
-In this case we have more dev / prod mode changes, since these are the fastest
-they are wrapped inside the layer.
+Replay this with a bunch of other tests added. Setup and teardown
+is executed ideally. In this case we have more dev / prod mode
+changes, since these are the fastest they are wrapped inside the
+layer.
>>> tree = LayerTree((cSuite, dSuite, d2Suite))
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=1', '@@resource?path=7', '@@resource?path=...setDevMode.html', '@@resource?path=tc', '@@resource?path=...setProdMode.html', '@@resource?path=tc', '@@resource?path=9', '@@resource?path=...setDevMode.html', '@@resource?path=td', '@@resource?path=td2', '@@resource?path=...setProdMode.html', '@@resource?path=td', '@@resource?path=td2', '@@resource?path=10', '@@resource?path=8', '@@resource?path=2')
-So far we have only tried single path setups. Let's now try a split route.
-The setup and teardown work correctly in one level.
+So far we have only tried single path setups. Let's now try a
+split route. The setup and teardown work correctly in one level.
>>> tree = LayerTree((aSuite, bSuite, cSuite))
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=1', '@@resource?path=...setDevMode.html', '@@resource?path=ta', '@@resource?path=...setProdMode.html', '@@resource?path=ta', '@@resource?path=5', '@@resource?path=...setDevMode.html', '@@resource?path=tb', '@@resource?path=...setProdMode.html', '@@resource?path=tb', '@@resource?path=6', '@@resource?path=7', '@@resource?path=...setDevMode.html', '@@resource?path=tc', '@@resource?path=...setProdMode.html', '@@resource?path=tc', '@@resource?path=8', '@@resource?path=2')
-Another functionality is that certain tests may mark that they don't want
-to be in dual mode:
+Another functionality is that certain tests may mark that they
+don't want to be in dual mode:
>>> class DummyPlugin4(object):
...
@@ -229,8 +232,9 @@
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=1', '@@resource?path=5', '@@resource?path=tb2', '@@resource?path=6', '@@resource?path=2')
-This is also true if both dual and single mode tests are in the same layer. In this case
-the tests will wun in the end, which in practice means Production mode.
+This is also true if both dual and single mode tests are in the
+same layer. In this case the tests will wun in the end, which in
+practice means Production mode.
>>> tree = LayerTree((bSuite, b2Suite))
>>> tuple(tree.get_relative_urls(None))
@@ -243,8 +247,9 @@
('@@resource?path=1', '@@resource?path=...setDevMode.html', '@@resource?path=ta', '@@resource?path=ta2', '@@resource?path=...setProdMode.html', '@@resource?path=ta', '@@resource?path=ta2', '@@resource?path=5', '@@resource?path=...setDevMode.html', '@@resource?path=tb', '@@resource?path=...setProdMode.html', '@@resource?path=tb', '@@resource?path=tb2', '@@resource?path=6', '@@resource?path=7', '@@resource?path=...setDevMode.html', '@@resource?path=tc', '@@resource?path=...setProdMode.html', '@@resource?path=tc', '@@resource?path=9', '@@resource?path=...setDevMode.html', '@@resource?path=td', '@@resource?path=td2', '@@resource?path=...setProdMode.html', '@@resource?path=td', '@@resource?path=td2', '@@resource?path=10', '@@resource?path=11', '@@resource?path=...setDevMode.html', '@@resource?path=te', '@@resource?path=...setProdMode.html', '@@resource?path=te', '@@resource?path=12', '@@resource?path=8', '@@resource?path=2')
-Finally, we still need to check the following:
-Suites that are empty are skipped, and no setup teardown or devel / prod mode is generated for them.
+Finally, we still need to check the following: Suites that are
+empty are skipped, and no setup teardown or devel / prod mode is
+generated for them.
>>> class DummyPlugin5(object):
...
Modified: kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_suites.txt
==============================================================================
--- kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_suites.txt (original)
+++ kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_suites.txt Sun Apr 6 11:07:41 2008
@@ -3,7 +3,8 @@
Selenium test suites
====================
-Selenium test suites can be set up from plugin resource definitions.
+Selenium test suites can be set up from plugin resource
+definitions.
>>> from kss.demo import (
... KSSSeleniumTestSuite,
@@ -20,17 +21,18 @@
>>> suite1 = Plugin.selenium_tests[0]
A suite is like a testcase collection, so it provides its allowed
-resource filenames. These are used to secure the resource handling
-(to select which files can be served from the filesystem).
+resource filenames. These are used to secure the resource
+handling (to select which files can be served from the
+filesystem).
>>> tuple(suite1.get_testcase_paths())
('1', '...setDevMode.html', '...setProdMode.html')
-(Normally we would see an absolute path in place of '1', but the module
-finder does not work from within doctests.)
+(Normally we would see an absolute path in place of '1', but the
+module finder does not work from within doctests.)
-And the list of test urls as well. (We use in place of the view which
-is not important in this case.)
+And the list of test urls as well. (We use in place of the view
+which is not important in this case.)
>>> tuple(suite1.get_relative_urls(None))
('@@resource?path=...setDevMode.html', '@@resource?path=1', '@@resource?path=...setProdMode.html', '@@resource?path=1')
@@ -39,9 +41,10 @@
Dual and single mode
--------------------
-The `suite1` suite also executes the tests twice, both in development and production mode.
-If we want single mode for a given suite, we can set it with setting the `dual_mode`
-parameter of the suite to False.
+The `suite1` suite also executes the tests twice, both in
+development and production mode. If we want single mode for a
+given suite, we can set it with setting the `dual_mode` parameter
+of the suite to False.
>>> class Plugin2(object):
...
@@ -60,7 +63,8 @@
Using test layers
-----------------
-We can define a layer to the suite, with its own setup and teardown.
+We can define a layer to the suite, with its own setup and
+teardown.
>>> from kss.demo import KSSSeleniumTestLayerBase
@@ -88,9 +92,10 @@
>>> tuple(suite3.get_relative_urls(None))
('@@resource?path=sa', '@@resource?path=...setDevMode.html', '@@resource?path=3', '@@resource?path=...setProdMode.html', '@@resource?path=3', '@@resource?path=ta')
-To use more tests in the setup of a layer, no extra effort is needed
-since the testcase resource already provide KSSSeleniumTestCaseList
-to construct collection from other testcases.
+To use more tests in the setup of a layer, no extra effort is
+needed since the testcase resource already provide
+KSSSeleniumTestCaseList to construct collection from other
+testcases.
>>> from kss.demo import KSSSeleniumTestCaseList
@@ -153,9 +158,11 @@
Generating tests for a set of resources
---------------------------------------
-Normally, the tests are not collected from suites individually, but a tree is built from a set
-of suites providing an optimal setup and teardown sequence. This is done by the demo utility itself.
-The list of suites is originating from various different plugins.
+Normally, the tests are not collected from suites individually,
+but a tree is built from a set of suites providing an optimal
+setup and teardown sequence. This is done by the demo utility
+itself. The list of suites is originating from various different
+plugins.
>>> class Plugin5(object):
...
@@ -175,28 +182,32 @@
>>> tuple(tree.get_relative_urls(None))
('@@resource?path=2', '@@resource?path=sa', '@@resource?path=...setDevMode.html', '@@resource?path=5a', '@@resource?path=...setProdMode.html', '@@resource?path=5a', '@@resource?path=sb', '@@resource?path=...setDevMode.html', '@@resource?path=5b', '@@resource?path=...setProdMode.html', '@@resource?path=5b', '@@resource?path=tb', '@@resource?path=ta')
-More testing of the layers can be found in the selenium_layers.txt file.
+More testing of the layers can be found in the
+selenium_layers.txt file.
Filtering of testcases
----------------------
-Test suites can be given a ``component`` and ``application`` property. They are
-both strings.
+Test suites can be given a ``component`` and ``application``
+property. They are both strings.
-``component`` should be the dotted component name of the owner of this test.
-For example, ``plone.app.fancylib`` or ``kss.plugins.superplugin``.
-
-``application`` identified the application that tests for the usage of this
-component. For example, ``Plone``. This is usually a bigger category then the
-component, as an application consists of many components.
-
-If the application property is not specified, this means that the test does not
-belong to a specific application, so it is either a kss core or a
-plugin test.
-
-Filtering at the moment is only implemented by the ``application`` property.
-This means all the tests of an application can be executed together.
+``component`` should be the dotted component name of the owner of
+this test. For example, ``plone.app.fancylib`` or
+``kss.plugins.superplugin``.
+
+``application`` identified the application that tests for the
+usage of this component. For example, ``Plone``. This is usually
+a bigger category then the component, as an application consists
+of many components.
+
+If the application property is not specified, this means that the
+test does not belong to a specific application, so it is either a
+kss core or a plugin test.
+
+Filtering at the moment is only implemented by the
+``application`` property. This means all the tests of an
+application can be executed together.
>>> class Plugin6(object):
...
@@ -212,8 +223,8 @@
... ),
... )
-The filtering is done from the resource registry. How the test sequence is
-actually constructed from a selection of suites, is demonstrated in the
-``selenium_layers.txt`` document.
+The filtering is done from the resource registry. How the test
+sequence is actually constructed from a selection of suites, is
+demonstrated in the ``selenium_layers.txt`` document.
Modified: kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_testcases.txt
==============================================================================
--- kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_testcases.txt (original)
+++ kukit/kss.demo/branch/1.4-kss-test/kss/demo/selenium_testcases.txt Sun Apr 6 11:07:41 2008
@@ -3,43 +3,45 @@
Selenium test cases
===================
-Selenium test cases in kss.demo are defined by "test collections".
-A collection selects a number of tests. This is why they are called collections,
-although in reality they are testcases which however can be constructed
-from other collections.
+Selenium test cases in kss.demo are defined by "test
+collections". A collection selects a number of tests. This is
+why they are called collections, although in reality they are
+testcases which however can be constructed from other
+collections.
-There are two methods that every collection has, and they are executed
-during the creation of the test suite.
+There are two methods that every collection has, and they are
+executed during the creation of the test suite.
Every collection implements an ``get_resolve_urls``. This returns
-an iterator that yields a list of relative test urls. If resolved,
-they should render a selenium test case in html format. The order
-of the resources specifies their execution order. The method
-needs to be called with the rendering view as a parameter.
+an iterator that yields a list of relative test urls. If
+resolved, they should render a selenium test case in html format.
+The order of the resources specifies their execution order. The
+method needs to be called with the rendering view as a parameter.
In addition, they also implement a ``get_testcase_paths`` method.
This, unlike the previous one, returns an iterator to a list of
absolute filenames. The order of these is not important. It must
contain all the filenames that the collection wants to publish
via the ``@@resource?path=...`` view provided by kss.demo. So,
-each item in this list corresponds to an item in the ``get_resolve_urls``
-results.
+each item in this list corresponds to an item in the
+``get_resolve_urls`` results.
-New collection types can be implemented by classes, as long as they
-implement the ``ISeleniumTestCollection`` interface, in the way specified
-below. kss.demo supplies the following collection types, that
-allow to specify a set of testcases in a flexible way.
+New collection types can be implemented by classes, as long as
+they implement the ``ISeleniumTestCollection`` interface, in the
+way specified below. kss.demo supplies the following collection
+types, that allow to specify a set of testcases in a flexible
+way.
Creation of testcase collections
--------------------------------
-The collections use implicit magic (the same one used by the
-Zope CA for the ``implements``) to locate the directory of the
-python file that instantiates the collection. This allows that
-filenames that are used as parameters, will be expanded to their
-absolute class automatically. If we create a collection in itself,
-we will get an error:
+The collections use implicit magic (the same one used by the Zope
+CA for the ``implements``) to locate the directory of the python
+file that instantiates the collection. This allows that filenames
+that are used as parameters, will be expanded to their absolute
+class automatically. If we create a collection in itself, we will
+get an error:
>>> from kss.demo import KSSSeleniumTestCase
@@ -48,8 +50,8 @@
...
TypeError: The <class 'kss.demo.resource.KSSSeleniumTestCase'> suite class can be used only from inside a class definition.
- The correct way is to use it from inside a class definition. This way
- the html file will be located relative to this directory:
+The correct way is to use it from inside a class definition. This
+way the html file will be located relative to this directory:
>>> from kss.demo import KSSSeleniumTestSuite
@@ -65,9 +67,9 @@
Test cases by filename
----------------------
-This collection will contain a single test that we specify by filepath.
-The path will be applied relatively to the directory where the file
-containing the instantiation resides.
+This collection will contain a single test that we specify by
+filepath. The path will be applied relatively to the directory
+where the file containing the instantiation resides.
>>> class Suite:
... tests = KSSSeleniumTestCase('my_testcase.html')
@@ -78,13 +80,15 @@
>>> tuple(case1.get_relative_urls(None))
('@@resource?path=...my_testcase.html',)
-Note that we gave ``None`` as a parameter. This should be normally
-the view that does the rendering, needed to be passed to each collection.
-We will see a case later when this will be important.
-
-The ``get_testcase_paths`` method also just returns a single absolute
-filepath. (In the case of the test they will really not be absolute,
-because the locator magic does not work well with doctests.)
+Note that we gave ``None`` as a parameter. This should be
+normally the view that does the rendering, needed to be passed to
+each collection. We will see a case later when this will be
+important.
+
+The ``get_testcase_paths`` method also just returns a single
+absolute filepath. (In the case of the test they will really not
+be absolute, because the locator magic does not work well with
+doctests.)
>>> tuple(case1.get_testcase_paths())
('...my_testcase.html',)
@@ -93,9 +97,9 @@
Test cases by directory
-----------------------
-This is the usual way of working with tests. We specify a directory,
-and every ``*.html`` file in that directory is picked into the testcase
-collection.
+This is the usual way of working with tests. We specify a
+directory, and every ``*.html`` file in that directory is picked
+into the testcase collection.
>>> from kss.demo import KSSSeleniumTestDirectory
@@ -103,7 +107,8 @@
... tests = KSSSeleniumTestDirectory('selenium_tests')
>>> case2 = Suite2.tests
- We don't have this directory here. So in both cases we get an error.
+We don't have this directory here. So in both cases we get an
+error.
>>> tuple(case2.get_relative_urls(None))
Traceback (most recent call last):
@@ -115,9 +120,9 @@
...
OSError: [Errno 2] No such file or directory: 'selenium_tests'
- For the sake of the test, we will find a testcase directory
- from kss.core. Note this would not be needed from real code,
- you'd just need to use the directory name.
+For the sake of the test, we will find a testcase directory from
+kss.core. Note this would not be needed from real code, you'd
+just need to use the directory name.
>>> import sys, os.path, kss.core.plugins.core.demo
>>> rootdir = os.path.dirname(sys.modules['kss.core.plugins.core.demo'].__file__)
@@ -127,7 +132,8 @@
... tests = KSSSeleniumTestDirectory(dirpath)
>>> case2 = Suite2.tests
- There are many tests in this list. (These are the tests for the kss core plugin.)
+There are many tests in this list. (These are the tests for the
+kss core plugin.)
>>> tuple(case2.get_relative_urls(None))
('@@resource?path=...0_ecmaunit_tests.html', ...)
@@ -196,12 +202,13 @@
Support for sandbox creation
----------------------------
-A more special testcase is used to create a sandbox (a site with some content, or
-some initial data that each test needs). This test suite
-will be rendered by the browser view and take parameters. These are used as
-credentials for the content creation (as normal login to Zope could not be used
-from the setup), and to specify the url of the view that will carry out the
-creation.
+A more special testcase is used to create a sandbox (a site with
+some content, or some initial data that each test needs). This
+test suite will be rendered by the browser view and take
+parameters. These are used as credentials for the content
+creation (as normal login to Zope could not be used from the
+setup), and to specify the url of the view that will carry out
+the creation.
For this test, we will need a real (although fake) view.
@@ -224,13 +231,14 @@
>>> tuple(case6.get_relative_urls(fake_view))
('@@kss-selenium-create-sandbox-test.html?method_name=@@kss_create_my_sandbox&admin_username=admin&admin_password=admin',)
-This view will generate a testcase which is an informational form with a button. If
-this button is pressed, the view specified with ``method_name`` will be executed.
-This will receive the credentials, and it will check them against the Zope
+This view will generate a testcase which is an informational form
+with a button. If this button is pressed, the view specified with
+``method_name`` will be executed. This will receive the
+credentials, and it will check them against the Zope
authentication information, before acting as Administrator.
-The collection does not return paths, since it does not use the ```@@resource?path=...```
-view.
+The collection does not return paths, since it does not use the
+``@@resource?path=...`` view.
>>> tuple(case6.get_testcase_paths())
()
More information about the Kukit-checkins
mailing list