Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-29T01:04:47Z

Pdscott2: /* Round 2 Testing Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). A sample HTML page demonstrating the ability to query by filename was written as part of phase I. For phase II, a more complex HTML page will be required which queries for filename and date range. Records will also be populated into an HTML table instead of returning raw JSON. Javascript functions will also be added to sort columns using the [https://datatables.net DataTables jQuery plug-in].
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python tests.py</code>

=====To Run The App Locally=====
* Set the Flask environment variable by typing <code>export FLASK_APP=flask_sever</code> (use set instead of export for Windows)
* In the cloned repo folder, use the command <code>python -m flask_server</code> or alternatively type <code>flask run</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:56:54Z

Pdscott2: /* To Run The App Locally */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). A sample HTML page demonstrating the ability to query by filename was written as part of phase I. For phase II, a more complex HTML page will be required which queries for filename and date range. Records will also be populated into an HTML table instead of returning raw JSON. Javascript functions will also be added to sort columns using the [https://datatables.net DataTables jQuery plug-in].
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python tests.py</code>

=====To Run The App Locally=====
* Set the Flask environment variable by typing <code>export FLASK_APP=flask_sever</code> (use set instead of export for Windows)
* In the cloned repo folder, use the command <code>python -m flask_server</code> or alternatively type <code>flask run</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:56:01Z

Pdscott2: /* To Run The App Locally */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). A sample HTML page demonstrating the ability to query by filename was written as part of phase I. For phase II, a more complex HTML page will be required which queries for filename and date range. Records will also be populated into an HTML table instead of returning raw JSON. Javascript functions will also be added to sort columns using the [https://datatables.net DataTables jQuery plug-in].
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python tests.py</code>

=====To Run The App Locally=====
* Set the Flask environment variable by typing <code>export FLASK_APP=flask_sever</code>
* In the cloned repo folder, use the command <code>python -m flask_server</code> or alternatively type <code>flask run</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:53:36Z

Pdscott2: /* To Run Unit Tests */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). A sample HTML page demonstrating the ability to query by filename was written as part of phase I. For phase II, a more complex HTML page will be required which queries for filename and date range. Records will also be populated into an HTML table instead of returning raw JSON. Javascript functions will also be added to sort columns using the [https://datatables.net DataTables jQuery plug-in].
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python tests.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:52:23Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). A sample HTML page demonstrating the ability to query by filename was written as part of phase I. For phase II, a more complex HTML page will be required which queries for filename and date range. Records will also be populated into an HTML table instead of returning raw JSON. Javascript functions will also be added to sort columns using the [https://datatables.net DataTables jQuery plug-in].
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:46:25Z

Pdscott2: /* Unit Testing */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date, :fail_time]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-28T23:44:10Z

Pdscott2: /* Data model */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure in the form YYYYMMDD
|-
| fail_time
| ISO date (String)
| Time of the failure in the form HH:MM:SS.MMMMMM
|}

=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-13T00:34:42Z

Pdscott2: /* Implementation */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely dictated by the Servo team - they have defined what the service should do and how it should be designed. A standalone working version of the design has been implemented in a [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 Github repository]. The complete list of files created for this project can be examined in this repository. Eventually, this project will be incorporated into the Servo development repository and interfaced with other Servo development software. The details of the implementation are given below.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-13T00:05:11Z

Pdscott2: /* Flask Service */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes are given below:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-12T23:59:42Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given that the fail_date is already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-12T23:57:51Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date already being populated in the database as an ISO date string when records are added, it should be possible to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-08T00:36:25Z

Pdscott2: /* Round 2 Testing Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===
{| class="wikitable"
|-
! Feature
! Testing Infrastructure Required
|-
| Date Range Query Functionality
| New unit tests to ensure query returns proper records
|-
| HTML Front-End
| Functional tests to ensure proper views are returned for each request.
|-
| Servo Integration via filter-intermittents
| Unit and functional testing via Servo
|-
| Servo integration with Salt Stack File System
| Unit and functional testing via Servo
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-08T00:28:00Z

Pdscott2: /* Unit Testing */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

===Round 2 Testing Plan===

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-08T00:24:48Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-08T00:22:29Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in [https://github.com/servo/saltfs Salt Stack File System] (saltfs). This will also require a testing setup for the saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-08T00:17:08Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.
{| class="wikitable"
|-
! Use Case
| Filter intermittent failures by date
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database during specific time frame
|-
! Triggers
| A user submits a query for intermittent failures occurring within a specific date range
|-
! Postconditions
| A collection of intermittent failure records is returned
|-
|}

The second request is to build an HTML front-end to the service to be queried using JavaScript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required JavaScript request mechanism should fulfill the requirements.
{| class="wikitable"
|-
! Use Case
| Interface with Flask service via HTML front-end
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Previously saved intermittent failure records exist in the database, Flask server is operational
|-
! Triggers
| Users select a date range via an HTML form
|-
! Postconditions
| An HTML view is presented showing a pareto failing tests, each linked to the pertinent Github library and sortable by various criteria.
|-
|}

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.
{| class="wikitable"
|-
! Use Case
| Modify "filter-intermittents" command to add entries to database
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Instead of being immediately filtered, the details of the intermittent failures are firstly recorded in the database before being filtered.
|-
! Postconditions
| Entries exist in the database for each occurrence of an intermittent failure.
|-
|}
The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.
{| class="wikitable"
|-
! Use Case
| Propagate failure data into Salt Stack Filesystem
|-
! Primary Actor
| Servo Developer
|-
! Preconditions
| Failure database exists with functionality to add records, Flask server is operational.
|-
! Triggers
| The "filter-intermittents command is issued as part of the automated failure reporting that occurs during continuous integration. Failure information is propagated to the master Salt Stack Filesystem for archival.
|-
! Postconditions
| Entries exist in the Salt Stack Filesystem for each occurrence of an intermittent failure.
|-
|}

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T23:11:39Z

Pdscott2: /* Motivation */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding frequencies of specific failing tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

The second request is to build an HTML front-end to the service to be queried using javascript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required javascript request mechanism should fulfill the requirements.

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.

The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T23:10:27Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

The second request is to build an HTML front-end to the service to be queried using javascript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required javascript request mechanism should fulfill the requirements.

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded for each intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.

The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T23:07:21Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

The second request is to build an HTML front-end to the service to be queried using javascript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required javascript request mechanism should fulfill the requirements.

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

It was requested that we use an existing command (filter-intermittents) In the existing testing_commands.py code as the initiator for saving records. Separate failure records should be recorded foreach intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.

The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T23:05:31Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

The second request is to build an HTML front-end to the service to be queried using javascript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required javascript request mechanism should fulfill the requirements.

The last two steps involve the full integration of this product into the Servo pipeline and will require the forking of the Servo project on Github.

In the given testing_commands.py code, it has been requested that we use an existing command (filter-intermittents) as the initiator for saving records. Separate failure records should be recorded foreach intermittent failure encountered. This modification will provide the actual integration into the Servo framework to allow communication with this tracking system.

The second integration into the Servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T22:58:05Z

Pdscott2: /* Round 2 Design Plan */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

The second request is to build an HTML front-end to the service to be queried using javascript. The user interface should report the results in a useful manner (linking to the pertinent Github location, sorting by different criteria, etc.). The requirements of this request should allow us to repurpose the testing webpages that were built in the first round. Slight modifications and the addition of the required javascript request mechanism should fulfill the requirements.

These two last steps involve the full integration of this product into the servo pipeline and will require the forking of the Servo project on Github.

In the given test_command application we have to make filter-intermittents command record a separate failure for each intermittent failure encountered. This is the actual integration into the servo framework to talk with this tracking system.

The second integration into the servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T22:48:02Z

Pdscott2: /* Subsequent Steps (Round 2) */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

===Round 2 Design Plan===
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

Build a HTML front-end to the service that queries it using JS and reports the results in a useful manner (linking to github, sorting, etc.). For this we should be able to repurpose the testing webpages that we built in the first round. Polishing these up and giving them the required JS request mechanism should suffice.

These two last steps are the full integration of this product into the servo pipeline and will require the forking of the servo project on github.

In the given test_command application we have to make filter-intermittents command record a separate failure for each intermittent failure encountered. This is the actual integration into the servo framework to talk with this tracking system.

The second integration into the servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T22:44:15Z

Pdscott2: /* Motivation */

== Introduction ==
This wiki provides details on new functionality programmed for the Servo OSS project.

===Background===
"[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. Our goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Motivation===
This project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Specifically, the requestors have [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project specified] that a [http://flask.pocoo.org/docs/0.12/ Flask] service be developed using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7] to aid in tracking failures. Intermittent failures frequently occur during development but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolve the most prevalent issues. The intermittent test failure tracker would store information regarding specific tests and also provide a means to quickly query for tests that have failed.

===Tasks===
=====Round 1=====
The intermittent test failure tracker initial steps (for the OSS project) include:
* Build a Flask service
* Use a JSON file to store information
* Record required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Query the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server

=====Round 2=====
Subsequent steps (for the final project) include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to GitHub
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]

== Design ==

===Design Pattern===

The Servo and this project's code follow a [https://en.wikipedia.org/wiki/Service_layers_pattern Service Layer] design pattern. This design pattern breaks up functionality into smaller "services" and applies the services to the topmost "layer" of the project for which they are needed.

===Application Flow===

==== Saving a Test ====
The Servo build agent calls a webhook (a way for an app to provide other applications with real-time information) inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

<pre>
+---------------------------------------------+
| Intermittent Test Failure Tracker |
| |
+--------------+ | +-----------+ +---------+ +------+ |
| | | | | | | | | | +--------+
| Servo | | | | | | | | | | |
| Build +------> webhook +------> handler +----> db +---------> json |
| Server | | | | | | | | | | file |
| | | | | | | | | | | |
+--------------+ | +-----------+ +---------+ +------+ | +--------+
| |
+---------------------------------------------+

</pre>

==Subsequent Steps (Round 2)==
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. This will require a new query function that takes the range as parameters.

Build a HTML front-end to the service that queries it using JS and reports the results in a useful manner (linking to github, sorting, etc.). For this we should be able to repurpose the testing webpages that we built in the first round. Polishing these up and giving them the required JS request mechanism should suffice.

These two last steps are the full integration of this product into the servo pipeline and will require the forking of the servo project on github.

In the given test_command application we have to make filter-intermittents command record a separate failure for each intermittent failure encountered. This is the actual integration into the servo framework to talk with this tracking system.

The second integration into the servo project for this tracker will be to propagate the required information for recording failures in saltfs. This will also require a testing setup for saltfs or at least a mock setup for mimicking the integration into saltfs.

== Implementation ==
The implementation is entirely influenced by the request, the Servo team clearly defines what the service should do and how it would be made.

=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

{| class="wikitable"
|-
! Name
! Type
! Description
|-
| test_file
| String
| Name of the intermittent test file
|-
| platform
| String
| Platform the test failed on
|-
| builder
| String
| The test machine (builder) the test failed on
|-
| number
| Integer
| The GitHub pull request number
|-
| fail_date
| ISO date (String)
| Date of the failure
|}
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human-readable.

=== Flask Service ===
[http://flask.pocoo.org/ Flask] is a [https://en.wikipedia.org/wiki/Microservices microservice] framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

@app.route('/')
def index():
return 'Index page'

@app.route('/user/<username>')
def show_user(username):
return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

== Test Plan ==

=== Functional Testing ===
As a convenience to the testers included in this code base is a set of [http://csc517oss.zachncst.com/ testing web applications] and is only for illustrating the project's functionality.
This simple set of forms allow a tester to exercise the functionality of the [https://en.wikipedia.org/wiki/Representational_state_transfer REST] endpoints without having to write any REST code.
The links on the page lead to demonstrations of the query and record handlers, as well as a display of the JSON file containing all the Intermittent Test Failure records.
All usable for thorough integration testing.

===Unit Testing===
The Unit Tests included in the code exercise the major functions of this system. The tests exercise the addition of a record into the database, the removal of a record given a filename, the retrieval of a record, and the assertion that a record will not be added if any of the record parameters (test_file, platform, builder, number) is missing. All unit tests are in tests.py.

{| class="wikitable"
! colspan="3" | Unit Test Summary
|-
! Test Purpose
! Function Tested
! Parameters
|-
| Add a record to a database
| db.add
| params[:self, :test_file, :platform, :builder, :number, :fail_date]
|-
| Delete a record from database
| db.remove
| params[:test_file]
|-
| Record a new Intermittent failure
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
| Query the Intermittent failure records
| handlers.query
| params[:db, :test_file]
|-
| Record a new Intermittent failure, test invalid values - 4 tests for blanks for each input item
| handlers.record
| params[:db, :test_file, :platform, :builder, :number]
|-
|}

====Running Unit Tests and the App====

Before attempting either of the following, clone the [https://github.com/adamw17/csc517ossproject repo].

=====To Run Unit Tests=====
* In the cloned repo folder, use the command <code>python test.py</code>

=====To Run The App Locally=====
* In the cloned repo folder, use the command <code>python -m flask_server</code>
* To launch the app, go to http://localhost:5000

== Submission/Pull Requests ==

There is no Pull Request because Servo manager Josh Matthews requested that we start a new (non-branched) repository for this project. The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When Servo developers are ready, the project will be pulled in to the Servo project on GitHub. In the interim, we shared our repo with Josh, whose reply was "this looks really great! Thanks for tackling it!"

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T22:37:57Z

Pdscott2: /* Tasks */

CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time

2017-04-07T22:37:10Z

Pdscott2: /* Tasks */

CSC/ECE 517 Spring 2017/oss M1706

2017-04-06T01:01:41Z

Pdscott2: /* Description */

===Description===
This purpose of this project is provide additional testing infrastructure for the Servo OSS project. "[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues.

===Tasks to be completed===

===Current Implementation===

===UML Diagram===

===Proposed Design===

'''TASK 1''' -

'''TASK 2''' -

==== Design Pattern Used ====

====Features to be added====

===Testing Plan===

====Files Changed and Added====

====Models====

====Controllers====

====Views====

===Important Links===

Link to Github repository : https://github.com/adamw17/csc517ossproject

Link to Pull request : The contact for this project asked us to create an entirely new repository. A pull request is not applicable.

===References===

CSC/ECE 517 Spring 2017/oss M1706

2017-04-06T01:00:23Z

Pdscott2: /* Description */

===Description===
This purpose of this project is provide additional testing infrastructure for the [[Servo OSS project]]. "[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues.

===Tasks to be completed===

===Current Implementation===

===UML Diagram===

===Proposed Design===

'''TASK 1''' -

'''TASK 2''' -

==== Design Pattern Used ====

====Features to be added====

===Testing Plan===

====Files Changed and Added====

====Models====

====Controllers====

====Views====

===Important Links===

Link to Github repository : https://github.com/adamw17/csc517ossproject

Link to Pull request : The contact for this project asked us to create an entirely new repository. A pull request is not applicable.

===References===

CSC/ECE 517 Spring 2017/oss M1706

2017-04-06T00:54:49Z

Pdscott2:

===Description===
This purpose of this project is provide additional testing infrastructure for Mozilla Servo OSS project. "[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues.

===Tasks to be completed===

===Current Implementation===

===UML Diagram===

===Proposed Design===

'''TASK 1''' -

'''TASK 2''' -

==== Design Pattern Used ====

====Features to be added====

====Gems to be used====

===Metrics View===

====Instructor View====

====Student View====

===Testing Plan===

====Files Changed and Added====

====Models====

====Controllers====

====Views====

===Important Links===

Link to Github repository :

Link to Pull request :

===References===

CSC/ECE 517 Spring 2017/oss M1706

2017-04-05T20:06:13Z

Pdscott2:

===Description===
This project is designed to provide additional testing infrastructure for Mozilla Servo. "[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.

===Tasks to be completed===

===Current Implementation===

===UML Diagram===

===Proposed Design===

'''TASK 1''' -

'''TASK 2''' -

==== Design Pattern Used ====

====Features to be added====

====Gems to be used====

===Metrics View===

====Instructor View====

====Student View====

===Testing Plan===

====Files Changed and Added====

====Models====

====Controllers====

====Views====

===Important Links===

Link to Github repository :

Link to Pull request :

===References===

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-04-01T00:23:13Z

Pdscott2: /* Create test file named grades_helper_spec.rb in spec/helpers */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file, in order to separate Controller logic from View.
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb. Prior to this project, none of the existing methods in grades_helper.rb were tested using unit tests. The following unit tests were written and used to exercise the methods. An examination of the specific test cases is given below in the Test Plan section. The final two methods in this file are functional tests used to ensure all discrete functions perform normally when combined together.

<pre>
require 'rails_helper'
require 'selenium-webdriver'

describe GradesHelper, type: :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@assignment2 = create(:assignment, name: 'whatever', max_team_size: 3)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
@new_participant = create(:participant, assignment: @assignment)
@participant = create(:participant, assignment: @assignment2)
@assignment_team = create(:assignment_team, assignment: @assignment)
@questionnaire = create(:questionnaire)
@metareview_questionnaire = create(:metareview_questionnaire)
@author_feedback_questionnaire = create(:author_feedback_questionnaire)
@teammate_review_questionnaire = create(:teammate_review_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @metareview_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @author_feedback_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @teammate_review_questionnaire)

@questions = {}
@questions[@questionnaire.symbol] = @questionnaire.questions
@questions[@metareview_questionnaire.symbol] = @metareview_questionnaire.questions
@questions[@author_feedback_questionnaire.symbol] = @author_feedback_questionnaire.questions
@questions[@teammate_review_questionnaire.symbol] = @teammate_review_questionnaire.questions

create(
:assignment_due_date,
assignment: @assignment2,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
params[:id] = @new_participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview after a view action' do
@assignment2.max_team_size = 1
@assignment2.save
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment with a team and with a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant
expect(result).to eq(new_participant)
end
end

describe 'rscore_X' do
it 'should return records of each review type if available' do
params[:id] = @new_participant.id
expect(rscore_review).to_not be_nil
expect(rscore_metareview).to_not be_nil
expect(rscore_feedback).to_not eq(nil)
expect(rscore_teammate).to_not eq(nil)
end
it 'should return nil if review types are not available' do
params[:id] = @participant.id
expect(rscore_review).to be_nil
expect(rscore_metareview).to be_nil
expect(rscore_feedback).to be_nil
expect(rscore_teammate).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
graded_participant = create(:participant, grade: 90)
create(:assignment_questionnaire, user_id: graded_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = graded_participant.id
expect(p_total_score).to eq(90)
end
it 'should return :total_score if no grade is available' do
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = @new_participant.id
expect(p_total_score).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
params[:id] = @new_participant.id
@new_participant.grade = 90
@new_participant.save
expect(p_title).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
params[:id] = @new_participant.id
expect(p_title).to eq(nil)
end
end

describe 'get_css_style_for_X_reputation' do
hamer_input = [-0.1, 0, 0.5, 1, 1.5, 2, 2.1]
lauw_input = [-0.1, 0, 0.2, 0.4, 0.6, 0.8, 0.9]
output = %w(c1 c1 c2 c2 c3 c4 c5)
it 'should return correct css for hamer reputations' do
hamer_input.each_with_index do |e, i|
expect(get_css_style_for_hamer_reputation(e)).to eq(output[i])
end
end
it 'should return correct css for luaw reputations' do
lauw_input.each_with_index do |e, i|
expect(get_css_style_for_lauw_reputation(e)).to eq(output[i])
end
end
end
end

#########################
# Functional Cases
#########################
describe GradesHelper, type: :feature do
before(:each) do
@assignment = create(:assignment)
@assignment_team = create(:assignment_team, assignment: @assignment)
@participant = create(:participant, assignment: @assignment)
create(:team_user, team: @assignment_team, user: User.find(@participant.user_id))
login_as(@participant.name)
visit '/student_task/list'
expect(page).to have_content 'final2'
click_link('final2')
end
describe 'case 1' do
it "Javascript should work on grades Alternate View", js: true do
expect(page).to have_content 'Alternate View'
expect(page).to have_content 'Review'
click_link('Alternate View')
expect(page).to have_content 'Grade for submission'
end
end
describe 'case 2' do
it "Student should be able to view scores", js: true do
expect(page).to have_content 'Your scores'
click_link('Your scores')
expect(page).to have_content '0.00%'
end
end
end

</pre>

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-04-01T00:17:33Z

Pdscott2: /* Create test file named grades_helper_spec.rb in spec/helpers */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file, in order to separate Controller logic from View.
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb

<pre>
require 'rails_helper'
require 'selenium-webdriver'

describe GradesHelper, type: :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@assignment2 = create(:assignment, name: 'whatever', max_team_size: 3)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
@new_participant = create(:participant, assignment: @assignment)
@participant = create(:participant, assignment: @assignment2)
@assignment_team = create(:assignment_team, assignment: @assignment)
@questionnaire = create(:questionnaire)
@metareview_questionnaire = create(:metareview_questionnaire)
@author_feedback_questionnaire = create(:author_feedback_questionnaire)
@teammate_review_questionnaire = create(:teammate_review_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @metareview_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @author_feedback_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @teammate_review_questionnaire)

@questions = {}
@questions[@questionnaire.symbol] = @questionnaire.questions
@questions[@metareview_questionnaire.symbol] = @metareview_questionnaire.questions
@questions[@author_feedback_questionnaire.symbol] = @author_feedback_questionnaire.questions
@questions[@teammate_review_questionnaire.symbol] = @teammate_review_questionnaire.questions

create(
:assignment_due_date,
assignment: @assignment2,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
params[:id] = @new_participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview after a view action' do
@assignment2.max_team_size = 1
@assignment2.save
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment with a team and with a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant
expect(result).to eq(new_participant)
end
end

describe 'rscore_X' do
it 'should return records of each review type if available' do
params[:id] = @new_participant.id
expect(rscore_review).to_not be_nil
expect(rscore_metareview).to_not be_nil
expect(rscore_feedback).to_not eq(nil)
expect(rscore_teammate).to_not eq(nil)
end
it 'should return nil if review types are not available' do
params[:id] = @participant.id
expect(rscore_review).to be_nil
expect(rscore_metareview).to be_nil
expect(rscore_feedback).to be_nil
expect(rscore_teammate).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
graded_participant = create(:participant, grade: 90)
create(:assignment_questionnaire, user_id: graded_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = graded_participant.id
expect(p_total_score).to eq(90)
end
it 'should return :total_score if no grade is available' do
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = @new_participant.id
expect(p_total_score).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
params[:id] = @new_participant.id
@new_participant.grade = 90
@new_participant.save
expect(p_title).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
params[:id] = @new_participant.id
expect(p_title).to eq(nil)
end
end

describe 'get_css_style_for_X_reputation' do
hamer_input = [-0.1, 0, 0.5, 1, 1.5, 2, 2.1]
lauw_input = [-0.1, 0, 0.2, 0.4, 0.6, 0.8, 0.9]
output = %w(c1 c1 c2 c2 c3 c4 c5)
it 'should return correct css for hamer reputations' do
hamer_input.each_with_index do |e, i|
expect(get_css_style_for_hamer_reputation(e)).to eq(output[i])
end
end
it 'should return correct css for luaw reputations' do
lauw_input.each_with_index do |e, i|
expect(get_css_style_for_lauw_reputation(e)).to eq(output[i])
end
end
end
end

#########################
# Functional Cases
#########################
describe GradesHelper, type: :feature do
before(:each) do
@assignment = create(:assignment)
@assignment_team = create(:assignment_team, assignment: @assignment)
@participant = create(:participant, assignment: @assignment)
create(:team_user, team: @assignment_team, user: User.find(@participant.user_id))
login_as(@participant.name)
visit '/student_task/list'
expect(page).to have_content 'final2'
click_link('final2')
end
describe 'case 1' do
it "Javascript should work on grades Alternate View", js: true do
expect(page).to have_content 'Alternate View'
expect(page).to have_content 'Review'
click_link('Alternate View')
expect(page).to have_content 'Grade for submission'
end
end
describe 'case 2' do
it "Student should be able to view scores", js: true do
expect(page).to have_content 'Your scores'
click_link('Your scores')
expect(page).to have_content '0.00%'
end
end
end

</pre>

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-04-01T00:13:33Z

Pdscott2: /* Create test file named grades_helper_spec.rb in spec/helpers */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file, in order to separate Controller logic from View.
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
require 'rails_helper'
require 'selenium-webdriver'

describe GradesHelper, type: :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@assignment2 = create(:assignment, name: 'whatever', max_team_size: 3)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
@new_participant = create(:participant, assignment: @assignment)
@participant = create(:participant, assignment: @assignment2)
@assignment_team = create(:assignment_team, assignment: @assignment)
@questionnaire = create(:questionnaire)
@metareview_questionnaire = create(:metareview_questionnaire)
@author_feedback_questionnaire = create(:author_feedback_questionnaire)
@teammate_review_questionnaire = create(:teammate_review_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @metareview_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @author_feedback_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @teammate_review_questionnaire)

@questions = {}
@questions[@questionnaire.symbol] = @questionnaire.questions
@questions[@metareview_questionnaire.symbol] = @metareview_questionnaire.questions
@questions[@author_feedback_questionnaire.symbol] = @author_feedback_questionnaire.questions
@questions[@teammate_review_questionnaire.symbol] = @teammate_review_questionnaire.questions

create(
:assignment_due_date,
assignment: @assignment2,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
params[:id] = @new_participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview after a view action' do
@assignment2.max_team_size = 1
@assignment2.save
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment with a team and with a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant
expect(result).to eq(new_participant)
end
end

describe 'rscore_X' do
it 'should return records of each review type if available' do
params[:id] = @new_participant.id
expect(rscore_review).to_not be_nil
expect(rscore_metareview).to_not be_nil
expect(rscore_feedback).to_not eq(nil)
expect(rscore_teammate).to_not eq(nil)
end
it 'should return nil if review types are not available' do
params[:id] = @participant.id
expect(rscore_review).to be_nil
expect(rscore_metareview).to be_nil
expect(rscore_feedback).to be_nil
expect(rscore_teammate).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
graded_participant = create(:participant, grade: 90)
create(:assignment_questionnaire, user_id: graded_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = graded_participant.id
expect(p_total_score).to eq(90)
end
it 'should return :total_score if no grade is available' do
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = @new_participant.id
expect(p_total_score).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
params[:id] = @new_participant.id
@new_participant.grade = 90
@new_participant.save
expect(p_title).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
params[:id] = @new_participant.id
expect(p_title).to eq(nil)
end
end

describe 'get_css_style_for_X_reputation' do
hamer_input = [-0.1, 0, 0.5, 1, 1.5, 2, 2.1]
lauw_input = [-0.1, 0, 0.2, 0.4, 0.6, 0.8, 0.9]
output = %w(c1 c1 c2 c2 c3 c4 c5)
it 'should return correct css for hamer reputations' do
hamer_input.each_with_index do |e, i|
expect(get_css_style_for_hamer_reputation(e)).to eq(output[i])
end
end
it 'should return correct css for luaw reputations' do
lauw_input.each_with_index do |e, i|
expect(get_css_style_for_lauw_reputation(e)).to eq(output[i])
end
end
end
end

Functional Cases

describe GradesHelper, type: :feature do
before(:each) do
@assignment = create(:assignment)
@assignment_team = create(:assignment_team, assignment: @assignment)
@participant = create(:participant, assignment: @assignment)
create(:team_user, team: @assignment_team, user: User.find(@participant.user_id))
login_as(@participant.name)
visit '/student_task/list'
expect(page).to have_content 'final2'
click_link('final2')
end
describe 'case 1' do
it "Javascript should work on grades Alternate View", js: true do
expect(page).to have_content 'Alternate View'
expect(page).to have_content 'Review'
click_link('Alternate View')
expect(page).to have_content 'Grade for submission'
end
end
describe 'case 2' do
it "Student should be able to view scores", js: true do
expect(page).to have_content 'Your scores'
click_link('Your scores')
expect(page).to have_content '0.00%'
end
end
end

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-04-01T00:13:10Z

Pdscott2: /* Create test file named grades_helper_spec.rb in spec/helpers */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file, in order to separate Controller logic from View.
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
require 'rails_helper'
require 'selenium-webdriver'

describe GradesHelper, type: :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@assignment2 = create(:assignment, name: 'whatever', max_team_size: 3)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
@new_participant = create(:participant, assignment: @assignment)
@participant = create(:participant, assignment: @assignment2)
@assignment_team = create(:assignment_team, assignment: @assignment)
@questionnaire = create(:questionnaire)
@metareview_questionnaire = create(:metareview_questionnaire)
@author_feedback_questionnaire = create(:author_feedback_questionnaire)
@teammate_review_questionnaire = create(:teammate_review_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @metareview_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @author_feedback_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @teammate_review_questionnaire)

@questions = {}
@questions[@questionnaire.symbol] = @questionnaire.questions
@questions[@metareview_questionnaire.symbol] = @metareview_questionnaire.questions
@questions[@author_feedback_questionnaire.symbol] = @author_feedback_questionnaire.questions
@questions[@teammate_review_questionnaire.symbol] = @teammate_review_questionnaire.questions

create(
:assignment_due_date,
assignment: @assignment2,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
params[:id] = @new_participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview after a view action' do
@assignment2.max_team_size = 1
@assignment2.save
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment with a team and with a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant
expect(result).to eq(new_participant)
end
end

describe 'rscore_X' do
it 'should return records of each review type if available' do
params[:id] = @new_participant.id
expect(rscore_review).to_not be_nil
expect(rscore_metareview).to_not be_nil
expect(rscore_feedback).to_not eq(nil)
expect(rscore_teammate).to_not eq(nil)
end
it 'should return nil if review types are not available' do
params[:id] = @participant.id
expect(rscore_review).to be_nil
expect(rscore_metareview).to be_nil
expect(rscore_feedback).to be_nil
expect(rscore_teammate).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
graded_participant = create(:participant, grade: 90)
create(:assignment_questionnaire, user_id: graded_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = graded_participant.id
expect(p_total_score).to eq(90)
end
it 'should return :total_score if no grade is available' do
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = @new_participant.id
expect(p_total_score).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
params[:id] = @new_participant.id
@new_participant.grade = 90
@new_participant.save
expect(p_title).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
params[:id] = @new_participant.id
expect(p_title).to eq(nil)
end
end

describe 'get_css_style_for_X_reputation' do
hamer_input = [-0.1, 0, 0.5, 1, 1.5, 2, 2.1]
lauw_input = [-0.1, 0, 0.2, 0.4, 0.6, 0.8, 0.9]
output = %w(c1 c1 c2 c2 c3 c4 c5)
it 'should return correct css for hamer reputations' do
hamer_input.each_with_index do |e, i|
expect(get_css_style_for_hamer_reputation(e)).to eq(output[i])
end
end
it 'should return correct css for luaw reputations' do
lauw_input.each_with_index do |e, i|
expect(get_css_style_for_lauw_reputation(e)).to eq(output[i])
end
end
end
end

# Functional Cases

describe GradesHelper, type: :feature do
before(:each) do
@assignment = create(:assignment)
@assignment_team = create(:assignment_team, assignment: @assignment)
@participant = create(:participant, assignment: @assignment)
create(:team_user, team: @assignment_team, user: User.find(@participant.user_id))
login_as(@participant.name)
visit '/student_task/list'
expect(page).to have_content 'final2'
click_link('final2')
end
describe 'case 1' do
it "Javascript should work on grades Alternate View", js: true do
expect(page).to have_content 'Alternate View'
expect(page).to have_content 'Review'
click_link('Alternate View')
expect(page).to have_content 'Grade for submission'
end
end
describe 'case 2' do
it "Student should be able to view scores", js: true do
expect(page).to have_content 'Your scores'
click_link('Your scores')
expect(page).to have_content '0.00%'
end
end
end

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-04-01T00:12:21Z

Pdscott2: /* Write test cases for all methods in grades_helper.rb by using factories */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file, in order to separate Controller logic from View.
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
require 'rails_helper'
require 'selenium-webdriver'

describe GradesHelper, type: :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@assignment2 = create(:assignment, name: 'whatever', max_team_size: 3)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
@new_participant = create(:participant, assignment: @assignment)
@participant = create(:participant, assignment: @assignment2)
@assignment_team = create(:assignment_team, assignment: @assignment)
@questionnaire = create(:questionnaire)
@metareview_questionnaire = create(:metareview_questionnaire)
@author_feedback_questionnaire = create(:author_feedback_questionnaire)
@teammate_review_questionnaire = create(:teammate_review_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @metareview_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @author_feedback_questionnaire)
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @teammate_review_questionnaire)

@questions = {}
@questions[@questionnaire.symbol] = @questionnaire.questions
@questions[@metareview_questionnaire.symbol] = @metareview_questionnaire.questions
@questions[@author_feedback_questionnaire.symbol] = @author_feedback_questionnaire.questions
@questions[@teammate_review_questionnaire.symbol] = @teammate_review_questionnaire.questions

create(
:assignment_due_date,
assignment: @assignment2,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
params[:id] = @new_participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview after a view action' do
@assignment2.max_team_size = 1
@assignment2.save
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment with a team and with a metareview after a view action' do
params[:action] = 'view'
params[:id] = @assignment2.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant
expect(result).to eq(new_participant)
end
end

describe 'rscore_X' do
it 'should return records of each review type if available' do
params[:id] = @new_participant.id
expect(rscore_review).to_not be_nil
expect(rscore_metareview).to_not be_nil
expect(rscore_feedback).to_not eq(nil)
expect(rscore_teammate).to_not eq(nil)
end
it 'should return nil if review types are not available' do
params[:id] = @participant.id
expect(rscore_review).to be_nil
expect(rscore_metareview).to be_nil
expect(rscore_feedback).to be_nil
expect(rscore_teammate).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
graded_participant = create(:participant, grade: 90)
create(:assignment_questionnaire, user_id: graded_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = graded_participant.id
expect(p_total_score).to eq(90)
end
it 'should return :total_score if no grade is available' do
create(:assignment_questionnaire, user_id: @new_participant.id, questionnaire: @questionnaire)
@questions[@questionnaire.symbol] = @questionnaire.questions
params[:id] = @new_participant.id
expect(p_total_score).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
params[:id] = @new_participant.id
@new_participant.grade = 90
@new_participant.save
expect(p_title).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
params[:id] = @new_participant.id
expect(p_title).to eq(nil)
end
end

describe 'get_css_style_for_X_reputation' do
hamer_input = [-0.1, 0, 0.5, 1, 1.5, 2, 2.1]
lauw_input = [-0.1, 0, 0.2, 0.4, 0.6, 0.8, 0.9]
output = %w(c1 c1 c2 c2 c3 c4 c5)
it 'should return correct css for hamer reputations' do
hamer_input.each_with_index do |e, i|
expect(get_css_style_for_hamer_reputation(e)).to eq(output[i])
end
end
it 'should return correct css for luaw reputations' do
lauw_input.each_with_index do |e, i|
expect(get_css_style_for_lauw_reputation(e)).to eq(output[i])
end
end
end
end

#########################
# Functional Cases
#########################
describe GradesHelper, type: :feature do
before(:each) do
@assignment = create(:assignment)
@assignment_team = create(:assignment_team, assignment: @assignment)
@participant = create(:participant, assignment: @assignment)
create(:team_user, team: @assignment_team, user: User.find(@participant.user_id))
login_as(@participant.name)
visit '/student_task/list'
expect(page).to have_content 'final2'
click_link('final2')
end
describe 'case 1' do
it "Javascript should work on grades Alternate View", js: true do
expect(page).to have_content 'Alternate View'
expect(page).to have_content 'Review'
click_link('Alternate View')
expect(page).to have_content 'Grade for submission'
end
end
describe 'case 2' do
it "Student should be able to view scores", js: true do
expect(page).to have_content 'Your scores'
click_link('Your scores')
expect(page).to have_content '0.00%'
end
end
end

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-23T00:33:25Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==

The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written using RSpec/FactoryGirl/Selenium and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.
===Functional Tests===

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

===Unit Tests===
Unit tests were required per the project assignment for helper methods which previously had no associated unit tests. These tests verified that each discrete method returned the proper values. The tests were written using RSpec/FactoryGirl and are listed in the code above. A summary of the test cases is given below.

{| class="wikitable"
! colspan="4" | Unit Test Summary
|-
! Method
! Parameters
! Purpose
! Tested Scenarios
|-
| get_accordion_title
| last_topic, new_topic
| Render a proper partial for questionnaires
| last_topic=nil; new_topic=nil; neither=nil
|-
| has_team_and_metareview?
| params[:id]
| Determine whether a team and reviews exist for a given assignment
| find an assignment given assignment_id; find an assignment given participant_id; return 1 for a case with a team but no meta review; return 1 for a case with a meta review but no team; return 2 for a case with a team and metareview
|-
| participant
| params[:id]
| Returns a participant given an id
| find a newly created participant
|-
| rscore_review
| params[:id]
| returns all the reviews for a participant based on id
| return reviews from a participant with reviews; return nothing for a participant without reviews.
|-
| rscore_metareview
| params[:id]
| returns all the metareviews for a participant based on id
| return metareviews from a participant with metareviews; return nothing for a participant without metareviews.
|-
| rscore_feedback
| params[:id]
| returns all the author feedback for a participant based on id
| returns feedback for a participant with feedback; return nothing for a participant without feedback.
|-
|-
| rscore_teammate
| params[:id]
| returns teammate reviews for a participant based on id
| returns teammate reviews for a participant with teammate reviews; return nothing for a participant without teammate reviews.
|-
| p_total_score
| params[:id]
| returns grade for a participant based on id
| returns grade for a participant with grade; returns total_score for a participant without grade.
|-
| p_title
| params[:id]
| returns a pertinent title for the grades view
| returns text title for a participant with grade; returns nothing for a participant without grade.
|-
| get_css_style_for_hamer_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.5 yields CSS c2; rep 1 yields CSS c2; rep 1.5 yields CSS c3, rep 2 yields CSS c4; rep 2.1 yields css c5
|-
| get_css_style_for_lauw_reputation
| reputation_value
| returns a CSS value for formatting based on reputation
| rep -0.1 yields CSS c1; rep 0 yields CSS c1; rep 0.2 yields CSS c2; rep 0.4 yields CSS c2; rep 0.6 yields CSS c3, rep 0.8 yields CSS c4; rep 0.9 yields css c5
|-
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-22T23:44:54Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==
The main goal of testing was to ensure functionality was maintained after refactoring was completed. The following test cases exercise the functionality of the code sections which were refactored. Automated versions of these tests were written and appear in on the Github repository associated with this project. The functional tests may also be run manually per the descriptions below.

{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-22T23:40:42Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==
{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza as a student
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-22T23:39:18Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==
{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student2064
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to Expertiza
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-22T23:29:59Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==
{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student2064
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test _participant.html.erb to ensure it is working after refactoring logic code
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assignment as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Your Scores"
# On the "Score for OSS Project" screen, ensure that the scores are loaded correctly.
# Averages should be 99.2, 90, and 60 for Submitted Work, Reviewing, and Author Feedback, respectively.
# The Final Score should be 99.2%.
|-
! Test Execution using existing login
| [Insert test execution steps using existing login]
|}

E1728. Remove useless partials from grades view and move view logic to grades helper.rb

2017-03-22T22:55:51Z

Pdscott2: /* Test Plans */

==Introduction==
This wiki provides details on the refactoring tasks that were undertaken as part of the continuous improvement to the Expertiza project
===Background===
[[Expertiza_documentation|Expertiza]] is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

The application provides a complete system through which students and instructors collaborate on the learning objects as well as submit, review and grade assignments for the courses.

===Motivation===
By participating in the overall refactoring effort as part of the continuous improvement of Expertiza, students get an opportunity to work on a open source software project. This helps them gain exposure on the technologies used in the project as well as much needed experience in collaborating with peers as part of the software development process.

===Tasks===
The tasks involved as part of this refactoring effort were geared towards cleaning up the grade view logic.

====Initial Task List====
The initial set of tasks were:
* For files: _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb
# Move javascript code to assets
* For files: _scores_header.html.erb
# Move logical code (such as L43-96) to helper file and assign self-explanatory method name
* For files: _participant.html.erb, view_team.html.erb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name
# Such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb

====Revised Task List====
On working with files _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, the team came to find out that these files were not being used anymore in the application and the overall tasks were updated to the following:
* Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.
* For files _participant.html.erb, view_team.html.erb to grades_helper.rb
# Move javascript code to assets
# Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb
* Create test file named grades_helper_spec.rb in spec/helpers
* Write test cases for all methods in grades_helper.rb by using factories

==Refactoring Tasks==
===Remove useless partials from grades view, such as _scores_author_feedback.html.erb, _scores_metareview.html.erb, _scores_submitted_work.html.erb, _scores_header.html.erb, etc.===
The named files were removed from the project and the deletions were committed to the repository

===For files _participant.html.erb, view_team.html.erb to grades_helper.rb===
====Move javascript code to assets====
A new file was created and added to the project: app/assets/javascripts/grades/view_team.js

For the view_team.html.erb file, the javascript code was moved to view_team.js
<pre>
$=jQuery;

$(function () {
$("[data-toggle='tooltip']").tooltip();
$("#scoresTable").tablesorter();
});

var lesser = false;
// Function to sort the columns based on the total review score
function col_sort(m) {
lesser = !lesser
// Swaps two columns of the table
jQuery.moveColumn = function (table, from, to) {
var rows = jQuery('tr', table);

var hidden_child_row = table.find('tr.tablesorter-childRow');

hidden_child_row.each(function () {
inner_table = jQuery(this).find('table.tbl_questlist')
hidden_table = inner_table.eq(0).find('tr')

hidden_table.eq(from - 1).detach().insertBefore(hidden_table.eq(to - 1));
if (from - to > 1) {
hidden_table.eq(to - 1).detach().insertAfter((hidden_table.eq(from - 2)));

}

});

var cols;
rows.each(function () {
cols = jQuery(this).children('th, td');
cols.eq(from).detach().insertBefore(cols.eq(to));
if (from - to > 1) {
cols.eq(to).detach().insertAfter((cols.eq(from - 1)));

}
});
}

// Gets all the table with the class "tbl_heat"
var tables = $("table.tbl_heat");
// Get all the rows with the class accordion-toggle
var tbr = tables.eq(m).find('tr.accordion-toggle');
// Get the cells from the last row of the table
var columns = tbr.eq(tbr.length - 1).find('td');
// Init an array to hold the review total
var sum_array = [];
// iterate through the rows and calculate the total of each review
for (var l = 2; l < columns.length - 2; l++) {
var total = 0;
for (var n = 0; n < tbr.length; n++) {
var row_slice = tbr.eq(n).find('td');
if (parseInt(row_slice[l].innerHTML) > 0) {
total = total + parseInt(row_slice[l].innerHTML)
}
}
sum_array.push(total)
}

// The sorting algorithm
for (var i = 3; i < columns.length - 2; i++) {
var j = i;
while (j > 2 && compare(sum_array[j - 2], sum_array[j - 3], lesser)) {
var tmp
tmp = sum_array[j - 3]
sum_array[j - 3] = sum_array[j - 2]
sum_array[j - 2] = tmp
jQuery.moveColumn($("table.tbl_heat").eq(m), j, j - 1);
// This part is repeated since the table is updated
tables = $("table.tbl_heat")
tbr = tables.eq(m).find('tr.accordion-toggle');
columns = tbr.eq(tbr.length - 1).find('td')
j = j - 1;

}
}
}

// Function to return boolean based on lesser or greater operator
function compare(a, b, less) {
if (less) {
return a < b
} else {
return a > b
}
}</pre>
====Move logical code to helper file and assign self-explanatory method name such as L8-22 in _participant.html.erb====
The following lines of code were removed
<pre>
<%
participant = pscore[:participant]
if pscore[:review]
@rscore_review=Rscore.new(pscore,:review)
end
if pscore[:metareview]
@rscore_metareview=Rscore.new(pscore,:metareview)
end
if pscore[:feedback]
@rscore_feedback=Rscore.new(pscore,:feedback)
end
if pscore[:teammate]
@rscore_teammate=Rscore.new(pscore,:teammate)
end
%>
</pre>
and converted to properties in the GradesHelper module defined in the app/helpers/grades_helper.rb file
<pre>
def participant
@participant = Participant.find(params[:id])
end

def rscore_review
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:review]
@rscore_review=Rscore.new(@pscore,:review)
end
@rscore_review
end

def rscore_metareview
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:metareview]
@rscore_metareview=Rscore.new(@pscore,:metareview)
end
@rscore_metareview
end

def rscore_feedback
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:feedback]
@rscore_feedback=Rscore.new(@pscore,:feedback)
end
@rscore_feedback
end

def rscore_teammate
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @pscore[:teammate]
@rscore_teammate=Rscore.new(@pscore,:teammate)
end
@rscore_teammate
end

def p_total_score
@participant = Participant.find(params[:id])
@pscore = @participant.scores(@questions)
if @participant.grade
@total_score = participant.grade
else
@total_score = @pscore[:total_score]
end
@total_score
end

def p_title
@participant = Participant.find(params[:id])
if @participant.grade
@title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant."
else
@title = nil
end
@title
end
</pre>

The following lines of code in the _participant.html.erb file were also replaced to use the above properties created

{| class="wikitable"
|-
! Original
! Replacement
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
</pre>
|-
| <pre><%= @rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_review.my_avg): @rscore_review.my_avg %>%<BR/></pre>
| <pre><%= rscore_review.my_avg.is_a?(Float)? sprintf("%.2f",rscore_review.my_avg): rscore_review.my_avg %>%<BR/></pre>
|-
| <pre><%= @rscore_review.my_min.is_a?(Float)? sprintf("%.0f",@rscore_review.my_min): @rscore_review.my_min %>% - <%= @rscore_review.my_max.is_a?(Float)? sprintf("%.0f",@rscore_review.my_max): @rscore_review.my_max %>%</pre>
| <pre><%= rscore_review.my_min.is_a?(Float)? sprintf("%.0f",rscore_review.my_min): rscore_review.my_min %>% - <%= rscore_review.my_max.is_a?(Float)? sprintf("%.0f",rscore_review.my_max): rscore_review.my_max %>%</pre>
|-
| <pre><% if @rscore_metareview && @rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_metareview.my_avg):@rscore_metareview.my_avg %>%</pre>
| <pre><% if rscore_metareview && rscore_metareview.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_avg.is_a?(Float)? sprintf("%.2f",rscore_metareview.my_avg):rscore_metareview.my_avg %>%</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",@rscore_metareview.my_min):@rscore_metareview.my_min %>% - <%= @rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",@rscore_metareview.my_max):@rscore_metareview.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_metareview.my_min.is_a?(Float)? sprintf("%.0f",rscore_metareview.my_min):rscore_metareview.my_min %>% - <%= rscore_metareview.my_max.is_a?(Float)?sprintf("%.0f",rscore_metareview.my_max):rscore_metareview.my_max %>%
</pre>
|-
| <pre>
<% if !@rscore_feedback.nil? && @rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",@rscore_feedback.my_avg): @rscore_feedback.my_avg %>%
</pre>
| <pre>
<% if !rscore_feedback.nil? && rscore_feedback.my_avg %>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_avg.is_a?(Float)? sprintf("%.2f",rscore_feedback.my_avg): rscore_feedback.my_avg %>%
</pre>
|-
| <pre><TD ALIGN="CENTER" VALIGN="TOP"><%= @rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_min): @rscore_feedback.my_min %>% - <%= @rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",@rscore_feedback.my_max):@rscore_feedback.my_max %>%
</pre>
| <pre>
<TD ALIGN="CENTER" VALIGN="TOP"><%= rscore_feedback.my_min.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_min): rscore_feedback.my_min %>% - <%= rscore_feedback.my_max.is_a?(Float)? sprintf("%.0f",rscore_feedback.my_max):rscore_feedback.my_max %>%
</pre>
|-
| <pre><% if @rscore_teammate and @rscore_teammate.my_avg %></pre>
| <pre><% if rscore_teammate and rscore_teammate.my_avg %></pre>
|-
| <pre>
<% range = @rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_min) : @rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += @rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",@rscore_teammate.my_max) : @rscore_teammate.my_max.to_s + '%' %>
</pre>
| <pre>
<% range = rscore_teammate.my_min.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_min) : rscore_teammate.my_min.to_s + '%' + ' - ' %>
<% range += rscore_teammate.my_max.is_a?(Float) ? sprintf("%.0f",rscore_teammate.my_max) : rscore_teammate.my_max.to_s + '%' %>
</pre>
|-
| <pre>
<% if participant.grade %>
<% total_score = participant.grade %>
<% title = "A score in blue indicates that the value was overwritten by the instructor or teaching assistant." %>
<% else %>
<% total_score = pscore[:total_score] %>
<% title = nil %>
<% end %>

<div <% if title %>title="<%=title%>" style="color:#0033FF"<% end %>><%= total_score==(-1)? "N/A": sprintf("%.2f",total_score) %><%= score_postfix %></div>
</pre>
| <pre><div <% if p_title %>title="<%=p_title%>" style="color:#0033FF"<% end %>><%= p_total_score==(-1)? "N/A": sprintf("%.2f",p_total_score) %><%= score_postfix %></div></pre>
|-
| <pre>
<% if !@rscore_review.nil? && @rscore_review.my_avg %>
<%= @rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",@rscore_review.my_avg):@rscore_review.my_avg %><%= score_postfix %>
</pre>
| <pre>
<% if !rscore_review.nil? && rscore_review.my_avg %>
<%= rscore_review.my_avg.is_a?(Float)?sprintf("%.2f",rscore_review.my_avg):rscore_review.my_avg %><%= score_postfix %>
</pre>

|}

===Create test file named grades_helper_spec.rb in spec/helpers===
A new test file was created and added to the project: spec/helpers/grades_helper_spec.rb
===Write test cases for all methods in grades_helper.rb by using factories===
The following test cases were added to test all methods in grades_helper.rb
<pre>
require 'rails_helper'

describe GradesHelper, :type => :helper do
before(:each) do
@assignment = create(:assignment, max_team_size: 1)
@deadline_type = create(:deadline_type, id: 5, name: 'metareview')
@deadline_right = create(:deadline_right)
end

describe 'get_accordion_title' do
it 'should render is_first:true if last_topic is nil' do
get_accordion_title(nil, 'last question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'last question', is_first: true})
end
it 'should render is_first:false if last_topic is not equal to next_topic' do
get_accordion_title('last question', 'next question')
expect(response).to render_template(partial: 'response/_accordion', locals: {title: 'next question', is_first: false})
end
it 'should render nothing if last_topic is equal to next_topic' do
get_accordion_title('question', 'question')
expect(response).to render_template(nil)
end
end

describe 'has_team_and_metareview?' do
it 'should correctly identify the assignment from an assignment id' do
params[:id] = @assignment.id
result = Assignment.find(params[:id])
expect(result).to eq(@assignment)
end
it 'should correctly identify the assignment from a participant id' do
participant = create(:participant, assignment: @assignment)
params[:id] = participant.id
result = Participant.find(params[:id]).parent_id
expect(result).to eq(@assignment.id)
end
it 'should return 0 for an assignment without a team or a metareview deadline after a view action' do
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: false, true_num: 0}
end
it 'should return 1 for an assignment with a team but no metareview deadline after a view action' do
@assignment.max_team_size = 2
@assignment.save
params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: false, true_num: 1}
end
it 'should return 1 for an assignment without a team but with a metareview deadline after a view action' do
@assignment.max_team_size = 1
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: false, has_metareview: true, true_num: 1}
end
it 'should return 2 for an assignment without a team but with a metareview after a view action' do
@assignment.max_team_size = 3
@assignment.save
@assignment_due_date = create(:assignment_due_date, assignment: @assignment, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

params[:action] = 'view'
params[:id] = @assignment.id
result = has_team_and_metareview?
expect(result).to be == {has_team: true, has_metareview: true, true_num: 2}
end
end

describe 'participant' do
it 'should return the correct particpant' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = participant()
expect(result).to eq(new_participant)
end
end

describe 'rscore_review' do
it 'should return a record of type :review if available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :review is available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_review()
expect(result).to be_nil
end
end

describe 'rscore_metareview' do
it 'should return a record of type :metareview if available' do
new_participant = create(:participant)
questionnaire = create(:metareview_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :metareview is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_metareview()
expect(result).to be_nil
end
end

describe 'rscore_feedback' do
it 'should return a record of type :feedback if available' do
new_participant = create(:participant)
questionnaire = create(:author_feedback_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :feedback is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_feedback()
expect(result).to be_nil
end
end

describe 'rscore_teammate' do
it 'should return a record of type :teammate if available' do
new_participant = create(:participant)
questionnaire = create(:teammate_review_questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to_not be_nil
end
it 'should return nil if no record of type :teammate is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = rscore_teammate()
expect(result).to be_nil
end
end

describe 'p_total_score' do
it 'should return the grade if available' do
new_participant = create(:participant, grade: 90)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(90)
end
it 'should return :total_score if no grade is available' do
new_participant = create(:participant)
questionnaire = create(:questionnaire)
assignment_questionnaire = create(:assignment_questionnaire, user_id: new_participant.id, questionnaire: questionnaire)
@questions = {}
@questions[questionnaire.symbol] = questionnaire.questions
params[:id] = new_participant.id
result = p_total_score()
expect(result).to eq(0)
end
end

describe 'p_title' do
it 'should return a title when the participant has a grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
new_participant.grade = 90
new_participant.save
result = p_title()
expect(result).to eq('A score in blue indicates that the value was overwritten by the instructor or teaching assistant.')
end
it 'should return nil when the participant has no grade' do
new_participant = create(:participant)
params[:id] = new_participant.id
result = p_title()
expect(result).to eq(nil)
end
end

describe 'get_css_style_for_hamer_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_hamer_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_hamer_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.5' do
result = get_css_style_for_hamer_reputation(0.5)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1' do
result = get_css_style_for_hamer_reputation(1)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 1.5' do
result = get_css_style_for_hamer_reputation(1.5)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 2' do
result = get_css_style_for_hamer_reputation(2)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 2.1' do
result = get_css_style_for_hamer_reputation(2.1)
expect(result).to be == 'c5'
end
end

describe 'get_css_style_for_lauw_reputation' do
it 'should return correct css for a reputation of -0.1' do
result = get_css_style_for_lauw_reputation(-0.1)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0' do
result = get_css_style_for_lauw_reputation(0)
expect(result).to be == 'c1'
end
it 'should return correct css for a reputation of 0.2' do
result = get_css_style_for_lauw_reputation(0.2)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.4' do
result = get_css_style_for_lauw_reputation(0.4)
expect(result).to be == 'c2'
end
it 'should return correct css for a reputation of 0.6' do
result = get_css_style_for_lauw_reputation(0.6)
expect(result).to be == 'c3'
end
it 'should return correct css for a reputation of 0.8' do
result = get_css_style_for_lauw_reputation(0.8)
expect(result).to be == 'c4'
end
it 'should return correct css for a reputation of 0.9' do
result = get_css_style_for_lauw_reputation(0.9)
expect(result).to be == 'c5'
end
end
end
</pre>

==Test Plans==
{| class="wikitable"
! colspan="2" | Test Case 1
|-
! Test URL
| http://csc517.eastus.cloudapp.azure.com:8080
|-
| colspan="2" |  
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if javascript changes for view_team.html.erb are working
|-
! Pre-Conditions
|
Make sure student to test with has the following:
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
|
# Login to the site as a student2064
# Click on "Assignments" on the top menu
# Select an assignment from the list
# On the "Submit or Review work for Expertiza" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
! Test Execution using existing login
|
# Login as "student2064"
# Click on "Assignments" on the top menu
# Select assignment "OSS project" from the list
# On the "Submit or Review work for OSS project" screen, click on "Alternate View" on the "Your Scores" line item
# On the "Summary Report for assignment" screen, test if the "Sort by total review score" button works and doesn't throw any javascript errors
|-
| colspan="2" |  
|-
! colspan="2" | Test Case 2
|-
! Test Type
| Functional
|-
! Scenario
| Test to see if logic elimination from _participant.html.erb is working
|-
! Pre-Conditions
|
# Has one course assigned
# Has one assigned as part of that course
# Has more than one review for that assignment
|-
! Description
| [Insert description here]
|-
! Test Execution using existing login
| [Insert test execution steps using existing login]
|}