Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-12-05T03:29:31Z

Mzhang18:

== '''Purpose''' ==
This project is to perform integration testing for team creation. The testing needs to be done with the help of RSpec and Capybara. The UI procedures need to be tested are:
* Log in as a student
* Choose a available topic
* Invite one or more students as teammates
* Students who get the invition could accept or denial
* After accept the invitation, the team should form and all teammates should have same topic

== '''Testing Tools and Concepts''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave. It contains its own mocking framework that is fully integrated into the framework based upon JMock. The framework can be considered a domain-specific language (DSL) and resembles a natural language specification.In this project we will use expectation part of RSpec at most time.

; RSpec-expectations<ref>[https://github.com/rspec/rspec-expectations RSpec expectations page]</ref>
: RSpec::Expectations lets you express expected outcomes on an object in an example

; RSpec-rails<ref>[https://github.com/rspec/rspec-rails RSpec rails page]</ref>
: RSpec-rails is a testing framework for Rails 3.x and 4.x..

=== Capybara ===
Capybara is a library written in the Ruby programming language which makes it easy to simulate how a user interacts with application. Capybara can talk with many different drivers which execute tests through the same clean and simple interface.<ref>[http://www.gamesparks.com/blog/automated-testing-with-cucumber-and-capybara/ Capybara page]</ref>Capybara helps developer test web applications by simulating how a real user would interact with app.<ref>[https://github.com/jnicklas/capybara Capybara github page]</ref>

* Using Capybara with Cucumber:

<code> cucumber-rails gem </code> comes with Capybara support built-in

* Using Capybara with RSpec:

Load RSpec 2.x support by adding the line: <code> require 'capybara/rspec' </code>.

* Using Capybara with Test::Unit:

When using Rails, add the following code in <code> test_helper.rb </code> file to make Capybara available in all test cases deriving from <code>ActionDispatch::IntegrationTest </code>.

<code> class ActionDispatch::IntegrationTest </code>
<code> # Make the Capybara DSL available in all integration tests </code>
<code> include Capybara::DSL </code>
<code> end </code>

=== Integration test ===
Integration testing<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration test]</ref> is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component. A component, in this time, refers to an integrated aggregate of more than one unit. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.
* '''Big Bang for Integration test '''

Big Bang<ref>[http://www.tutorialspoint.com/software_testing_dictionary/big_bang_testing.htm Big Bang]</ref> Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units.

* '''Two apporachs: Top down and Bottom up'''

•The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

•The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.

== '''Testing Plan''' ==
Based on the project requirements, the testing can be divided into the following parts:

T1. Ensure a student is able to login to the system.

T2. Ensure a student is able to choose a topic from the assignment.

T3. Ensure a student is able to form a team by inviting other students enrolled in this course.
S1. If the invitation is sent to a student who isn't enrolled in the class, it should not be allowed.
S2. If the invitation is sent to a student who is enrolled in the class, it should be allowed.

T4. Ensure an invitee is able to accept or reject.

T5. Ensure all teammates have the same topic.
S1. If a student accepts the invitation and the student have a topic before, the topic should be dropped.
S2. If a student accepts the invitation and did not have the topic before, the student should have the same topic as other teammates who accepted the invitation.

== '''Modifying factories''' ==
Factory_girl<ref>[https://github.com/thoughtbot/factory_girl]</ref> is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.
The file listed below is used for modifying factories for test.
* /expertiza/spec/factories/factories.rb

Using factory_girl to modify course data.

factory :course ,class:Course do
name "CSC 517 Fall 2009"
instructor_id nil
directory_path "csc517/f09"
info "Object-Oriented Languages and Systems"
private true
institutions_id nil
end

Using factory_girl to modify assignment data.

factory :assignment ,class:Assignment do
name "final2"
directory_path "try"
submitter_count 0
course
instructor_id nil
private false
num_reviews 0
num_review_of_reviews 0
num_review_of_reviewers 0
review_questionnaire_id nil
review_of_review_questionnaire_id nil
teammate_review_questionnaire_id nil
reviews_visible_to_all false
association :wiki_type ,:factory => :wikitype
num_reviewers 0
spec_location "bfbfb"
author_feedback_questionnaire_id nil
max_team_size 3
...
end

Using factory_girl to set due date.

factory :due_date ,class:DueDate do
due_at "2015-12-30 23:30:12"
association :deadline_type, :factory => :deadline_type,strategy: :build
assignment { Assignment.first || association(:assignment)}
submission_allowed_id nil
review_allowed_id nil
resubmission_allowed_id nil
rereview_allowed_id nil
review_of_review_allowed_id nil
round 1
flag false
threshold 1
delayed_job_id nil
deadline_name nil
description_url nil
quiz_allowed_id nil
teammate_review_allowed_id nil
end

== '''Scenario''' ==
[[File:5190_diagram1.jpg]]

== '''Testing Scenario''' ==
Using Capybara to test expertize by simulating how a real user would do to form or join a team.
The file listed below is used for simulating uses` behavior.
* /expertiza/spec/features/team_creation_spec.rb

Simulating one student creates a team and send an invitation to another student, and the other one accept this.

it 'one student should send invitation and the other student should accept' do
student=User.find_by_name("student2064")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')
click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')
visit '/sign_up_sheet/sign_up?assignment_id=1&id=1'
expect(page).to have_content('Your topic(s)')
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
expect(page).to have_content('final2_Team1')
fill_in 'user_name', with:'student2065'
click_button 'Invite'
expect(page).to have_content('student2065')
student=User.find_by_name("student2065")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
#expect(page).to have_content('student2064')
visit '/invitation/accept?inv_id=1&student_id=1&team_id=0'
expect(page).to have_content('Team Name: final2_Team1')

=References=
<references></references>

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-12-05T03:27:14Z

Mzhang18: /* Testing Scenario */

== '''Purpose''' ==
This project is to perform integration testing for team creation. The testing needs to be done with the help of RSpec and Capybara. The UI procedures need to be tested are:
* Log in as a student
* Choose a available topic
* Invite one or more students as teammates
* Students who get the invition could accept or denial
* After accept the invitation, the team should form and all teammates should have same topic

== '''Testing Tools and Concepts''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave. It contains its own mocking framework that is fully integrated into the framework based upon JMock. The framework can be considered a domain-specific language (DSL) and resembles a natural language specification.In this project we will use expectation part of RSpec at most time.

; RSpec-expectations<ref>[https://github.com/rspec/rspec-expectations RSpec expectations page]</ref>
: RSpec::Expectations lets you express expected outcomes on an object in an example

; RSpec-rails<ref>[https://github.com/rspec/rspec-rails RSpec rails page]</ref>
: RSpec-rails is a testing framework for Rails 3.x and 4.x..

=== Capybara ===
Capybara is a library written in the Ruby programming language which makes it easy to simulate how a user interacts with application. Capybara can talk with many different drivers which execute tests through the same clean and simple interface.<ref>[http://www.gamesparks.com/blog/automated-testing-with-cucumber-and-capybara/ Capybara page]</ref>Capybara helps developer test web applications by simulating how a real user would interact with app.<ref>[https://github.com/jnicklas/capybara Capybara github page]</ref>

* Using Capybara with Cucumber:

<code> cucumber-rails gem </code> comes with Capybara support built-in

* Using Capybara with RSpec:

Load RSpec 2.x support by adding the line: <code> require 'capybara/rspec' </code>.

* Using Capybara with Test::Unit:

When using Rails, add the following code in <code> test_helper.rb </code> file to make Capybara available in all test cases deriving from <code>ActionDispatch::IntegrationTest </code>.

<code> class ActionDispatch::IntegrationTest </code>
<code> # Make the Capybara DSL available in all integration tests </code>
<code> include Capybara::DSL </code>
<code> end </code>

=== Integration test ===
Integration testing<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration test]</ref> is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component. A component, in this time, refers to an integrated aggregate of more than one unit. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.
* '''Big Bang for Integration test '''

Big Bang<ref>[http://www.tutorialspoint.com/software_testing_dictionary/big_bang_testing.htm Big Bang]</ref> Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units.

* '''Two apporachs: Top down and Bottom up'''

•The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

•The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.

== '''Testing Plan''' ==
Based on the project requirements, the testing can be divided into the following parts:

T1. Ensure a student is able to login to the system.

T2. Ensure a student is able to choose a topic from the assignment.

T3. Ensure a student is able to form a team by inviting other students enrolled in this course.
S1. If the invitation is sent to a student who isn't enrolled in the class, it should not be allowed.
S2. If the invitation is sent to a student who is enrolled in the class, it should be allowed.

T4. Ensure an invitee is able to accept or reject.

T5. Ensure all teammates have the same topic.
S1. If a student accepts the invitation and the student have a topic before, the topic should be dropped.
S2. If a student accepts the invitation and did not have the topic before, the student should have the same topic as other teammates who accepted the invitation.

== '''Modifying factories''' ==
Factory_girl<ref>[https://github.com/thoughtbot/factory_girl]</ref> is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.
The file listed below is used for modifying factories for test.
* /expertiza/spec/factories/factories.rb

Using factory_girl to modify course data.

factory :course ,class:Course do
name "CSC 517 Fall 2009"
instructor_id nil
directory_path "csc517/f09"
info "Object-Oriented Languages and Systems"
private true
institutions_id nil
end

Using factory_girl to modify assignment data.

factory :assignment ,class:Assignment do
name "final2"
directory_path "try"
submitter_count 0
course
instructor_id nil
private false
num_reviews 0
num_review_of_reviews 0
num_review_of_reviewers 0
review_questionnaire_id nil
review_of_review_questionnaire_id nil
teammate_review_questionnaire_id nil
reviews_visible_to_all false
association :wiki_type ,:factory => :wikitype
num_reviewers 0
spec_location "bfbfb"
author_feedback_questionnaire_id nil
max_team_size 3
...
end

Using factory_girl to set due date.

factory :due_date ,class:DueDate do
due_at "2015-12-30 23:30:12"
association :deadline_type, :factory => :deadline_type,strategy: :build
assignment { Assignment.first || association(:assignment)}
submission_allowed_id nil
review_allowed_id nil
resubmission_allowed_id nil
rereview_allowed_id nil
review_of_review_allowed_id nil
round 1
flag false
threshold 1
delayed_job_id nil
deadline_name nil
description_url nil
quiz_allowed_id nil
teammate_review_allowed_id nil
end

== '''Scenario''' ==
[[File:5190_diagram1.jpg]]

== '''Testing Scenario''' ==
Using Capybara to test expertize by simulating how a real user would do to form or join a team.

it 'one student should send inviatation and the other student should accept' do
student=User.find_by_name("student2064")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')
click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')
visit '/sign_up_sheet/sign_up?assignment_id=1&id=1'
expect(page).to have_content('Your topic(s)')
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
expect(page).to have_content('final2_Team1')
fill_in 'user_name', with:'student2065'
click_button 'Invite'
expect(page).to have_content('student2065')
student=User.find_by_name("student2065")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
#expect(page).to have_content('student2064')
visit '/invitation/accept?inv_id=1&student_id=1&team_id=0'
expect(page).to have_content('Team Name: final2_Team1')

=References=
<references></references>

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-12-05T03:25:42Z

Mzhang18:

== '''Purpose''' ==
This project is to perform integration testing for team creation. The testing needs to be done with the help of RSpec and Capybara. The UI procedures need to be tested are:
* Log in as a student
* Choose a available topic
* Invite one or more students as teammates
* Students who get the invition could accept or denial
* After accept the invitation, the team should form and all teammates should have same topic

== '''Testing Tools and Concepts''' ==

=== RSpec ===
Rspec <ref>[https://en.wikipedia.org/wiki/RSpec RSpec Wiki Page]</ref> is a behavior-driven development (BDD) framework for the Ruby programming language, inspired by JBehave. It contains its own mocking framework that is fully integrated into the framework based upon JMock. The framework can be considered a domain-specific language (DSL) and resembles a natural language specification.In this project we will use expectation part of RSpec at most time.

; RSpec-expectations<ref>[https://github.com/rspec/rspec-expectations RSpec expectations page]</ref>
: RSpec::Expectations lets you express expected outcomes on an object in an example

; RSpec-rails<ref>[https://github.com/rspec/rspec-rails RSpec rails page]</ref>
: RSpec-rails is a testing framework for Rails 3.x and 4.x..

=== Capybara ===
Capybara is a library written in the Ruby programming language which makes it easy to simulate how a user interacts with application. Capybara can talk with many different drivers which execute tests through the same clean and simple interface.<ref>[http://www.gamesparks.com/blog/automated-testing-with-cucumber-and-capybara/ Capybara page]</ref>Capybara helps developer test web applications by simulating how a real user would interact with app.<ref>[https://github.com/jnicklas/capybara Capybara github page]</ref>

* Using Capybara with Cucumber:

<code> cucumber-rails gem </code> comes with Capybara support built-in

* Using Capybara with RSpec:

Load RSpec 2.x support by adding the line: <code> require 'capybara/rspec' </code>.

* Using Capybara with Test::Unit:

When using Rails, add the following code in <code> test_helper.rb </code> file to make Capybara available in all test cases deriving from <code>ActionDispatch::IntegrationTest </code>.

<code> class ActionDispatch::IntegrationTest </code>
<code> # Make the Capybara DSL available in all integration tests </code>
<code> include Capybara::DSL </code>
<code> end </code>

=== Integration test ===
Integration testing<ref>[https://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx Integration test]</ref> is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component. A component, in this time, refers to an integrated aggregate of more than one unit. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups.
* '''Big Bang for Integration test '''

Big Bang<ref>[http://www.tutorialspoint.com/software_testing_dictionary/big_bang_testing.htm Big Bang]</ref> Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units.

* '''Two apporachs: Top down and Bottom up'''

•The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

•The bottom-up approach requires the lowest-level units be tested and integrated first. These units are frequently referred to as utility modules. By using this approach, utility modules are tested early in the development process and the need for stubs is minimized. The downside, however, is that the need for drivers complicates test management and high-level logic and data flow are tested late. Like the top-down approach, the bottom-up approach also provides poor support for early release of limited functionality.

== '''Testing Plan''' ==
Based on the project requirements, the testing can be divided into the following parts:

T1. Ensure a student is able to login to the system.

T2. Ensure a student is able to choose a topic from the assignment.

T3. Ensure a student is able to form a team by inviting other students enrolled in this course.
S1. If the invitation is sent to a student who isn't enrolled in the class, it should not be allowed.
S2. If the invitation is sent to a student who is enrolled in the class, it should be allowed.

T4. Ensure an invitee is able to accept or reject.

T5. Ensure all teammates have the same topic.
S1. If a student accepts the invitation and the student have a topic before, the topic should be dropped.
S2. If a student accepts the invitation and did not have the topic before, the student should have the same topic as other teammates who accepted the invitation.

== '''Modifying factories''' ==
Factory_girl<ref>[https://github.com/thoughtbot/factory_girl]</ref> is a fixtures replacement with a straightforward definition syntax, support for multiple build strategies (saved instances, unsaved instances, attribute hashes, and stubbed objects), and support for multiple factories for the same class (user, admin_user, and so on), including factory inheritance.
The file listed below is used for modifying factories for test.
* /expertiza/spec/factories/factories.rb

Using factory_girl to modify course data.

factory :course ,class:Course do
name "CSC 517 Fall 2009"
instructor_id nil
directory_path "csc517/f09"
info "Object-Oriented Languages and Systems"
private true
institutions_id nil
end

Using factory_girl to modify assignment data.

factory :assignment ,class:Assignment do
name "final2"
directory_path "try"
submitter_count 0
course
instructor_id nil
private false
num_reviews 0
num_review_of_reviews 0
num_review_of_reviewers 0
review_questionnaire_id nil
review_of_review_questionnaire_id nil
teammate_review_questionnaire_id nil
reviews_visible_to_all false
association :wiki_type ,:factory => :wikitype
num_reviewers 0
spec_location "bfbfb"
author_feedback_questionnaire_id nil
max_team_size 3
...
end

Using factory_girl to set due date.

factory :due_date ,class:DueDate do
due_at "2015-12-30 23:30:12"
association :deadline_type, :factory => :deadline_type,strategy: :build
assignment { Assignment.first || association(:assignment)}
submission_allowed_id nil
review_allowed_id nil
resubmission_allowed_id nil
rereview_allowed_id nil
review_of_review_allowed_id nil
round 1
flag false
threshold 1
delayed_job_id nil
deadline_name nil
description_url nil
quiz_allowed_id nil
teammate_review_allowed_id nil
end

== '''Scenario''' ==
[[File:5190_diagram1.jpg]]

== '''Testing Scenario''' ==

it 'one student should send inviatation and the other student should accept' do
student=User.find_by_name("student2064")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
expect(page).to have_content('Submit or Review work for final2')
click_link 'Signup sheet'
expect(page).to have_content('Signup sheet for final2 assignment')
visit '/sign_up_sheet/sign_up?assignment_id=1&id=1'
expect(page).to have_content('Your topic(s)')
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
expect(page).to have_content('final2_Team1')
fill_in 'user_name', with:'student2065'
click_button 'Invite'
expect(page).to have_content('student2065')
student=User.find_by_name("student2065")
role=student.role
ApplicationController.any_instance.stub(:current_user).and_return(student)
ApplicationController.any_instance.stub(:current_role_name).and_return('Student')
ApplicationController.any_instance.stub(:current_role).and_return(role)
visit '/student_task/list'
expect(page).to have_content('final2')
click_link 'final2'
click_link 'Your team'
#expect(page).to have_content('student2064')
visit '/invitation/accept?inv_id=1&student_id=1&team_id=0'
expect(page).to have_content('Team Name: final2_Team1')

=References=
<references></references>

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-12-05T02:57:28Z

Mzhang18: /* Modifying factories */

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

111

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-11-09T06:42:19Z

Mzhang18: /* Scenario */

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-11-09T06:42:05Z

Mzhang18: /* Scenario */

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-11-09T06:41:00Z

Mzhang18: /* Scenario */

CSC/ECE 517 Fall 2015 E1590 Integration testing for Team creation

2015-11-09T06:40:51Z

Mzhang18: /* Scenario */

File:5190 diagram zmc.jpg

2015-11-09T06:40:16Z

2015-10-31T21:35:15Z

Mzhang18:

'''E1561. Refactoring due_date.rb and deadline_helper.rb'''

This page provides a description of the Expertiza based OSS project. This project aimed at refactoring due_date.rb and deadline_helper.rb.

=Introduction to Expertiza=
[http://http://expertiza.ncsu.edu/ Expertiza] is a [http://en.wikipedia.org/wiki/Open-source_software Open Source] [http://rubyonrails.org/ Rails] application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. This Open Source application can be cloned from [https://github.com/expertiza/expertiza/ Github], the latest active branch is [https://github.com/expertiza/expertiza/tree/rails4 "Rails 4"].
This page is for the explanation of refactoring Expertiza. The specific work we done here is to refactor due_date.rb model and deadline_helper.rb. Based on the DRY principle and Rails convention, we also need to rewrite some methods to adhere to the RESTful style.

=Project Desicription<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>=
'''Files involved:'''
due_date.rb
response_controller.rb
deadline_helper.rb
sign_up_sheet.rb

'''What it does:'''
Manages the deadlines of an assignment, setting due dates for an assignment, copying due dates from one assignment to a new assignment etc.

'''What's wrong with it:'''
* It has methods making unnecessary DB calls.
* It contains duplicated methods.

'''What needs to be done:'''
There are 5 major goals for this project:

1. Remove <code>DueDate.assign_topic_deadline</code> and use <code>DeadlineHelper.create_topic_deadline</code> method wherever possible.

2. Create a new method for sort in <code>due_date.rb</code> and invoke it from places used in <code>due_date.rb</code> and <code>response_controller.rb</code>.

3. Rename <code>setFlag()</code> to adhere to Rails naming conventions.

4. Refactor <code>DueDate.default_permission</code>.

5. Refactor <code>DeadlineHelper.set_start_due_date</code> method to smaller methods.

=Modification=
==Case 1: Remove <code>DueDate.assign_topic_deadline</code> and use <code>DeadlineHelper.create_topic_deadline</code> ==
<code>DueDate.assign_topic_deadline</code> method which is same as <code>DeadlineHelper.create_topic_deadline</code> method.
{| class="wikitable"
|-
! |DueDate.assign_topic_deadline Method
! |DeadlineHelper.create_topic_deadline Method
|- style="vertical-align:top;"
|<pre>
def self.assign_topic_deadline(due_date,offset,topic_id)
topic_deadline = TopicDeadline.new
topic_deadline.topic_id = topic_id
topic_deadline.due_at = DateTime.parse(due_date.due_at.to_s) + offset.to_i
topic_deadline.deadline_type_id = due_date.deadline_type_id
topic_deadline.late_policy_id = nil
topic_deadline.submission_allowed_id = due_date.submission_allowed_id
topic_deadline.review_allowed_id = due_date.review_allowed_id
topic_deadline.review_of_review_allowed_id = due_date.review_of_review_allowed_id
topic_deadline.round = due_date.round
topic_deadline.save
end
</pre>
|<pre>
def self.create_topic_deadline(due_date,offset,topic_id)
topic_deadline = TopicDeadline.new
topic_deadline.topic_id = topic_id
topic_deadline.due_at = DateTime.parse(due_date.due_at.to_s) + offset.to_i
topic_deadline.deadline_type_id = due_date.deadline_type_id
topic_deadline.late_policy_id = nil
topic_deadline.submission_allowed_id = due_date.submission_allowed_id
topic_deadline.review_allowed_id = due_date.review_allowed_id
topic_deadline.review_of_review_allowed_id = due_date.review_of_review_allowed_id
topic_deadline.round = due_date.round
topic_deadline.save
end
</pre>
|}
First remove the <code>assign_topic_deadline</code> method in <code>due_date.rb</code>, then use <code>DeadlineHelper.create_topic_deadline</code> in <code>sign_up_sheet.rb</code> instead.
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
set_of_due_dates = DueDate.where(assignment_id: assignment_id)
set_of_due_dates.each { |due_date|
DueDate.assign_topic_deadline(due_date, 0, topic.id)
</pre>
|<pre>
set_of_due_dates = DueDate.where(assignment_id: assignment_id)
set_of_due_dates.each { |due_date|
DeadlineHelper.create_topic_deadline(due_date, 0, topic.id)
</pre>
|}

==Case 2: Create a new method for sort in <code>due_date.rb</code> and use and invoke it from where use it ==
First, create a new class method in <code>due_date.rb</code>.
def self.deadline_sort(due_dates)
due_dates.sort { |m1, m2| (m1.due_at and m2.due_at) ? m1.due_at <=> m2.due_at : (m1.due_at ? -1 : 1) }
end
Then call the new method when we sort the deadline in in line number 104 of <code>due_date.rb</code> and in line number 61 of <code>response_controller.rb</code>.
In due_date.rb:
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
due_dates = DueDate.where(["assignment_id = ?", assignment_id])
sorted_deadlines = Array.new
#sorted so that the earliest deadline is at the first
sorted_deadlines = due_dates.sort { |m1, m2| (m1.due_at and m2.due_at)?m1.due_at <=> m2.due_at:(m1.due_at ? -1:1)}
</pre>
|<pre>
due_dates = DueDate.where(["assignment_id = ?", assignment_id]) sorted_deadlines = Array.new
#sorted so that the earliest deadline is at the first
sorted_deadlines = deadline_sort(due_dates)
</pre>
|}
In response_controller.rb:
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
due_dates = DueDate.where(["assignment_id = ?", @assignment.id])
@sorted_deadlines=Array.new
@sorted_deadlines=due_dates.sort { |m1, m2| (m1.due_at and m2.due_at) ? m1.due_at <=> m2.due_at : (m1.due_at ? -1 : 1) }
</pre>
|<pre>
due_dates = DueDate.where(["assignment_id = ?", @assignment.id])
@sorted_deadlines=Array.new
@sorted_deadlines=DueDate.deadline_sort(due_dates)
</pre>
|}

==Case 3: Rename <code>setFlag()</code> to adhere to Rails naming conventions ==
Find the method in <code>due_date.rb</code> and rename it to <code>set_flag</code>.
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
def setFlag()
self.flag = true
self.save
end
</pre>
|<pre>
def set_flag
self.flag = true
self.save
end
</pre>
|}
Then also change the method name where it is called.
In <code>background_email_reminder.rake</code>:
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
date.setFlag
</pre>
|<pre>
date.set_flag
</pre>
|}

==Case 4: Use the class variable in <code>default_permission</code> method and use conditionally check deadline type using <code>if...else</code> statements ==
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
def self.default_permission(deadline_type, permission_type)
permission_id = Hash.new
permission_id['OK'] = DeadlineRight.find_by_name('OK').id
permission_id['No'] = DeadlineRight.find_by_name('No').id
permission_id['Late'] = DeadlineRight.find_by_name('Late').id

default_permission = Hash.new
default_permission['submission'] = Hash.new
default_permission['submission']['submission_allowed'] = permission_id['OK']
default_permission['submission']['can_review'] = permission_id['No']
default_permission['submission']['review_of_review_allowed'] = permission_id['No']

default_permission['review'] = Hash.new
default_permission['review']['submission_allowed'] = permission_id['No']
default_permission['review']['can_review'] = permission_id['OK']
default_permission['review']['review_of_review_allowed'] = permission_id['No']

default_permission['metareview'] = Hash.new
default_permission['metareview']['submission_allowed'] = permission_id['No']
default_permission['metareview']['can_review'] = permission_id['No']
default_permission['metareview']['review_of_review_allowed'] = permission_id['OK']

default_permission['drop_topic'] = Hash.new
default_permission['drop_topic']['submission_allowed'] = permission_id['OK']
default_permission['drop_topic']['can_review'] = permission_id['No']
default_permission['drop_topic']['review_of_review_allowed'] = permission_id['No']

default_permission['signup'] = Hash.new
default_permission['signup']['submission_allowed'] = permission_id['OK']
default_permission['signup']['can_review'] = permission_id['No']
default_permission['signup']['review_of_review_allowed'] = permission_id['No']

default_permission['team_formation'] = Hash.new
default_permission['team_formation']['submission_allowed'] = permission_id['OK']
default_permission['team_formation']['can_review'] = permission_id['No']
default_permission['team_formation']['review_of_review_allowed'] = permission_id['No']

default_permission[deadline_type][permission_type]
end
</pre>
|<pre>
@@permission_id = Hash.new
@@permission_id['OK'] = DeadlineRight.find_by_name('OK').id
@@permission_id['No'] = DeadlineRight.find_by_name('No').id
@@permission_id['Late'] = DeadlineRight.find_by_name('Late').id
def self.default_permission(deadline_type, permission_type)

default_permission = Hash.new
if (deadline_type == 'submission')
default_permission['submission'] = Hash.new
default_permission['submission']['submission_allowed'] = @@permission_id['OK']
default_permission['submission']['can_review'] = @@permission_id['No']
default_permission['submission']['review_of_review_allowed'] = @@permission_id['No']
elsif (deadline_type == 'review')
default_permission['review'] = Hash.new
default_permission['review']['submission_allowed'] = @@permission_id['No']
default_permission['review']['can_review'] = @@permission_id['OK']
default_permission['review']['review_of_review_allowed'] = @@permission_id['No']
elsif (deadline_type == 'metareview')
default_permission['metareview'] = Hash.new
default_permission['metareview']['submission_allowed'] = @@permission_id['No']
default_permission['metareview']['can_review'] = @@permission_id['No']
default_permission['metareview']['review_of_review_allowed'] = @@permission_id['OK']
elsif (deadline_type == 'drop_topic')
default_permission['drop_topic'] = Hash.new
default_permission['drop_topic']['submission_allowed'] = @@permission_id['OK']
default_permission['drop_topic']['can_review'] = @@permission_id['No']
default_permission['drop_topic']['review_of_review_allowed'] = @@permission_id['No']
elsif (deadline_type == 'signup')
default_permission['signup'] = Hash.new
default_permission['signup']['submission_allowed'] = @@permission_id['OK']
default_permission['signup']['can_review'] = @@permission_id['No']
default_permission['signup']['review_of_review_allowed'] = @@permission_id['No']
elsif (deadline_type == 'team_formation')
default_permission['team_formation'] = Hash.new
default_permission['team_formation']['submission_allowed'] = @@permission_id['OK']
default_permission['team_formation']['can_review'] = @@permission_id['No']
default_permission['team_formation']['review_of_review_allowed'] = @@permission_id['No']
end
default_permission[deadline_type][permission_type]
end
</pre>
|}

==Case 5: Refactor <code>DeadlineHelper.set_start_due_date</code> method to smaller methods ==
The <code>set_start_due_date</code> method in </code>deadline_helper.rb</code>is too long. First create a new method <code>check_dependency</code>.
def self.check_dependency(set_of_topic, set_of_due_dates, offset)
set_of_topic.each { |topic_id|
#if the due dates have already been created and the save dependency is being clicked,
#then delete existing n create again
prev_saved_due_dates = TopicDeadline.where(topic_id: topic_id)
#Only if there is a dependency for the topic
if !prev_saved_due_dates.nil?
num_due_dates = prev_saved_due_dates.length
#for each due date in the current topic he want to compare it to the previous due date
for x in 0..num_due_dates - 1
#we don't want the old date to move earlier in time so we save it as the new due date and destroy the old one
if DateTime.parse(set_of_due_dates[x].due_at.to_s) + offset.to_i < DateTime.parse(prev_saved_due_dates[x].due_at.to_s)
set_of_due_dates[x] = prev_saved_due_dates[x]
offset = 0
end
prev_saved_due_dates[x].destroy
end
end
set_of_due_dates.each_with_index {|due_date, index|
create_topic_deadline(due_date, offset, topic_id)
}
}
end
Then call <code>check_dependency</code> method in the original <code>set_start_due_date</code> method.
{| class="wikitable"
|-
! |Before Change
! |After Change
|- style="vertical-align:top;"
|<pre>
def self.set_start_due_date(assignment_id,set_of_topics)

#Remember, in create_common_start_time_topics function we reversed the graph so reverse it back
set_of_topics = set_of_topics.reverse

set_of_topics_due_dates = Array.new
i=0
days_between_submissions = Assignment.find(assignment_id)['days_between_submissions'].to_i
set_of_topics.each { |set_of_topic|
set_of_due_dates = nil
if i==0
#take the first set from the table which user stores
set_of_due_dates = DueDate.where(assignment_id: assignment_id)
offset = 0
else
set_of_due_dates = TopicDeadline.where(topic_id: set_of_topics[i-1][0])

set_of_due_dates.sort_by {|a| a.due_at }

offset = days_between_submissions
end

set_of_topic.each { |topic_id|
#if the due dates have already been created and the save dependency is being clicked,
#then delete existing n create again
prev_saved_due_dates = TopicDeadline.where(topic_id: topic_id)

#Only if there is a dependency for the topic
if !prev_saved_due_dates.nil?
num_due_dates = prev_saved_due_dates.length
#for each due date in the current topic he want to compare it to the previous due date
for x in 0..num_due_dates - 1
#we don't want the old date to move earlier in time so we save it as the new due date
and destroy the old one
if DateTime.parse(set_of_due_dates[x].due_at.to_s) + offset.to_i <
DateTime.parse(prev_saved_due_dates[x].due_at.to_s)
set_of_due_dates[x] = prev_saved_due_dates[x]
offset = 0
end
prev_saved_due_dates[x].destroy
end
end

set_of_due_dates.each_with_index {|due_date, index|
create_topic_deadline(due_date, offset, topic_id)
}
}
i = i+1
}

end
</pre>
|<pre>
def self.set_start_due_date(assignment_id,set_of_topics)

#Remember, in create_common_start_time_topics function we reversed the graph so reverse it back
set_of_topics = set_of_topics.reverse

set_of_topics_due_dates = Array.new
i=0
days_between_submissions = Assignment.find(assignment_id)['days_between_submissions'].to_i
set_of_topics.each { |set_of_topic|
set_of_due_dates = nil
if i==0
#take the first set from the table which user stores
set_of_due_dates = DueDate.where(assignment_id: assignment_id)
offset = 0
else
set_of_due_dates = TopicDeadline.where(topic_id: set_of_topics[i-1][0])

set_of_due_dates.sort_by {|a| a.due_at }

offset = days_between_submissions
end

check_dependency(set_of_topic, set_of_due_dates, offset)

i = i+1
}

end

def self.check_dependency(set_of_topic, set_of_due_dates, offset)
set_of_topic.each { |topic_id|
#if the due dates have already been created and the save dependency is being clicked,
#then delete existing n create again
prev_saved_due_dates = TopicDeadline.where(topic_id: topic_id)

#Only if there is a dependency for the topic
if !prev_saved_due_dates.nil?
num_due_dates = prev_saved_due_dates.length
#for each due date in the current topic he want to compare it to the previous due date
for x in 0..num_due_dates - 1
#we don't want the old date to move earlier in time so we save it as the new due date
and destroy the old one
if DateTime.parse(set_of_due_dates[x].due_at.to_s) + offset.to_i <
DateTime.parse(prev_saved_due_dates[x].due_at.to_s)
set_of_due_dates[x] = prev_saved_due_dates[x]
offset = 0
end
prev_saved_due_dates[x].destroy
end
end

set_of_due_dates.each_with_index {|due_date, index|
create_topic_deadline(due_date, offset, topic_id)
}
}
end
</pre>
|}
=Results Screenshot=
== Steps to verify deadline type default ==
Log into the application with the user having an instructor's role.

1. Click on Assignments.

2. Click on Edit.

3. Click on Due dates.

You will see the default of each deadline type in each row is "Yes", while the others are "No".
[[File:Q3.png]]

== Steps to verify save dependency ==
Log into the application with the user having an instructor's role.

1. Go to Page: http://152.1.13.227:3000/sign_up_sheet/add_signup_topics_staggered/723 (723 can be changed to the id of any assignments).

2. Click on Save dependencies.

Successful loading of this page confirms the save dependency method.
[[File:Q5.png]]

= References=
<references/>