Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-12T04:03:34Z

Meschwei: /* Test Plan */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> and Capybara<ref>[https://github.com/jnicklas/capybara]</ref> using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref>. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
===RSpec===

Rspec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> is Behavior Driven Development<ref>[https://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development]</ref> framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber<ref>[https://cucumber.io/ Cucumber]</ref>. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

===Capybara===

Capybara<ref>[https://github.com/jnicklas/capybara Capybara github link]</ref> is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

===Integration Testing===

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration Testing - Microsoft Developer Network]</ref>. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up<ref>[https://en.wikipedia.org/wiki/Integration_testing Integration Testing - Wikipedia]</ref>.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Pattern and Approach==

We are required to write integration tests for the peer review process. Since we are not adding any new functionalities or amending any existing ones we don’t need to follow any specific design pattern. However we need to follow a specific integration testing approach to conduct the integration testing. The testing approach that we have decided to follow is '''Top-Down'''.
We are first going to create the following entities
* '''User or Reviewer'''
* '''Assignment Questionnaire or Rubric'''
* '''Assignment'''
Then we plan to incrementally test the interaction of these entities in a bottom-up manner.
We first test whether the user is able to successfully login.
If he is able to successfully login, we test whether he is able to successfully select an assignment for review.
If he is able to successfully select an assignment, we test whether he is able to able to submit a review successfully based on whether it is a text-based, point-based or both and whether he chooses to answer all, some or none of the questions of the rubric.

==Flowchart for the Peer Review Testing Approach==
[[File:FlowchartE1591 2.png]]

==Use Case Diagram==

[[File: UseCaseE1591.png]]

==Test Plan==
The following section describes how we plan on testing the application based requirements found on the Project Description<ref>[https://docs.google.com/document/d/1t0keeNQ2kP0NmcgIrtQXGi5K_GhQYcKzEVWJPPRBOHE/edit Project Description]</ref>. We wish to create Integration tests that thoroughly test a Student user reviewing an assignment submission. We will create a file called spec/features/peer_review.rb to run our integration tests.

=== Test Cases Prerequisites ===
To create and run our test cases we require some setup in Expertiza. The following list describes the information that we will enter into the system before running any of our test cases.

# We will use the Student with the username 'student13' and password 'password' to login as a Student.
# We will enroll Student into a specific course.
# We will create an Assignment per individual test case that is customized for our test case.
# We will submit an Assignment from a student other than 'student13' for 'student13' to review

=== Test Cases ===
The following list describes the individual test cases we will creating for Expertiza.

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-11T17:00:16Z

Meschwei: /* Test Scenarios */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> and Capybara<ref>[https://github.com/jnicklas/capybara]</ref> using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref>. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
===RSpec===

Rspec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> is Behavior Driven Development<ref>[https://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development]</ref> framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber<ref>[https://cucumber.io/ Cucumber]</ref>. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

===Capybara===

Capybara<ref>[https://github.com/jnicklas/capybara Capybara github link]</ref> is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

===Integration Testing===

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration Testing - Microsoft Developer Network]</ref>. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up<ref>[https://en.wikipedia.org/wiki/Integration_testing Integration Testing - Wikipedia]</ref>.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Plan==
The following section describes how we plan on testing the application based requirements found on the Project Description<ref>[https://docs.google.com/document/d/1t0keeNQ2kP0NmcgIrtQXGi5K_GhQYcKzEVWJPPRBOHE/edit Project Description]</ref>. We wish to create Integration tests that thoroughly test a Student user reviewing an assignment submission.

=== Test Cases Prerequisites ===
To create and run our test cases we require some setup in Expertiza. The following list describes the information that we will enter into the system before running any of our test cases.

# We will use the Student with the username 'student13' and password 'password' to login as a Student.
# We will enroll Student into a specific course.
# We will create an Assignment per individual test case that is customized for our test case.
# We will submit an Assignment from a student other than 'student13' for 'student13' to review

=== Test Cases ===
The following list describes the individual test cases we will creating for Expertiza.

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-11T16:46:25Z

Meschwei: /* Test Scenarios */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> and Capybara<ref>[https://github.com/jnicklas/capybara]</ref> using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref>. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
===RSpec===

Rspec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> is Behavior Driven Development<ref>[https://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development]</ref> framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber<ref>[https://cucumber.io/ Cucumber]</ref>. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

===Capybara===

Capybara<ref>[https://github.com/jnicklas/capybara Capybara github link]</ref> is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

===Integration Testing===

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration Testing - Microsoft Developer Network]</ref>. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up<ref>[https://en.wikipedia.org/wiki/Integration_testing Integration Testing - Wikipedia]</ref>.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Scenarios==
The following section describes how we plan on testing the application based requirements found on the Project Description<ref>[https://docs.google.com/document/d/1t0keeNQ2kP0NmcgIrtQXGi5K_GhQYcKzEVWJPPRBOHE/edit Project Description]</ref>. We wish to create Integration tests that thoroughly test a Student user reviewing an assignment submission.

=== Test Cases Prerequisites ===
To create and run our test cases we require some setup in Expertiza. The following list describes the information that we will enter into the system before running any of our test cases.

# We will use the Student with the username 'student13' and password 'password' to login as a Student.
# We will enroll Student into a specific course.
# We will create an Assignment per individual test case that is customized for our test case.
# We will submit an Assignment from a student other than 'student13' for 'student13' to review

=== Test Cases ===
The following list describes the individual test cases we will creating for Expertiza.

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-11T16:40:09Z

Meschwei: /* Test Scenarios */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> and Capybara<ref>[https://github.com/jnicklas/capybara]</ref> using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref>. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
===RSpec===

Rspec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> is Behavior Driven Development<ref>[https://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development]</ref> framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber<ref>[https://cucumber.io/ Cucumber]</ref>. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

===Capybara===

Capybara<ref>[https://github.com/jnicklas/capybara Capybara github link]</ref> is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

===Integration Testing===

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration Testing - Microsoft Developer Network]</ref>. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up<ref>[https://en.wikipedia.org/wiki/Integration_testing Integration Testing - Wikipedia]</ref>.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Scenarios==
The following section describes how we plan on testing the application based requirements found on the Project Description<ref>[https://docs.google.com/document/d/1t0keeNQ2kP0NmcgIrtQXGi5K_GhQYcKzEVWJPPRBOHE/edit Project Description]</ref>

=== Test Cases Prerequisites ===

=== Test Cases ===
T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T03:02:50Z

Meschwei: /* Enforce Good Ruby Conventions */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

= Unit Testing =
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec<ref>[http://rspec.info/ RSpec - http://rspec.info/]</ref>
. We also utilized the RSpec-Mocks<ref>[https://github.com/rspec/rspec-mocks RSpec-Mocks - https://github.com/rspec/rspec-mocks]</ref> to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza - https://github.com/expertiza/expertiza]</ref>, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

= Refactoring =
We performed various refactorings on our code to increase the codes readability and remove redundancy.

== Extracting Variables ==
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

== Enforce Good Ruby Conventions ==
We attempted to enforce good Ruby conventions while refactoring the code<ref>[https://github.com/bbatsov/ruby-style-guide Ruby Style Guidelines - https://github.com/bbatsov/ruby-style-guide]</ref>. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 

== Creating New Methods ==
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

= How to Run Tests =
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

= Fixing Issue 580 =
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T03:01:39Z

Meschwei: /* Unit Testing */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

= Unit Testing =
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec<ref>[http://rspec.info/ RSpec - http://rspec.info/]</ref>
. We also utilized the RSpec-Mocks<ref>[https://github.com/rspec/rspec-mocks RSpec-Mocks - https://github.com/rspec/rspec-mocks]</ref> to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza - https://github.com/expertiza/expertiza]</ref>, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

= Refactoring =
We performed various refactorings on our code to increase the codes readability and remove redundancy.

== Extracting Variables ==
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

== Enforce Good Ruby Conventions ==
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
== Creating New Methods ==
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

= How to Run Tests =
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

= Fixing Issue 580 =
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T03:00:22Z

Meschwei: /* Unit Testing */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

= Unit Testing =
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec<ref>[http://rspec.info/ RSpec - http://rspec.info/]</ref>
. We also utilized the RSpec-Mocks<ref>[https://github.com/rspec/rspec-mocks RSpec-Mocks - https://github.com/rspec/rspec-mocks]</ref> to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

= Refactoring =
We performed various refactorings on our code to increase the codes readability and remove redundancy.

== Extracting Variables ==
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

== Enforce Good Ruby Conventions ==
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
== Creating New Methods ==
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

= How to Run Tests =
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

= Fixing Issue 580 =
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T02:59:17Z

Meschwei: /* Unit Testing */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

= Unit Testing =
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec<ref>[http://rspec.info/ RSpec - http://rspec.info/]</ref>
. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

= Refactoring =
We performed various refactorings on our code to increase the codes readability and remove redundancy.

== Extracting Variables ==
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

== Enforce Good Ruby Conventions ==
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
== Creating New Methods ==
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

= How to Run Tests =
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

= Fixing Issue 580 =
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T02:57:37Z

Meschwei:

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

= Unit Testing =
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

= Refactoring =
We performed various refactorings on our code to increase the codes readability and remove redundancy.

== Extracting Variables ==
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

== Enforce Good Ruby Conventions ==
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
== Creating New Methods ==
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

= How to Run Tests =
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

= Fixing Issue 580 =
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T02:55:27Z

Meschwei:

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

== Unit Testing ==
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

== Refactoring ==
We performed various refactorings on our code to increase the codes readability and remove redundancy.

=== Extracting Variables ===
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

=== Enforce Good Ruby Conventions ===
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
=== Creating New Methods ===
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

== How to Run Tests ==
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

== Fixing Issue 580 ==
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

=References=
<references></references>

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T02:10:07Z

Meschwei: /* Unit Testing */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

== Unit Testing ==
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

Before we started working on Expertiza, running RSpec on the codebase resulted in 992 / 4184 lines of code (23.71%) covered. After our work, running RSpec on the codebase resulted in 1144 / 4278 lines of code (26.74%) covered.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

== Refactoring ==
We performed various refactorings on our code to increase the codes readability and remove redundancy.

=== Extracting Variables ===
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

=== Enforce Good Ruby Conventions ===
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
=== Creating New Methods ===
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

== How to Run Tests ==
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

== Fixing Issue 580 ==
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T01:56:24Z

Meschwei: /* How to Run Tests */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

== Unit Testing ==
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

== Refactoring ==
We performed various refactorings on our code to increase the codes readability and remove redundancy.

=== Extracting Variables ===
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

=== Enforce Good Ruby Conventions ===
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
=== Creating New Methods ===
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

== How to Run Tests ==
# Clone the repo 
#;<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>
# Change current directory to cloned repository 
# Run Command: 
#;<pre>rspec spec/controllers/sign_up_sheet_spec.rb</pre>
#;<pre>rspec spec/models/sign_up_sheet_spec.rb</pre>
# Check coverage:
#;Open overage/index.html in browser and check line coverage for following methods
#;# Create() in sign_up_sheet_controller.rb in Controllers 
#;# self.add_signup_topic() in sign_up_sheet.rb Models 
#;# save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
#;# self.confirmTopic() in sign_up_sheet.rb in Models

== Fixing Issue 580 ==
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T01:48:50Z

Meschwei: /* Unit Testing */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

== Unit Testing ==
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller tests and model tests for corresponding functions so as to test various scenarios and get 100% test coverage. We sought to obtain this high level of coverage to make refactoring more precise. We believe that highly tested code is resilient errors that could occur when refactoring.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller.

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions.

# Create() in SignUpSheetController
# self.add_signup_topic() in SignUpSheet
# save_topic_deadlines() in SignUpSheetController
# self.confirmTopic() in SignUpSheet

== Refactoring ==
We performed various refactorings on our code to increase the codes readability and remove redundancy.

=== Extracting Variables ===
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

=== Enforce Good Ruby Conventions ===
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
=== Creating New Methods ===
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

== How to Run Tests ==
1. Clone the repo 
<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>

2. Change current directory to cloned repository 

3. Run Command: 
<pre>rspec spec/controllers/sign_up_sheet_spec.rb

rspec spec/models/sign_up_sheet_spec.rb
</pre>

4. Check coverage: 
Open overage/index.html in browser and check line coverage for following methods
 
a. Create()in sign_up_sheet_controller.rb in Controllers 
b. self.add_signup_topic() in sign_up_sheet.rb Models 
c. save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
d. self.confirmTopic() in sign_up_sheet.rb in Models

== Fixing Issue 580 ==
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-11-10T01:44:36Z

Meschwei: /* E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb */

= E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb =
In this project, we have unit tested various methods in SignUpSheetController.rb and SignUpSheet.rb as well as refactoring these methods. We first wrote unit tests to ensure we had adequate coverage for our methods. Then, we refactored our methods with confidence found from our unit tests. We found that directly testing the functions that we refactored provided better assurances that our refactorings were correct rather than manual testing the user interface.

== Unit Testing ==
For our unit testing, we used the RSpec framework. We choose this framework since legacy tests of our methods were implemented with RSpec. We also utilized the RSpec-Mocks to test functions related to the database without having to use fixtures.

We wrote multiple controller and model tests for corresponding functions so as to tests various scenarios and get 100 % test coverage.

E.g. If you run the test in spec/controllers/sign_up_sheet_spec.rb by command "rspec spec/controllers/sign_up_sheet_spec.rb", then you can see the 100% line coverage for controller method save_topic_deadlines() in sign_up_sheet_controller.rb. For checking the coverage, open the index.html page coverage folder and go to respective controller. 

Similar, run the tests in Model and Controllers folder to see 100% test coverage for following functions. 

1. Create()in SignUpSheetController 
2. self.add_signup_topic() in SignUpSheet Model 
3. save_topic_deadlines() in SignUpSheetController 
4. self.confirmTopic() in SignUpSheet 

== Refactoring ==
We performed various refactorings on our code to increase the codes readability and remove redundancy.

=== Extracting Variables ===
We extracted variable from complicated statements to increase the readability of the code. In the code base we were working with, there were a variety of lines of code that were more than 80 characters long. These lines of code were hard to read. So, we split them up into multiple lines of code by extracting statements found in function calls into their own variable.

Example:

<pre>duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: DeadlineType.find_by_name('submission').id, round: j).first</pre>

Became:

<pre>deadline_type_subm = DeadlineType.find_by_name('submission').id
duedate_subm = TopicDeadline.where(topic_id: topic.id, deadline_type_id: deadline_type_subm, round: j).first</pre>

=== Enforce Good Ruby Conventions ===
We attempted to enforce good Ruby conventions while refactoring the code. This entails doing things like correcting the formatting of the code to make it more readable. In addition to this, we converted a variety of iterators to follow good ruby conventions.

For example, sign_up_sheet.rb had the function self.add_sign_up_topic(assignment_id) which contained an iteration through a set of topics while manually maintaining an index variable. Manually maintaining the index variable can be problematic for future maintenance.
<pre>i=0
@topics.each { |topic|
# Code not relevant to example omitted.
i = i + 1
}
</pre>

We replaced these with the Ruby <code>each_with_index</code> iterator. This allows us to pass the responsibility of maintaining the count of the index to the iterator.
<pre>@topics.each_with_index do |topic, i|</pre>

We replaced "=>" while passing parameter by colon (:)
So that <pre>
'due_at' => due_dates[session[:duedates][j]['id'].to_s </pre>
became
<pre>
due_at: due_dates[session[:duedates][j]['id'].to_s
</pre>
 
=== Creating New Methods ===
We have refactored the methods which were doing a lot of things into two or more methods so as to segregate the functionality and following the basic principal that one method should do only one thing. Also, this helped in making the methods more readable and easy to understand. 

E.g. In sign_up_sheet.rb Model, "def sign_up_wailisted()" is the new method extracted from original method self.confirmTopic(). There are many more such examples which are done as part of refactoring.
 

== How to Run Tests ==
1. Clone the repo 
<pre>git clone https://github.com/MaxSchweizer/expertiza</pre>

2. Change current directory to cloned repository 

3. Run Command: 
<pre>rspec spec/controllers/sign_up_sheet_spec.rb

rspec spec/models/sign_up_sheet_spec.rb
</pre>

4. Check coverage: 
Open overage/index.html in browser and check line coverage for following methods
 
a. Create()in sign_up_sheet_controller.rb in Controllers 
b. self.add_signup_topic() in sign_up_sheet.rb Models 
c. save_topic_deadlines() in sign_up_sheet_controller.rb in Controllers 
d. self.confirmTopic() in sign_up_sheet.rb in Models

== Fixing Issue 580 ==
We were not able to recreate the problem found in issue 580. After multiple attempts of trying to recreate the bug we began to examine the source code. We believe that someone else has already fixed the bug before we started working on the project.

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:27:22Z

Meschwei: /* Test Scenarios */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> and Capybara using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref>. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
===RSpec===

Rspec<ref>[http://rspec.info/documentation/ Rspec].''Rspec Documentation''</ref> is Behavior Driven Development<ref>[https://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development]</ref> framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber<ref>[https://cucumber.io/ Cucumber]</ref>. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

===Capybara===

Capybara<ref>[https://github.com/jnicklas/capybara Capybara github link]</ref> is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

===Integration Testing===

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx]</ref>. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up<ref>[https://en.wikipedia.org/wiki/Integration_testing https://en.wikipedia.org/wiki/Integration_testing]</ref>.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Scenarios==
Using the testing requirements found on the Project Description<ref>[https://docs.google.com/document/d/1t0keeNQ2kP0NmcgIrtQXGi5K_GhQYcKzEVWJPPRBOHE/edit Project Description]</ref>:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:18:16Z

Meschwei: /* Background */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza Expertiza's Github Site]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are and Capybara using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec. The various entities like users, assignment, questionnaire and instructor will be simulated using Capybara.

==Technologies to be used==
'''RSpec'''

Rspec is Behavior Driven Development framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

'''Capybara'''

Capybara is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

'''Integration Testing'''

Integration testing is a phase of software testing where units which have already been tested are combined into a component and the interface between them is tested. The idea is to test combination of pieces and eventually expand the process to test the modules with those of the other group. Eventually, all the modules making up a process are tested together.
Integration testing identifies the problem that occurs when units are combined. Some different types of integration testing are big bang, top- down, bottom-up.
*Big Bang Integration Testing – All modules are integrated simultaneously, after which everything is tested as a whole. It is very effective for saving time in the integration testing process.
*The top down approach – The highest level modules are tested first. This allows high level logic and data flow to be integrated early in the process.
*The bottom up approach - In this approach, lowest level components are tested first, and then used to facilitate the testing of higher level components.

==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:16:51Z

Meschwei: /* References */

==Background==
Expertiza<ref>[https://github.com/expertiza/expertiza]</ref> is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are '''RSpec''' and '''Capybara''' using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec. The various entities like '''users, assignment''' '''questionnaire''' and '''instructor''' will be simulated using Capybara.

==Technologies to be used==
'''RSpec'''

Rspec is Behavior Driven Development framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

'''Capybara'''

Capybara is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==
<references></references>

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:16:27Z

Meschwei: /* Background */

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:14:49Z

Meschwei: /* Background */

==Background==

[https://github.com/expertiza/expertiza Expertiza] is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re-submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
The purpose of the project is to perform an integration testing for the peer review of a submitted assignment. We aim to write test cases that test the different positive test scenarios for which the reviewer should be able to successfully submit the review to an assignment. The review process has certain minimum guidelines which need to be adhered to. We also plan to test the negative scenarios for which the reviewer doesn’t adhere to these guidelines and hence should not be able to submit the review to the assignment.
The Expertiza project has been developed using Ruby on Rails. The technologies to be used for the project are '''RSpec''' and '''Capybara''' using Ruby on Rails as an underlying framework. We will write the spec methods using RSpec. The various entities like '''users, assignment''' '''questionnaire''' and '''instructor''' will be simulated using Capybara.

==Technologies to be used==
'''RSpec'''

Rspec is Behavior Driven Development framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

'''Capybara'''

Capybara is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:10:50Z

Meschwei: /* Technologies to be used */

==Background==

Expertiza is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
Once an The project aims to write integration tests for the
==Technologies to be used==
'''RSpec'''

Rspec is Behavior Driven Development framework for ruby, it is a meta gem composed of different libraries designed to work together or with other testing tools like Cucumber. It has dependencies on Rspec core, Rspec expectations, Rspec mocks gems which can be loaded by using 'require'.

Installation-
gem install rspec

'''Capybara'''

Capybara is a library written in ruby, it helps you to test your web applications by pretending to be a user and following the user story, it simulates the browser to interact with app to receive pages parse the HTML and submit forms just as an actual user would do. Capybara can interact with many different drivers which execute tests through the same clean and simple interface. One can seamlessly choose between Selenium, Webkit or pure Ruby drivers.

Installation-

Capybara requires ruby 1.9.3 or later,to install add following line to your gem file and run bundle install
gem 'capybara'
If testing a rails app add this to your test helper file
require 'capybara/rails'

==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T19:01:49Z

Meschwei: /* Background */

==Background==

Expertiza is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.

One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called "Other’s Work" where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link.

After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.

For some assignments there is a scope for a re submission of an improved version of the work. After such a re submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
Once an The project aims to write integration tests for the
==Technologies to be used==
==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T18:47:59Z

Meschwei: /* Test Scenarios */ More test cases

==Background==

Expertiza is an open-source web tool that is used for online assignment completion purpose for different courses. The software enables the students to form online teams and choose different assignment topics. Each topic has a completion deadline and the students can submit the links to their work or assignments through expertiza.
One of the key features of expertiza is the online peer review process. Students who are enrolled in the same courses can review the works or the assignments of the fellow students. Typically for each assignment there is a link called Other’s Work where a student is prompted to give feedback to the works of their fellow classmates. This link becomes active after a certain date that is determined by the instructor or the administrator. After the date, a student can choose one of the assignments that are available for review through the activated link. After an assignment has been chosen for review, the reviewer will be presented with a review sheet that has a number of parameters based upon which the review should be done. The reviewer chooses a rating for each parameter, typically being the lowest and 5 as the highest. He can also leave a comment justifying his rating and stating the scopes of improvements for the project. The team members whose assignment has been reviewed can also review the review, i.e. provide an explanation about their work or give comments with respect to the feedback provided by the reviewer.
For some assignments there is a scope for a re submission of an improved version of the work. After such a re submission the reviewer can again review the assignment editing and updating his previous review based upon the resubmitted work.

==Purpose==
Once an The project aims to write integration tests for the
==Technologies to be used==
==Test Scenarios==
Using the testing requirements found on the Project Description:

T1: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will successfully submit the review answering the points based review choices.

T2: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by only answering some of the points based review choices.

T3: Login as a Student user and select a submission for review. The submission will only contain points based review choices. The user will unsuccessfully submit the review by answering none of the points based review choices.

T4: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will successfully submit the review answering the text based review choices.

T5: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by only answering some of the text based review choices.

T6: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will unsuccessfully submit the review by answering none of the text based review choices.

T7: Login as a Student user and select a submission for review. The submission will only contain text based review choices. The user will submit the review by answering all of the text based review choices with single word answers.

T8: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will successfully submit the review answering all of the review choices.

T9: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering only some of the review choices.

T10: Login as a Student user and select a submission for review. The submission will only contain both points based and text based review choices. The user will unsuccessfully submit the review answering none of the review choices.

==References==

CSC/ECE 517 Fall 2015 E1591 Integration testing for peer review

2015-11-07T18:45:22Z

Meschwei: /* Test Scenarios */ Basic testing scanarios

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T19:55:09Z

Meschwei: /* Enforce Good Ruby Conventions */

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T19:48:07Z

Meschwei: /* Refactoring */

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T19:45:00Z

Meschwei: /* Refactoring */ Extracting Variables

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T16:36:26Z

Meschwei: /* E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb */

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T16:31:34Z

Meschwei: Basic Introduction

CSC/ECE 517 Fall 2015/oss E1557 GXM

2015-10-31T16:24:59Z

Meschwei: First Commit

E1557. Refactoring SignUpSheetController.rb and SignUpSheet.rb

CSC/ECE 517 Fall 2015

2015-10-31T16:24:27Z

Meschwei: /* Writing Assignment 2 */

==Writing Assignment 2==
*[[CSC/ECE_517_Fall_2015/sample_page]]
*[[CSC/ECE_517_Fall_2015/ossE1558BGJ]]
*[[CSC/ECE 517 Fall 2015/oss/M1502/AAAASS]]
*[[CSC/ECE 517 Fall 2015/oss/M1503/IntegrateXMLParser]]
*[[CSC/ECE_517_Fall_2015/ossE1568BZHXJS]]
*[[CSC/ECE_517_Fall_2015/ossE1572VGA]]
*[[CSC/ECE_517_Fall_2015/oss_E1573_sap]]
*[[CSC/ECE 517 Fall 2015/oss E1559 rrz]]
*[[CSC/ECE 517 Fall 2015/oss E1570 avr]]
*[[CSC/ECE 517 Fall 2015/oss E1556 CHM]]
*[[CSC/ECE 517 Fall 2015/oss M1504 JJD]]
*[[CSC/ECE 517 Fall 2015/oss E1562 APS]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss M1501 GSN]]
*[[CSC/ECE 517 Fall 2015/oss E1551 RGS]]
*[[CSC/ECE 517 Fall 2015/oss E1555 GMR]]
*[[CSC/ECE 517 Fall 2015/oss E1552 NRR]]
*[[CSC/ECE 517 Fall 2015/oss E1565 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1561 WZL]]
*[[CSC/ECE 517 Fall 2015/oss E1553 AAJ]]
*[[CSC/ECE 517 Fall 2015/oss E1554 AAR]]
*[[CSC/ECE 517 Fall 2015/oss E1569 JNR]]
*[[CSC/ECE 517 Fall 2015/oss E1560 PSV]]
*[[CSC/ECE 517 Fall 2015/oss M1505 MSV]]
*[[CSC/ECE 517 Fall 2015/oss E1557 GXM]]