Changes between Version 10 and Version 11 of BluePrint/Testing/TestSuite

Timestamp:

04/22/13 22:58:21 (12 years ago)

Author:

somayjain

Comment:

--

BluePrint/Testing/TestSuite

@@ -65 +65 @@
 * The CI Server should fetch the latest code from [https://github.com/flavour/eden/ Github Repository] and run the tests on the latest code fetched.
 
-* The CI Server should run all the tests across templates on a daily basis both locally and remotely. It should save the aggregate report of the tests on the server and as well as mail it to the concerned people. People may also subscribe to receive the test results via email.
+* The CI Server should run all the tests across templates on a daily basis both locally and remotely. It should '''save the aggregate report of the tests on the server and as well as mail it to the concerned people.''' People may also subscribe to receive the test results via email. The previous implementation of the CI Server saved the results at [http://82.71.213.53/RESULTS/]. The same location can be used for storing the test results.
 
 * For each test, the report should include '''the template it is run on, test name and location of the test script in eden'''. In case of failure of the test, '''it should include the traceback and the record details it was intended to work on'''. In case the test passes, it should include the test name and the pass status of the test.
@@ -73 +73 @@
 * These tests should run against each and every template where the target functionality is available. For templates where the functionality is not available, the test should auto-deactivate.
 
-* Given that Sahana is a web-based tool, Selenium tests should be made robust, easy to use. The main idea is to '''have a set of functions(create, search, report, edit) which will take the tablename, labels of the field and the record data as input'''. 
+* Given that Sahana is a web-based tool, Selenium tests should be made robust, easy to use. The main idea is to '''have a set of functions(create, search, edit) which will take the tablename, labels of the field and the record data as input'''. 
 
 * The Test suite should '''automatically check the type of field(option, autocomplete, text, date, datetime, etc) being used''' in the current template and fill the form accordingly. With this, we can create a code-template which just needs to be copied, pasted and fed in the record when creating a new Selenium test. This will ensure that writing Selenium tests are as easy as giving a test case.
+
+* A sample code-template can be of the form - 
+{{{
+# Create Method
+def test_<testname>_create_<module_name>(self):
+    self.login(account, nexturl)    # already implemented
+    # The data which is to be added to the table
+    data_list = [ ( column_name1, data1 ), ( column_name2, data2 ), .. so on ]
+    self.create(tablename , data_list)
+
+# Search Method
+def test_<testname>_search_type_<module_name>(self):
+    self.login(account, nexturl)    # already implemented
+    search_fields = [ ( column_name1 , [label1, label2, ..] ),    # the list of labels are those which 
+                                                                  # are to be searched for under column_name1 
+                      ( column_name2 , [label1, label2, ..] ),
+                      .. so on ]
+
+    self.search(type, tablename, search_fields)    # type can be simple or advanced
+
+# Edit Method
+def test_<testname>_edit_<module_name>(self):
+    self.login(account, nexturl)    # already implemented
+    # The new data which is to be edited in the table
+    edit_list = [ ( column_name1, data1 ), ( column_name2, data2 ), .. so on ]
+    self.create(tablename , edit_list)
+
+}}}
 
 * So, the workflow of the developer will include running the unit tests to see if the new changes break anything and providing a Selenium test for the newly written module, which will be run in Continuous Integration.