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


Ignore:
Timestamp:
04/22/13 22:58:21 (9 years ago)
Author:
somayjain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Testing/TestSuite

    v10 v11  
    6565* 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.
    6666
    67 * 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.
     67* 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.
    6868
    6969* 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.
     
    7373* 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.
    7474
    75 * 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'''.
     75* 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'''.
    7676
    7777* 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.
     78
     79* A sample code-template can be of the form -
     80{{{
     81# Create Method
     82def test_<testname>_create_<module_name>(self):
     83    self.login(account, nexturl)    # already implemented
     84    # The data which is to be added to the table
     85    data_list = [ ( column_name1, data1 ), ( column_name2, data2 ), .. so on ]
     86    self.create(tablename , data_list)
     87
     88# Search Method
     89def test_<testname>_search_type_<module_name>(self):
     90    self.login(account, nexturl)    # already implemented
     91    search_fields = [ ( column_name1 , [label1, label2, ..] ),    # the list of labels are those which
     92                                                                  # are to be searched for under column_name1
     93                      ( column_name2 , [label1, label2, ..] ),
     94                      .. so on ]
     95
     96    self.search(type, tablename, search_fields)    # type can be simple or advanced
     97
     98# Edit Method
     99def test_<testname>_edit_<module_name>(self):
     100    self.login(account, nexturl)    # already implemented
     101    # The new data which is to be edited in the table
     102    edit_list = [ ( column_name1, data1 ), ( column_name2, data2 ), .. so on ]
     103    self.create(tablename , edit_list)
     104
     105}}}
    78106
    79107* 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.