Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016 E1708: Improvements to staggered-deadline assignments

2016-12-06T21:40:12Z

Cahuja2:

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 final project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an open source project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1708 and titled ‘Improvements to Staggered-Deadline Assignments’ is intended to make contributors or students understand the implementation of assignments and due dates models and tables, so that they can improve on the methodology which is used to assign the due dates to assignments and topics. A staggered-deadline assignment is an assignment in which different topics have different deadlines. It can be pretty useful if different topics within an assignment can have different deadlines for submission as well as reviews. The project has been divided into three problem statements and each of them is addressing an individual functional requirement related to the staggered deadline. The statements and the proposed approaches to meet the requirements are explained below as implementation.

== Project Requirements ==
The following issues can arise with a staggered-deadline assignment.

''Problem 1: Staggered-deadline topic available for selection past its deadline''

For a topic with multiple slots that is posted, if it is not selected in the first round, it is still available for selection in a later round. The team that selects the topic then is unable to submit their work as it is past deadline. A solution to this is to prohibit anyone from signing up for a topic whose submission deadline has passed.

''Problem 2: Manual submission and review deadline entry required for all topics''

Currently system requires instructor to enter submission and review deadlines for all topics. A probable solution to this is to allow the instructor to apply one deadline entry to a set of topics and also let the system calculate subsequent dates for subsequent project phases like review and re-submission, based on an initial deadline entry.

''Problem 3: New submissions not identifiable among pool of already graded entries''

Currently there is no way to identify new submissions among list of entries for which grading has already been done. There should some marker or way to distinguish new entries.

==Analysis and Implementation==
'''For Problem 1''', the solution that we have chosen to implement is fix 1. We will prevent anyone from signing up for a topic whose submission deadline has passed. Currently this is happening, but only in case of assignments which do not have staggered deadlines. This logic can be found in the ‘list’ method in the sign_up_sheet_controller.rb class. If the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for any topic in that assignment. Bellow code snippet indicates the same.

<pre>
unless assignment.due_dates.find_by_deadline_type_id(1).nil?
if !assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now
@show_actions = false
</pre>

We will have to replicate a similar logic for staggered deadline assignments. The problem here is that for staggered deadline assignments, different topics might have different deadlines. So, we will have to check deadlines for topics on an individual basis. Deadlines for individual topics are stored in a table called due_dates with the parent_id as the identifier of the particular topic in place of the assignment identifier. A logic for getting the due dates of individual topics for staggered deadline assignments is found in the method check_topic_due_date_value in the module SignUpSheetHelper.

<pre>
topic_due_date = TopicDueDate.where(parent_id: topic_id, deadline_type_id: deadline_type_id, round:review_round).first rescue nil
if !topic_due_date.nil?
due_date = topic_due_date.due_at
else
due_date = assignment_due_dates[review_round - 1].due_at.to_s
</pre>

First we check if the topic has a specific different deadline set by the instructor, and if not, then its deadline will be the same as the common deadline for the assignment.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will disable the selection option (Green color tick mark).

'''Implementation:'''
As mentioned, we are going to have to check deadlines on a topic-by-topic basis and so in the \app\views\sign_up_sheet\_all_actions.html.erb file, where we actually decide whether a student can sign up for a particular topic, we have implemented the following check to ensure that the submission deadline for that topic has not yet passed. We do this only for staggered deadline assignments as for the other assignments, this check has already taken place.

<pre>
!@assignment.staggered_deadline? || Time.now < get_topic_deadline([@assignment.due_dates.find_by_deadline_type_id(1)],topic.id,1,1)
</pre>

'''Design Principles used:'''
# Code re-usability: In order to ensure that we did not duplicate code, we used existing code in the check_topic_due_date_value method with some slight refactoring so that it could return us the dates in the required form.

Bellow is the a flow diagram indicating how deadlines are chosen for various topics:

[[File:ncsu_csc517_2016_e1708_decidingADeadline.png]]

'''In Problem 2''', the current implementation of the system requires the instructor to manually enter deadlines for the three submission review rounds which can be a painstaking task. Our requirement is to provide the instructor with the option to select a relative date for the submission review deadlines based on the Round1 submission deadline. The instructor would however like the ability to manually enter a custom date according to his needs.

One way of dealing with the above problem would be to provide an option for the other date fields for a given assignment to chose a relative date based on the initial submission date in addition to the ability to override and manually enter a custom date. Example: 3 days after Submission deadline, 6 days after re-submission deadline. This approach of implementation will only require changes to the _due_dates.html.erb view for the assignments controller.

Changes will have to be made to the due_dates_table in the _due_dates.html.erb file. Changes have to be made to the datetime_picker_roundtype_roundnumber id. We could provide the user with a drop down menu listing a possible set of relative dates to chose from, in addition to the ability to manually enter a custom date. This could be done on the view side by modifying the date fields and adding the necessary JavaScript so that appropriate date responses are filled into the corresponding date fields when an option is chose from the dropdown menu.

[[File:ncsu_csc517_2016_e1708_decidingADeadline2.png]]

'''For Problem 3''', the grader needs to know about the new reviews done by the author since the last time grading was done. Grades for reviews are stored in the grade_for_reviewer column in the participant table. Reviews done by a Reviewer for a particular reviewee are mapped in the response_maps table and the actual data regarding the reviews (round no, comments, date, etc.) are stored in the responses table with the map_id as the foreign key. In order to implement our solution, we will add a new review_last_graded_date column to the participant table to store when the grading was last done. If the grader changes the grade, then the review_last_graded_date will change to reflect the latest date.

Now, when the grader views the review_report for a particular participant,

# The code gets the review_last_graded_date for this participant
# Then it checks the responses table for the reviews that this participant has done for that assignment and compares the updated_at date for each of those reviews with the review_last_graded_date.
# If the updated_at date for any of those reviews is greater than the review_last_graded_date, we can change the color of the link which is displayed for that review to blue color to indicate that the participant has entered this new review, and that it has not yet been graded.

Bellow is the flow diagram for the same
[[File:ncsu_csc517_2016_e1708_newReviews.png]]

'''Implementation'''
# In the method 'save_grade_and_comment_for_reviewer' , in the review_mapping_controller, we save the grading date along with the actual grade and comments
# In the view app\views\review_mapping\_review_report.html.erb, we add a new method 'get_team_color' which actually performs the steps displayed in the flow diagram. It does this for each review that a particular participant has done.

==Use Cases==

====Problem 1====
For both the parts in this problem, we have chosen CSC/ECE 506, Spring 2015 as the course and Chapter 11-12 madeup exercises as the assignment. The first step will be to make this assignment a staggered deadline assignment. For doing this edit the assignment and under the General tab, make this a staggered deadline assignment.

''Part1: All submission due dates are in the past, so no topic is available for signup''

# Login as instructor6 
# Impersonate student5695 
# In the Assignments section, go to assignment Chapter 11-12 made up exercises 
# Click on Sign-up sheet 
# No topic should be displayed for signup 

''Part2: Change due date to after today for a topic, now it should be available for signup''

# Login as instructor6 
# Go to Manage - -> Courses and select CSC/ECE 506, Spring 2015 
# Edit the assignment Chapter 11-12 madeup exercises 
# Go to Topics tab and scroll down to the bottom and click on Show start/due date 
# Make the submission deadline for topic 11.2 as any date after today 
# Now Impersonate the student5695 and go to his sign_up sheet
# This topic 11.2 should be available for signup. All others remain unavailable 

====Problem 2====
''Part1: Instructor wants to assign default deadlines to a staggered assignment''

In this case, the default deadlines for the assignment will be filled automatically based on the submission date for Round 1. In this case no further input from the instructor is required apart from selecting the round 1 submission deadline

# Login as instructor6 
# Go to assignments and either create a new one or edit a pre-existing one. 
# Change assignment type to staggered. 
# Chose a submission deadline for round 1. 
# Deadlines for all other rounds will be autopopulated. 

''Part2: Instructor wants to enter custom deadlines for a staggered assignment''

In this case, the instructor has two options. He can either chose a deadline from a list of other relative deadlines from the dropdown menu for a particular round or all rounds, or he can decide to override the system enter a date manually by selecting the “Custom Date” option.

# Login as instructor6 
# Go to assignments and either create a new one or edit a pre-existing one. 
# Change assignment type to staggered. 
# Chose a submission deadline for round 1. 
# Deadlines for all other rounds will be autopopulated. 
# Change all the deadlines for the other rounds according to your requirements by choosing the "Custom Date" option 

''Part3: Instructor wants to enter a custom deadline only for a particular round''

In this case, the instructor can set the submission deadline for round 1. This would result in all deadlines being populated relatively according to the pre-set values. The instructor can then, if need be, modify the deadline for a particular round by either selecting a different relative date or by entering a custom date manually.

# Login as instructor6 
# Go to assignments and either create a new one or edit a pre-existing one. 
# Change assignment type to staggered. 
# Chose a submission deadline for round 1. 
# Deadlines for all other rounds will be autopopulated. 
# Change all the deadlines for the necessary round by either entering a manual date or by choosing a different relative date from the dropdown. 

====Problem 3====

''Part 1: To check if the color changes to blue when a new review is entered after the grading has been done.''
# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2014, go to edit assignments and choose New problems B
# Edit this and make it a staggered deadline assignment. Also change the review due dates for the first round to any date beyond today
# Now go back to assignments page and go to view review report for this assignment
# We focus on student 5059 for this case.
# This student has one review, go ahead and grade this review.
# Now impersonate student5059
# Go to the assignment 'New problems B' and click on 'others work'
# Choose topic 7.2 'The memory inconsistency problem' as the new review topic.
# Go ahead and submit a review for this topic.
# Now revert back to instructor6 and again go to view review report for this assignment.
# Now we can see a new review appears for the student 5059 by the name '5433, student' and this is blue in color indicating that this is yet to be graded.
# Now change the earlier grade and click on 'Save'.
# Refresh the page and the color of the review '5433, student' changes back to the normal color indicating that this one is graded.

''Part 2: Color must not change to blue if instructor has not graded at all .''
# Follow first 6 steps from Part 1.
# This student has submitted one review '5403, student'
# The color for this is still the normal color though, as no grading has been done (blank grade and comment column) and so the instructor knows that he has not done any grading for this review.

''Part 3: Color must not change to blue if the participant saves a review but does not submit it .''
# Follow the first 10 steps from part 1.
# Now start the review, but do not submit it, just save it.
# Revert back to instructor6 and again go to view review report for this assignment.
# Now we can see a new review appears for the student 5059 by the name '5433, student' but this still has the normal color as this review is not yet completed and the instructor need not look at it.

''Part 4: New Assignments''
In order to make sure that our changes will also work in the case of newly created assignments, we created a new assignment similar to assignment 'Chapter 11-12 madeup Exercise' under the course CSC/ECE 506, Spring 2015. The participants for this assignment were the same as those for the course. We created 4 new topics for this assignment. We allowed for submissions and reviews to take place at the same time in this assignment. We impersonated users student5695, student5697 and student5698 to make submissions and also made them review each other. After this we tested each of the above three test cases and they were working correctly.

==Unit Testing==
We have included 2 new helper specs as part of our task

# review_mapping_helper_spec.rb
# sign_up_sheet_helper_spec.rb

These cover the methods we either modified or added in the respective helpers. We were able to cover the sign_up_sheet_helper entirely while the coverage in
case of review_mapping_helper increased from 13.89% to 23.15%

==Testing Plan==
Testing for modification of dates in staggered deadlines. 
Case 1: Attempting to enter a date for a round that was before the previous round. The system should reject this deadline since it is not valid. 
Case 2: Attempting to enter a date for round1, round2 or round 3 that is out of invalid (Deadlines being before current date). The system should make sure that all dates being entered are valid and greater than or equal to current date. 
Case 3: Entering an incorrect date when manually entering a deadline for a particular round for a staggered deadline. When the user decides to enter a deadline manually rather than choosing the relative deadlines from the dropdown, care must be taken to ensure that the date is in the correct form. 

==References==
[https://expertiza.ncsu.edu/ Expertiza home page] 
[https://en.wikipedia.org/wiki/GitHub Github Wikipedia Page] 
[https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia Page] 
[https://www.youtube.com/watch?v=c9aFHfWSgMg&feature=youtu.be Demo Video]

CSC/ECE 517 Fall 2016 E1708: Improvements to staggered-deadline assignments

2016-12-06T21:39:19Z

Cahuja2:

CSC/ECE 517 Fall 2016 E1708: Improvements to staggered-deadline assignments

2016-12-06T21:23:29Z

Cahuja2:

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-04T00:06:22Z

Cahuja2: /* Outcomes */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response_take, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted true
end
end

The above factory is a contribution through the project. The factories create the instances for testing whenever required with the flag which indicates that the response is submitted.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

===== Running 'rspec' =====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

===== Deplyment testing =====
The project didn't make any changes in the development or production domain and only contributed to the testing domain. Also, RSpec tests are not tested with the running application in production or development, it's a part of testing which can be tested on console. So, no need of deployment was found for this project.

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.
After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:59:58Z

Cahuja2: /* Future Work */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response_take, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted true
end
end

The above factory is a contribution through the project. The factories create the instances for testing whenever required with the flag which indicates that the response is submitted.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.
After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:59:36Z

Cahuja2: /* Future Work */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response_take, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted true
end
end

The above factory is a contribution through the project. The factories create the instances for testing whenever required with the flag which indicates that the response is submitted.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
The team sought help from mentors and online resources and there are a lot of things which can still be implemented in a number of ways. All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.
After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:57:39Z

Cahuja2: /* Factories */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response_take, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted true
end
end

The above factory is a contribution through the project. The factories create the instances for testing whenever required with the flag which indicates that the response is submitted.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:53:04Z

Cahuja2: /* Contribution */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:52:18Z

Cahuja2:

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids][0]).to be(1)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-11-03T23:49:25Z

Cahuja2: /* Contribution */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe 'ReviewResponseMap' do
before(:each) do
@participant=create(:participant)
@assignment_questionnaire= create(:assignment_questionnaire)
@review_response=create(:review_response_map)
end

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(@review_response.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
response=create(:response_take)
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(@participant.class).to be(Participant)
end
end

describe "id" do
#test all the id are stored correctly
let(:reviewresponsemap) {ReviewResponseMap.new id: 66, reviewee_id: 1, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
it "should be our exact reviewer's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewer_id).to eq(1)
end
it "should be our exact reviewee's id" do
reviewresponsemap = build(:review_response_map)
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should be the response map_id" do
expect(response.map_id).to eq(4)
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block to keep the explanation to the point, the actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being ReviewResponseMap, FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as pieces of code.

describe "#final_versions_from_reviewer method" do
#three reviews are given by reviewer, result must have final review
it "should return final version of review when assignment has non varying rubric" do
create(:response_take)
create(:response_take)
create(:response_take)
map=ReviewResponseMap.final_versions_from_reviewer(1)
expect(map).to be_truthy
expect(map[:review][:questionnaire_id]).to be(1)
expect(map[:review][:response_ids].length).to be(1)
expect(map[:review][:response_ids][0]).to be(3)
end
.
.
.
describe "#import" do
it "raise error when not enough items" do
row = []
expect {ReviewResponseMap.import(row,nil,nil)}.to raise_error("Not enough items.")
end
it "raise error when assignment is nil" do
assignment = build(:assignment)
allow(Assignment).to receive(:find).and_return(nil)
row = ["user_name","reviewer_name", "reviewee_name"]
expect {ReviewResponseMap.import(row,nil,2)}.to raise_error("The assignment with id \"2\" was not found. <a href='/assignment/new'>Create</a> this assignment?")
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. Similarly, for QuizResponseMap class, the sample of test is as below.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb.

=== Outcomes ===
All the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes and the method chain calls a number of classes across the project which adds up to the complexity. For example, 'contributor' method from ReviewResponseMap class is a single line function but it calls method from ResponseMap which calls method from RevieResponseMap and then Participant and so on and it creates a complexity of creating instances of all these classes interlinking with each other with correct 'id'. The project is concluded with all the simple test cases and some complex test cases in the classes which are close to the ResponseMap hierarchy.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The submission includes a small video showing the test-runs. The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:20:12Z

Cahuja2: /* Factories */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:19:46Z

Cahuja2: /* Factories */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:19:33Z

Cahuja2: /* Factories */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:18:34Z

Cahuja2: /* Description of Project */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants id is assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:17:18Z

Cahuja2: /* References */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
# [https://expertiza.ncsu.edu/ Expertiza]
# [https://github.com/expertiza/expertiza Github Expertiza]
# [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
# [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:14:49Z

Cahuja2: /* References */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
1. [ https://expertiza.ncsu.edu/ Expertiza]
2. [https://github.com/expertiza/expertiza Github Expertiza]
3. [https://github.com/qizhongzhi/expertiza Local Contribution Github Fork]
4. [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:14:03Z

Cahuja2: /* References */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==
1. [ https://expertiza.ncsu.edu/ Expertiza]
2. Github [https://github.com/expertiza/expertiza Expertiza]
3. Local Contribution Github [https://github.com/qizhongzhi/expertiza Fork]
4. [https://relishapp.com/rspec RSpec]

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:08:53Z

Cahuja2: /* Running 'rspec' */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

The following snippet shows the result of running 'rspec spec/models/quiz_review_response_map.rb' on command line where Expertiza has been setup.

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

File:Quizresponsemap.jpg

2016-10-28T23:07:31Z

Cahuja2: uploaded a new version of "File:Quizresponsemap.jpg"

File:Quizresponsemap.jpg

2016-10-28T23:07:03Z

Cahuja2:

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:06:40Z

Cahuja2: /* Running 'rspec' */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

[[File:Quizresponsemap.jpg]]

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

File:Reviewresponsemap.JPG

2016-10-28T23:05:36Z

Cahuja2:

File:Quizresponsemap.JPG

2016-10-28T23:04:48Z

Cahuja2:

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T23:03:56Z

Cahuja2: /* Contribution */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
end

The above method is part of ReviewResponseMap and thus by Rails convention, the files containing above code is review_response_map_spec.rb. The specification is making sure that we get right fields when 'export_field' method is called while performing reviews.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end

The above two methods are part of QuizResponseMap and thus by Rails convention, the files containing above code is quiz_response_map_spec.rb. The first specification is making sure the relation between reviewer class and participant class which will be improved to give exact values using mocks in session 2 of the project. The second specification is making sure that we get empty score if there is no review.

describe "#show_review without response" do
it "should not show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end

Similarly, above two methods are being shown to project an idea of unit tests. The 'contributor' method has not been implemented in submission for session 1 and will be a part of session 2.

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for the some of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

rspec spec/models/review_response_map.rb
rspec spec/models/feedback_response_map.rb
rspec spec/models/teammate_review_response_map.rb
rspec spec/models/quiz_review_response_map.rb
rspec spec/models/bookmark_rating_response_map.rb
rspec spec/models/metareview_response_map.rb
rspec spec/models/self_review_response_map.rb

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T22:46:56Z

Cahuja2: /* Specifications */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [https://en.wikipedia.org/wiki/Cucumber_(software) cucumber], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T22:46:22Z

Cahuja2: /* Specifications */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [https://en.wikipedia.org/wiki/RSpec RSpec] with [[Cucumber (software)|cucumber]], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T22:44:55Z

Cahuja2: /* Specifications */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [[RSpec]] with [[Cucumber (software)|cucumber]], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T22:43:56Z

Cahuja2:

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [[RSpec]] with [[Cucumber (software)|cucumber]], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework. An example of specification using RSpec is shown in the adjacent snippet.

<INSERT Specification Snippet>

Add explanation.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.

require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}
describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end

The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.

describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end
describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A')
end
end
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end
describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T22:29:46Z

Cahuja2: /* Factories */

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following piece of code.

----
FactoryGirl.define do
factory :response, class: Response do
review_response_map { ReviewResponseMap.first || association(:review_response_map) }
response_map { ResponseMap.first || association(:response_map) }
additional_comment nil
version_num nil
round nil
is_submitted false
end
factory :response_map, class: ResponseMap do |f|
f.map_id { 100 }
f.reviewer_id { 200 }
f.Participant {'participant'}
end
end
----

The above factory was already present in the files whereas the second one is a contribution through the project. Both factories create the instances for testing whenever required.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [[RSpec]] with [[Cucumber (software)|cucumber]], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework. An example of specification using RSpec is shown in the adjacent snippet.

<INSERT Specification Snippet>

Add explanation.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.
<BASIC TEST>
The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.<syntaxhighlight lang="ruby">
describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end

describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A') #because no quiz has been taken
end
end
</syntaxhighlight><syntaxhighlight lang="ruby">
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end

describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
</syntaxhighlight><syntaxhighlight lang="ruby">
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
</syntaxhighlight>

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T21:27:16Z

Cahuja2:

CSC/ECE 517 Fall 2016 E1669 Test Various Kinds Of Response Map Hierarchies

2016-10-28T21:11:42Z

Cahuja2: Initial Plannning

{{dashboard.wikiedu.org sandbox}}

= CSC/ECE 517 Fall 2016/oss E1669 =

== Introduction ==
Expertiza is a web based application which can be used by instructors to assign tasks to students. Expertiza also allows students to form teams among each other, perform peer reviews on assignments and projects. It gives flexibility to instructor to allow students to see other student's work with intended limitations and impose required restrictions on student access. Expertiza has been developed as an Open Source Software (OSS) on Ruby on Rails framework.

== Motivation ==
Expertiza open source development program has fetched many contributions from faculties and students of different universities and thus, it incorporates a wide variety of Ruby coding styles, and this has been a reason why Expertiza project is kept as CSC/ECE 517 OSS project. The students have been given guidelines on Ruby coding styles and many problem statement includes tasks like refactoring and writing tests which can improve uniformity in coding style. The opportunity to work on an OSS project like Expertiza is also expected to provide student an introductory experience of understanding larger programs and making required contributions to them. The writing assignment along with programming assignment is expected to provide project documentation experience to students.

== Description of Project ==
The project numbered E1669 and titled 'Test various kinds of response map hierarchies' is intended to make contributors or students understand the working of response-map. Response-maps are implemented as classes in models as a convention in MVC architecture of Rails framework and they serve the purpose of mapping reviews among reviewers who is reviewing an assignment or project and reviewee whose work is being reviewed. The work which is being reviewed can be submission of an assignment, feedback to a submission, response to a feedback and whatever form which requires one participant to review a work of another participant. The response-maps exploits a number of relations which includes relations among assignments, quizzes, teammates who are participants and can be reviewer and reviewee at different times. The major key of differentiation among reviewer and reviewee as participants is id assigned to reviewer and reviewee. The code works perfectly fine but lacks unit tests for its methods.

== Project Implementation ==
The project requires contributors to write specification based unit tests. There are more than one ways to write unit tests in Ruby on Rails which includes writing test methods under test directory which requires writing fixtures and makes use of 'test_helper'. It is Rails' default way to prepare and use test data. This type of approach is not recommended for programs like Expertiza because of tedious maintenance of complex records and excessive dependencies of classes among each other. The work around is creating factories which creates data for tests whenever it is needed to create.

=== Factories ===
Factories generate data which is used to test the functionality of code. The code is typically either a model or controller. Factory Girl for rails is a gem for creating factories and it is also supported by open source development. For this project, factories were created using Factory Girl. One of the examples of factory girl being used in the project is shown in the following snippet.

<INSERT FACTORY SNIPPET>

Add explanation.

=== Specifications ===
Writing specifications is a way of behavior driven development approach to program which means that the specifications describes the behavior of the code. The specifications acts as tests and there are a number of tools, such as [https://github.com/rspec/rspec-rails TestUnit] and [[RSpec]] with [[Cucumber (software)|cucumber]], present to support this approach of development. For this project, RSpec was used and a part of reason for using RSpec is that it is included in the CSC/ECE517 coursework. An example of specification using RSpec is shown in the adjacent snippet.

<INSERT Specification Snippet>

Add explanation.

== Contribution ==
Apart from the examples given above, a number of test cases were written as unit tests for classes which inherits from ResponseMap class, namely ReviewResponseMap, TeammateReviewResponseMap, FeedbackResponseMap, QuizResponseMap, BookmarkRatingResponseMap, MetareviewResponseMap and SelfReviewResponseMap. Though all the methods were not tested in the test cases but the basic methods like object creation, object id and their respective titles were tested to be as assigned in the instance. Example of test cases implemented for basic methods are shown below.<syntaxhighlight lang="ruby" line="1">
require 'rails_helper'
describe ReviewResponseMap do
let(:reviewresponsemap) {ReviewResponseMap.new id: 6, reviewee_id: 1, reviewer_id: 2, reviewed_object_id: 8}
let(:response) {Response.new id: 4, map_id: 4}
let(:participant) {Participant.new id: 1}

describe "#new" do
it "Validate response instance creation with valid parameters" do
expect(reviewresponsemap.class).to be(ReviewResponseMap)
end
it "Validate response instance creation with valid parameters" do
expect(response.class).to be(Response)
end
it "Validate response instance creation with valid parameters" do
expect(participant.class).to be(Participant)
end
end
describe "id" do
it "should be our exact reviewresponsemap's id" do
expect(reviewresponsemap.id).to eq(6)
end
it "should be our exact reviewer's id" do
expect(reviewresponsemap.reviewer_id).to eq(2)
end
it "should be our exact reviewee's id" do
expect(reviewresponsemap.reviewee_id).to eq(1)
end
it "should not be any other reviewee's id" do
expect(reviewresponsemap.reviewee_id).not_to eq(2)
end
end
describe "title" do
it "should be Review" do
expect(reviewresponsemap.get_title).to eq('Review')
end
it "should not be teamReview" do
expect(reviewresponsemap.get_title).not_to eq('Team Review')
end
it "should be feedbackReview" do
expect(reviewresponsemap.get_title).not_to eq('Feedback Review')
end
end
end
</syntaxhighlight>The first line of above code block is specifying the 'rails_helper' which is needed to write the specifications here. The test has been written for ReviewResponseMap class and 'reviewresponsemap', 'response' and 'participant' are instances of ReviewResponseMap, Response and Participant. The 'new' specification test block is just making sure that the created instances are of respective class types and is not a much required test. Similarly, 'id' and 'title' attribute can be verified if the correct values of 'id' and 'title' have been stored. The above code block doesn't exactly show the actual changes made in the code block but actual changes can be found on the submitted git push request.

Apart from basic methods, some important methods were tested for classes which inherits more from ResponseMap as compared to other classes, example being FeedbackResponseMap and QuizResponseMap classes. Some examples are given below as snippets of code.<syntaxhighlight lang="ruby">
describe '#get_mappings_for_reviewer' do
it "gives out the relation of reviewer and participant" do
expect(QuizResponseMap.get_mappings_for_reviewer(participant.id).class).to eq(QuizResponseMap::ActiveRecord_Relation)
end
end

describe '#quiz_score' do
it "gives out the relation of reviewer and participant" do
expect(quizresponsemap.quiz_score).to eq('N/A') #because no quiz has been taken
end
end
</syntaxhighlight><syntaxhighlight lang="ruby">
describe "#show_review without response" do
it "should show a review" do
expect(feedbackresponsemap.show_review).to eq("No review was performed")
end
end

describe "#contributor" do
let(:feedbackresponsemap) {FeedbackResponseMap.new(:id => 1, :reviewee_id => 2, :reviewer_id => 3, :reviewed_object_id => 4, :review => Response.new(), :reviewee => Participant.new(), :reviewer => AssignmentParticipant.new())}
it "should return the object of same class" do
expect(feedbackresponsemap.contributor).to be(2)
end
end
</syntaxhighlight><syntaxhighlight lang="ruby">
describe "#export_field" do
it "should be xx" do
expect(ReviewResponseMap.export_fields(6)).to eq(["contributor", "reviewed by"])
end
</syntaxhighlight>

=== Outcomes ===
Currently, all the test cases which have been implemented are working without an error, however, the tests hasn't been written for most of the methods which call functions from inherited and related classes.

==== Running 'rspec' ====
RSpec can be run on a local setup of Expertiza. The steps to setup Expertiza locally has been documented well on the Github of Expertiza. After setting up expertiza, following RSpec commands can be used to invoke method testing.

Commands:

<SNIPPETS>

== Future Work ==
All the methods have not been covered which leaves the scope of writing more tests to increase coverage on ResponseMap class and it's child classes.

After getting enough coverage on ResponseMap and child classes, the closely related models like Participant and Assignment can be considered for unit testing.

== References ==