| Prev |
40.10.30 Cal Admin can also add new user party/groups/person to individual calendar items
40.20 Calendar Items Administration -
40.20.10 Provides the funcationality to delete, add, edit any +
40.20.10 Provides the functionality to delete, add, edit any item on the calendar
40.20.20 Provides the funcatinality to allow Calendar Administrator to change the permissions on each calendar item. Index: openacs-4/packages/acs-automated-testing/tcl/aa-test-procs.tcl =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-automated-testing/tcl/aa-test-procs.tcl,v diff -u -N -r1.79.2.15 -r1.79.2.16 --- openacs-4/packages/acs-automated-testing/tcl/aa-test-procs.tcl 16 Jul 2019 17:55:02 -0000 1.79.2.15 +++ openacs-4/packages/acs-automated-testing/tcl/aa-test-procs.tcl 9 Aug 2019 20:41:40 -0000 1.79.2.16 @@ -373,7 +373,7 @@ Also used, automatically, for errors sourcing test cases. - @param bugs A list of integers correspending to openacs.org bug numbers which relate to this test case. + @param bugs A list of integers corresponding to openacs.org bug numbers which relate to this test case. @param procs A list of OpenACS procs which are tested by this case. @param urls A list of URLs (relative to package) tested in web test case @@ -1372,7 +1372,7 @@ } } finally { # - # always reset after the reqest the login data nsv + # always reset after the request the login data nsv # nsv_unset -nocomplain aa_test logindata } @@ -1818,7 +1818,7 @@ ad_proc -public equals {node pairs} { Test whether provided selectors (first element of the pair) - return the specificed results (second element of the pair). + return the specified results (second element of the pair). } { foreach {q value} $pairs { @@ -2144,7 +2144,7 @@ set root_node [xml_doc_get_first_node $tree] - # Get the total test case cound + # Get the total test case count set testcase_count_node [xml_node_get_children_by_name $root_node testcase_count] set test(testcase_count) [xml_node_get_content $testcase_count_node] Index: openacs-4/packages/acs-automated-testing/www/doc/index.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-automated-testing/www/doc/index.html,v diff -u -N -r1.7 -r1.7.2.1 --- openacs-4/packages/acs-automated-testing/www/doc/index.html 7 Aug 2017 23:47:46 -0000 1.7 +++ openacs-4/packages/acs-automated-testing/www/doc/index.html 9 Aug 2019 20:41:40 -0000 1.7.2.1 @@ -2,7 +2,7 @@
+"HTML Tidy for macOS (vers 31 October 2006 - Apple Inc. build 15.15), see www.w3.org">Automated Testing provides a framework for executing tests of all varieties and for storing and viewing the results.
| Req # | Status in 5.0 | Priority for 5.1 (A=required, B=optional) | Description |
|---|---|---|---|
| 1 | Done | Done | Execute Tcl tests. Execute a sequence of Tcl code is executed and determine the correctness of the results. |
| 1.1 | partial | Done | Execute HTTP tests. Execute tests that can interact with a the webserver via the external, HTTP interface, including retrieving pages, following links, and submitting forms. (This is partially done in the sense that we can make http calls from tcl api, but there is no framework for doing anything complicated.) |
| 1.1.1 | Done | Execute tclwebtest scripts. A test can contain tclwebtest commands. If tclwebtest is not installed, those commands fail gracefully. | |
| 1.1.1.1 | partial | A | tclwebtest is easy to install. Tclwebtest installation is fully documented and can be installed with less than five steps. (Install is documented in 5.0, but there's a can't-find-config error; also, some new work in tclwebtest HEAD needs to packaged in a new tarball release.) |
| 2 | Done | Done | Tests have categories. Individual tests can be marked as belonging to zero, one, or many of these categories. The UI provides for running only tests in selected categories, and for viewing only results of tests in selected categories. |
| 2.1 | A | Each test can be associated with a single OpenACS.org bug (ie, store bug id as in integer, or store full url so that this can point to other bugs) | |
| 3 | B | Tests can be ordered lists of other tests. minimal: verify that a test proc can call other test procs. Better: A test can be created within the GUI by selecting other tests. This test is stored in the database and can be exported. (This is related to a bigger issue of storing test scripts in some format other than tcl procs.) | |
| 4 | C | Test scripts can be imported and exported. It should be possible to import a test into the database from a file, and to export it to a file. These files should be sharable by different OpenACS installations. It should be possible to import/export directly between running OpenACS sites. (We should look at what did and didn't work in acs-lang catalog files and work from there.) | |
| 5 | B | Macro Recording. End users can create and run tests from the web interface without writing code.
- 1) UI to turn on macro mode. 2) basic recording: when you fill out a form while macro mode is on, the submit is caught and displayed as tclwebtest code, and then executed. 3) UI for creating aa_true tests automatically, based on the content of the page. (For example, a form that says "the returned page must contain [ type regexp here] that spits out aa_true "test X" [string regexp blah blah] | |
| 6 | A | Notification subscriptions are available for "email me whenever this test fails" and "notify me whenever a test in this category fails" | |
| 7 | A | The results of an automated test are optionally written to an xml file. |
Because the current test package uses in-memory variables instead of database objects to track its tests, it is incompatible with the standard category package. It uses an internal, single-dimension category field. Should this eventually get extended, a more complete list of categories to implement could be:
Testing Mode +
Automated Testing provides a framework for executing tests of all varieties and for storing and viewing the results.
| Req # | Status in 5.0 | Priority for 5.1 (A=required, B=optional) | Description |
|---|---|---|---|
| 1 | Done | Done | Execute Tcl tests. Execute a sequence of Tcl code is executed and determine the correctness of the results. |
| 1.1 | partial | Done | Execute HTTP tests. Execute tests that can interact with a the webserver via the external, HTTP interface, including retrieving pages, following links, and submitting forms. (This is partially done in the sense that we can make http calls from tcl api, but there is no framework for doing anything complicated.) |
| 1.1.1 | Done | Execute tclwebtest scripts. A test can contain tclwebtest commands. If tclwebtest is not installed, those commands fail gracefully. | |
| 1.1.1.1 | partial | A | tclwebtest is easy to install. Tclwebtest installation is fully documented and can be installed with less than five steps. (Install is documented in 5.0, but there's a can't-find-config error; also, some new work in tclwebtest HEAD needs to packaged in a new tarball release.) |
| 2 | Done | Done | Tests have categories. Individual tests can be marked as belonging to zero, one, or many of these categories. The UI provides for running only tests in selected categories, and for viewing only results of tests in selected categories. |
| 2.1 | A | Each test can be associated with a single OpenACS.org bug (ie, store bug id as in integer, or store full url so that this can point to other bugs) | |
| 3 | B | Tests can be ordered lists of other tests. minimal: verify that a test proc can call other test procs. Better: A test can be created within the GUI by selecting other tests. This test is stored in the database and can be exported. (This is related to a bigger issue of storing test scripts in some format other than tcl procs.) | |
| 4 | C | Test scripts can be imported and exported. It should be possible to import a test into the database from a file, and to export it to a file. These files should be shareable by different OpenACS installations. It should be possible to import/export directly between running OpenACS sites. (We should look at what did and didn't work in acs-lang catalog files and work from there.) | |
| 5 | B | Macro Recording. End users can create and run tests from the web interface without writing code.
+ 1) UI to turn on macro mode. 2) basic recording: when you fill out a form while macro mode is on, the submit is caught and displayed as tclwebtest code, and then executed. 3) UI for creating aa_true tests automatically, based on the content of the page. (For example, a form that says "the returned page must contain [ type regexp here] that spits out aa_true "test X" [string regexp blah blah] | |
| 6 | A | Notification subscriptions are available for "email me whenever this test fails" and "notify me whenever a test in this category fails" | |
| 7 | A | The results of an automated test are optionally written to an XML file. |
Because the current test package uses in-memory variables instead of database objects to track its tests, it is incompatible with the standard category package. It uses an internal, single-dimension category field. Should this eventually get extended, a more complete list of categories to implement could be:
Testing Mode
Regression
Smoke
Stress
Index: openacs-4/packages/acs-automated-testing/www/doc/xml/requirements.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-automated-testing/www/doc/xml/requirements.xml,v
diff -u -N -r1.6 -r1.6.4.1
--- openacs-4/packages/acs-automated-testing/www/doc/xml/requirements.xml 27 Oct 2014 16:39:03 -0000 1.6
+++ openacs-4/packages/acs-automated-testing/www/doc/xml/requirements.xml 9 Aug 2019 20:41:40 -0000 1.6.4.1
@@ -78,7 +78,7 @@
4
C
- Test scripts can be imported and exported . It should be possible to import a test into the database from a file, and to export it to a file. These files should be sharable by different OpenACS installations. It should be possible to import/export directly between running OpenACS sites. (We should look at what did and didn't work in acs-lang catalog files and work from there.)Test scripts can be imported and exported . It should be possible to import a test into the database from a file, and to export it to a file. These files should be shareable by different OpenACS installations. It should be possible to import/export directly between running OpenACS sites. (We should look at what did and didn't work in acs-lang catalog files and work from there.)
@@ -101,7 +101,7 @@
7
A
- The results of an automated test are optionally written to an xml file.
+ The results of an automated test are optionally written to an XML file.