Expertiza_Wiki - User contributions [en]

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

2016-11-16T01:43:05Z

Arattili:

== 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 resubmission, based on an initial deadline entry.

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

Currently there is not 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. In order to do this we will have to modify the ‘list’ method in the sign_up_sheet_controller.rb class. In this method, currently we get the list of topics for a particular assignment:

<pre>
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment_id, private_to: mil)
@num_of_topics = @sign_up_topics.size
</pre>

Then if the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for the assignment.

<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. In that case we will have to check if the deadline has passed for each individual topic. 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 topics for staggered deadline assignments is found in the method check_topic_due_date_value in class 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 and if not then its deadline will be the same as the deadline for the assignment. We will use a similar logic.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will set the field @show_actions to false so then the user will not be able to sign up for these topics.
Possible Issues: We will have to confirm that the ‘list’ method is only method which is used for listing available topics to the user. If there is any other method being used, that will also have to be modified.

[[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 date_last_graded column to the participant table to store when the grading was last done. If the grader changes the grade, then the date_last_graded will change to reflect the latest date.

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

# The code gets the date_last_graded for this participant
# Then it checks the responses table for all the reviews that this participant has done for that assignment and compares the updated_at date for those reviews with the date_last_graded.
# If the updated_at date for any of those reviews is greater than the date_graded, we can change the colour of the link which is displayed for that reviewee to some different color to indicate that our author has entered a new review for that particular reviewee, and that it has not yet been graded.

[[File:ncsu_csc517_2016_e1708_newReviews.png]]

==Design==
===Use Case===
====Problem 1====
''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 
# Under the General tab, select Staggered deadline assignment 
# 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 
# Follow the steps in part 1 
# Now 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====

# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2015, go to edit assignments and choose Chapter 11-12 madeup exercises
# 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 impersonate student5695 (This user had selected one topic to be reviewed, but he never completed the review)
# Complete this review and submit it.
# Now revert back to instructor6 and go to view review report for this assignment
# Find user 5695. We should be able to see one review done by him (4383) and the colour should be blue (colour not yet decided) indicating that this is not yet graded.
# Now go ahead and grade this review
# The colour should change to the normal brownish colour.
# Now again impersonate student5695
# Go to this assignment and choose another topic for review (There will be only 1 available)
# Submit some review for this topic
# Now revert back to instructor6
# View review report for this assignment
# For student5695, we can now see 2 review submissions. One will be brown (4383) indicating that this one has been graded. The new one (5678) will be blue, indicating this one is yet to be graded.

==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]

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

2016-11-16T01:42:42Z

Arattili:

== 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 resubmission, based on an initial deadline entry.

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

Currently there is not 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. In order to do this we will have to modify the ‘list’ method in the sign_up_sheet_controller.rb class. In this method, currently we get the list of topics for a particular assignment:

<pre>
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment_id, private_to: mil)
@num_of_topics = @sign_up_topics.size
</pre>

Then if the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for the assignment.

<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. In that case we will have to check if the deadline has passed for each individual topic. 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 topics for staggered deadline assignments is found in the method check_topic_due_date_value in class 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 and if not then its deadline will be the same as the deadline for the assignment. We will use a similar logic.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will set the field @show_actions to false so then the user will not be able to sign up for these topics.
Possible Issues: We will have to confirm that the ‘list’ method is only method which is used for listing available topics to the user. If there is any other method being used, that will also have to be modified.

[[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 date_last_graded column to the participant table to store when the grading was last done. If the grader changes the grade, then the date_last_graded will change to reflect the latest date.

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

# The code gets the date_last_graded for this participant
# Then it checks the responses table for all the reviews that this participant has done for that assignment and compares the updated_at date for those reviews with the date_last_graded.
# If the updated_at date for any of those reviews is greater than the date_graded, we can change the colour of the link which is displayed for that reviewee to some different color to indicate that our author has entered a new review for that particular reviewee, and that it has not yet been graded.

[[File:ncsu_csc517_2016_e1708_newReviews.png]]

==Design==
===Use Case===
====Problem 1====
''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 
# Under the General tab, select Staggered deadline assignment 
# 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 
# Follow the steps in part 1 
# Now 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====

# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2015, go to edit assignments and choose Chapter 11-12 madeup exercises
# 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 impersonate student5695 (This user had selected one topic to be reviewed, but he never completed the review)
# Complete this review and submit it.
# Now revert back to instructor6 and go to view review report for this assignment
# Find user 5695. We should be able to see one review done by him (4383) and the colour should be blue (colour not yet decided) indicating that this is not yet graded.
# Now go ahead and grade this review
# The colour should change to the normal brownish colour.
# Now again impersonate student5695
# Go to this assignment and choose another topic for review (There will be only 1 available)
# Submit some review for this topic
# Now revert back to instructor6
# View review report for this assignment
# For student5695, we can now see 2 review submissions. One will be brown (4383) indicating that this one has been graded. The new one (5678) will be blue, indicating this one is yet to be graded.

==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]

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

2016-11-16T01:42:07Z

Arattili:

== 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 resubmission, based on an initial deadline entry.

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

Currently there is not 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. In order to do this we will have to modify the ‘list’ method in the sign_up_sheet_controller.rb class. In this method, currently we get the list of topics for a particular assignment:

<pre>
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment_id, private_to: mil)
@num_of_topics = @sign_up_topics.size
</pre>

Then if the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for the assignment.

<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. In that case we will have to check if the deadline has passed for each individual topic. 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 topics for staggered deadline assignments is found in the method check_topic_due_date_value in class 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 and if not then its deadline will be the same as the deadline for the assignment. We will use a similar logic.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will set the field @show_actions to false so then the user will not be able to sign up for these topics.
Possible Issues: We will have to confirm that the ‘list’ method is only method which is used for listing available topics to the user. If there is any other method being used, that will also have to be modified.

[[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 date_last_graded column to the participant table to store when the grading was last done. If the grader changes the grade, then the date_last_graded will change to reflect the latest date.

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

# The code gets the date_last_graded for this participant
# Then it checks the responses table for all the reviews that this participant has done for that assignment and compares the updated_at date for those reviews with the date_last_graded.
# If the updated_at date for any of those reviews is greater than the date_graded, we can change the colour of the link which is displayed for that reviewee to some different color to indicate that our author has entered a new review for that particular reviewee, and that it has not yet been graded.

[[File:ncsu_csc517_2016_e1708_newReviews.png]]

==Design==
===Use Case===
====Problem 1====
''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 
# Under the General tab, select Staggered deadline assignment 
# 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 
# Follow the steps in part 1 
# Now 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====

# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2015, go to edit assignments and choose Chapter 11-12 madeup exercises
# 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 impersonate student5695 (This user had selected one topic to be reviewed, but he never completed the review)
# Complete this review and submit it.
# Now revert back to instructor6 and go to view review report for this assignment
# Find user 5695. We should be able to see one review done by him (4383) and the colour should be blue (colour not yet decided) indicating that this is not yet graded.
# Now go ahead and grade this review
# The colour should change to the normal brownish colour.
# Now again impersonate student5695
# Go to this assignment and choose another topic for review (There will be only 1 available)
# Submit some review for this topic
# Now revert back to instructor6
# View review report for this assignment
# For student5695, we can now see 2 review submissions. One will be brown (4383) indicating that this one has been graded. The new one (5678) will be blue, indicating this one is yet to be graded.

==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]

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

2016-11-15T01:07:26Z

Arattili:

== 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 resubmission, based on an initial deadline entry.

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

Currently there is not 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. In order to do this we will have to modify the ‘list’ method in the sign_up_sheet_controller.rb class. In this method, currently we get the list of topics for a particular assignment:

<pre>
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment_id, private_to: mil)
@num_of_topics = @sign_up_topics.size
</pre>

Then if the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for the assignment.

<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. In that case we will have to check if the deadline has passed for each individual topic. 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 topics for staggered deadline assignments is found in the method check_topic_due_date_value in class 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 and if not then its deadline will be the same as the deadline for the assignment. We will use a similar logic.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will set the field @show_actions to false so then the user will not be able to sign up for these topics.
Possible Issues: We will have to confirm that the ‘list’ method is only method which is used for listing available topics to the user. If there is any other method being used, that will also have to be modified.

'''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.

'''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 date_last_graded column to the participant table to store when the grading was last done. If the grader changes the grade, then the date_last_graded will change to reflect the latest date.

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

# The code gets the date_last_graded for this participant
# Then it checks the responses table for all the reviews that this participant has done for that assignment and compares the updated_at date for those reviews with the date_last_graded.
# If the updated_at date for any of those reviews is greater than the date_graded, we can change the colour of the link which is displayed for that reviewee to some different color to indicate that our author has entered a new review for that particular reviewee, and that it has not yet been graded.

==Design==
===Use Case===
====Problem 1====
''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 
# Under the General tab, select Staggered deadline assignment 
# 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 
# Follow the steps in part 1 
# Now 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====

# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2015, go to edit assignments and choose Chapter 11-12 madeup exercises
# 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 impersonate student5695 (This user had selected one topic to be reviewed, but he never completed the review)
# Complete this review and submit it.
# Now revert back to instructor6 and go to view review report for this assignment
# Find user 5695. We should be able to see one review done by him (4383) and the colour should be blue (colour not yet decided) indicating that this is not yet graded.
# Now go ahead and grade this review
# The colour should change to the normal brownish colour.
# Now again impersonate student5695
# Go to this assignment and choose another topic for review (There will be only 1 available)
# Submit some review for this topic
# Now revert back to instructor6
# View review report for this assignment
# For student5695, we can now see 2 review submissions. One will be brown (4383) indicating that this one has been graded. The new one (5678) will be blue, indicating this one is yet to be graded.

===FlowChart===
====Deciding a deadline for an assignment====
[[File:ncsu_csc517_2016_e1708_decidingADeadline.png]]

[[File:ncsu_csc517_2016_e1708_decidingADeadline2.png]]

====Highlighting new reviews====
[[File:ncsu_csc517_2016_e1708_newReviews.png]]

==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]

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

2016-11-14T23:47:35Z

Arattili:

== 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 resubmission, based on an initial deadline entry.

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

Currently there is not 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. In order to do this we will have to modify the ‘list’ method in the sign_up_sheet_controller.rb class. In this method, currently we get the list of topics for a particular assignment:

<pre>
@sign_up_topics = SignUpTopic.where(assignment_id: @assignment_id, private_to: mil)
@num_of_topics = @sign_up_topics.size
</pre>

Then if the assignment is not a staggered deadline assignment and if its submission deadline has passed, then we prevent students from signing up for the assignment.

<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. In that case we will have to check if the deadline has passed for each individual topic. 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 topics for staggered deadline assignments is found in the method check_topic_due_date_value in class 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 and if not then its deadline will be the same as the deadline for the assignment. We will use a similar logic.
This way, we will filter out topics whose submission due dates have passed and for each of them, we will set the field @show_actions to false so then the user will not be able to sign up for these topics.
Possible Issues: We will have to confirm that the ‘list’ method is only method which is used for listing available topics to the user. If there is any other method being used, that will also have to be modified.

'''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.

<pre>
html += '<td class="due_date_name" width="15%">';
if (round_no != 0) {
html += 'Round ' + round_no + ': ' + capitalize(deadline_type);
} else {
html += capitalize(deadline_type.replace("_", " "));
}
html += '</td>';
var due_at = due_date.due_at;
if (due_at == null) {
due_at = '';
}
else{
var tzone = due_at.substr(23,6);
if(tzone=='Z'){
tzone = '+00:00';
}
var timezone = "(UTC "+tzone.toString()+")";
due_at = due_at.substr(0,4)+'/'+due_at.substr(5,2)+'/'+due_at.substr(8,2)+' '+due_at.substr(11,2)+':'+due_at.substr(14,2)+' '+timezone;
}
var due_name = due_date.deadline_name;
if (due_name == null){
due_name = '';
}
html += '<td align="center" class="due_date_due_at" width="25%">' +
'<input id="datetimepicker_' + element_id +
'" name="assignment_form[due_date][][due_at]" style="width: 200px" type="text" value="' +
due_at + '">' + '</td>';

html += '<td align="center" class="due_date_due_at" width="10%">';
// if(deadline_type == 'team_formation'){
// html += '<select id="due_date_submission_allowed_id" name="assignment_form[due_date][][submission_allowed_id]" disabled>'
// }
// else{
html += '<select id="due_date_submission_allowed_id" name="assignment_form[due_date][][submission_allowed_id]">'
// }

</pre>

'''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 date_last_graded column to the participant table to store when the grading was last done. If the grader changes the grade, then the date_last_graded will change to reflect the latest date.

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

# The code gets the date_last_graded for this participant
# Then it checks the responses table for all the reviews that this participant has done for that assignment and compares the updated_at date for those reviews with the date_last_graded.
# If the updated_at date for any of those reviews is greater than the date_graded, we can change the colour of the link which is displayed for that reviewee to some different color to indicate that our author has entered a new review for that particular reviewee, and that it has not yet been graded.

==Design==
===Use Case===
====Problem 1====
''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 
# Under the General tab, select Staggered deadline assignment 
# 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 
# Follow the steps in part 1 
# Now 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 fr round 1. 
# Deadlines for all other rounds will be prepopulated. 
''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 fr round 1. 
# Deadlines for all other rounds will be prepopulated. 
# 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 fr round 1. 
# Deadlines for all other rounds will be prepopulated. 
# 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====

# Login as instructor6
# Go to courses tab
# For CSC/ECE 506, Spring 2015, go to edit assignments and choose Chapter 11-12 madeup exercises
# 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 impersonate student5695 (This user had selected one topic to be reviewed, but he never completed the review)
# Complete this review and submit it.
# Now revert back to instructor6 and go to view review report for this assignment
# Find user 5695. We should be able to see one review done by him (4383) and the colour should be blue (colour not yet decided) indicating that this is not yet graded.
# Now go ahead and grade this review
# The colour should change to the normal brownish colour.
# Now again impersonate student5695
# Go to this assignment and choose another topic for review (There will be only 1 available)
# Submit some review for this topic
# Now revert back to instructor6
# View review report for this assignment
# For student5695, we can now see 2 review submissions. One will be brown (4383) indicating that this one has been graded. The new one (5678) will be blue, indicating this one is yet to be graded.

==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]

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

2016-11-10T04:14:10Z

Arattili:

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

2016-11-10T04:09:55Z

Arattili:

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

2016-11-10T04:06:54Z

Arattili:

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

2016-11-10T04:06:25Z

Arattili:

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

2016-11-10T04:01:45Z

Arattili:

CSC/ECE 517 Fall 2016/E1670. Unit tests for answers.rb

2016-10-29T00:18:40Z

Arattili:

==E1670 . Unit tests for answers.rb==

This wiki page is for the description of changes made under E1670 OSS assignment for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to take assignments posted by the course instructors. Expertiza allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on this feedback.

===Project Description===

In Expertiza, each questionnaire contains many questions, those question may have different types (e.g. checkbox, criterion, etc). When a user fills in a rubric, the responses for each question will become an answer record. The responses of rubrics are stored in answers table in DB. The answer.rb is the model for the answers table in DB. Answer.rb model does not have any test cases and the aim of the project is to write fast, effective and flexible unit test cases that offer maximum code coverage.

===Files Created/Modified===
*answer_spec.rb
*factories.rb

===RSpec===
====RSpec Introduction====
RSpec is a testing framework for Ruby for behavior-driven development (BDD) licensed under MIT. It is inspired by JBehave and contains fully integrated JMock based framework which has a very rich and powerful DSL (domain-specific language) which resembles a natural language specification.
Composed of multiple libraries structured to work together, RSpec provides encapsulated testing via the describe block to specify the behavior of the class and the context for the unit test case.

==== Why RSpec? ====
RSpec is easy to learn and implement and can be used with other testing tools like Cucumber and Minitest independently. It is extremely powerful for testing states with complicated setup and also helps in tearing down complex code to access the objects required for testing
RSpec semantics encourage agile thinking and practice and it structures the tests in a more intuitive way.

===Functions in answers.rb===

'''Function Name : Compute_scores'''

Compute_scores is a function in model answer.rb which gives the average, maximum and minimum scores obtained in a series a responses/assessments. It has two input parameters: List of assessments and questions. The function iterates over each assessment to get the total score of that assessment. If the response or review is invalid, that assessment won’t be considered in the calculation of the score average. After iterating over all assessments, Max score, and Min scores are calculated along with the average score based on the number of valid assessments. Their scores are returned by the function.

'''Rspec Unit Test : Compute_scores'''

Following scenarios are tested:

* To return scores as nil if the input list of assessments is nil. This is to make sure no Null Pointer exceptions are thrown by the code
*To return a particular score when a single valid assessment is given as an input.
*To return a particular score when multiple valid assessments are given as an input. This is to test the looping functionality of the method.
*To return a particular score when invalid assessments are given as an input. The validity and total scores are returned by a mock and not by the actual functions. This is to make the test cases less rigid so that failure of dependent functions do not disrupt the functionality of interface level tests.
*To return a particular score when invalid flag is nil. Invalid flag can either be 0,1 or nil. Nil situation is tested to prevent NullPointer Exceptions
*To check if the method get_total_score is called with the right parameters.

This unit test uses a stub and returns a mock value.
<pre>
Answer.stub(:get_total_score)
</pre>
This is to eliminate tight coupling between compute_scores and get_total_scores. Failure in get_total_scores wouldn't break the compute_scores test cases.

'''Function Name : Get_total_scores'''

This function is called by the Compute_scores method of the answer.rb model to compute the total score of an assessment. The input consists of assessment for which the total score is being calculated and the list of questions being evaluated in the assessment. The method uses questionnaire id from the questions and response id to obtain a score view questionnaire data. This score view is a read-only record. The questionnaire data mainly consists of q1_max_question_score, sum_of_weights and weighted_score. Before calculating the score, the function performs two crucial tasks.
*Checks if the answer for a scored question is nil. If it is nil or unanswered, the question will be ignored and not counted towards the score of this response.
* Calls the submission_valid function by passing the response record to set the @invalid flag based on the validity of the response.
The total score is calculated using the below formula

<pre>
(weighted_score / (sum_of_weights * max_question_score)) * 100
</pre>

Any edge cases would return -1 indicating no score

'''Rspec Unit Test : Get_total_scores'''

Following scenarios are tested:

*To return an anticipated total score of a single response without any edge cases. Since this function will be called only on one response at a time, there is no need to test for multiple responses at the same time.
*To return an anticipated total score of a response where nil answer is for a scored question. This is to check if its weight gets removed from the sum_of_weights.
*To return -1 when the sum of weights becomes 0. This can happen when all the scored questions are unanswered. Return value of -1 is checked at the calling function to ensure if a score is returned or not.
*To return -1 when weighted_score of questionnaireData is nil
* To check if submission_valid is called. This method is called to set invalid flag to indicate whether the response entered is valid or not. The validity criteria is explained in the submission_valid? Function.

This unit test uses two stubs and returns mock results
<pre>
ScoreView.stub(:find_by_sql)
</pre>
<pre>
Answer.stub(:where)
</pre>
This is to reduce the outcome of the test to depend on DB calls. For example, in case the connection to DB fails, this unit test would still pass making it less rigid.

'''Function Name : submission_valid?'''

This purpose of this function is to verify the validity of a review based on a deadline. This function obtains a list of AssignmentDueDate objects in descending order which is then compared against the current time to determine which deadlines are valid and which ones are not. The flag variable is used to represent whether or not a deadline was available in the previous iteration of the loop. If the flag is set to TRUE and the deadline is less than the current date, then latest_review_phase_start_time is set to this deadline. A list of ResubmissionTime objects is also retrieved from the controller. These objects are then compared against the then latest_review_phase_start_time variable to determine a response.

Observations: The current implementation of the function is bugged. It retrieves a list of sorted AssignmentDueDate objects and proceeds to check if this list is empty. However, instead of exiting if the function if the list is empty, it carries on execution and raises an exception on hitting the for loop.

*Checks if a review is valid or not by comparing its date with a list of deadlines.
*Returns 1 or 0 depending on validity
*Current implementation is bugged. Throws an exception if no AssignmentDueDate objects are passed, returns nil if any objects are passed.

'''Rspec Unit Test : submission_valid?'''

Following scenarios are tested:

*Passing valid AssignmentDueDate objects
*Not passing any AssignmentDueDate objects

When valid AssignmentDueDate objects are passed, stubs are used to create fake AssignmentDueDate Objects and ResubmissionTime objects. These objects are then populated with valid deadline dates and deadline_type values. These values are then supplied when requested by the submission_valid? Function rather than actually calling the function. The current implementation of this test case expects the program to throw an error when it reaches the for loop. Once this bug is fixed, this test case may be re-written to test a more legitimate test case.

In case an empty list of AssignmentDueDate objects is passed back to the submission_valid?() method. This would cause the function to return nil. When this function is fixed, the following test case may be re-written to test for a more legitimate test-case.

This unit test uses two stubs and returns mock results
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
The above stub returns two AssignmentDueDate objects whenever the where() and order() method are chained on AssignmentDueDate.
<pre>
ResubmissionTime.stub_chain(:where, :order)
</pre>
The above stub returns two ResubmissionTime objects whenever the where() and order() method are chained on ResubmissionTime.
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
This stub is used in the second test case to return nil objects.

the stub_chain method can be used to create stubs where chained methods are expected.

'''Function Name : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

These three functions are sql queries that hit the DB to get a output record after a series of selections and joins. SQL queries that hit DB often do not have a high priority when it comes to testing, so the project does not aggressively test these functions. However, these functions are tested to make sure the queries are able to find the right column names and tables successfully. Any change in the table schema would be detected in these test cases. The functionality of these queries are not tested but instead existence of an output is tested. This ensures that answer.rb is able to make a successful db connection and is sync with the latest db schema. Since the function actually hits the DB, mocks can no longer be used, instead active records were created and saved in test db using FactoryGirl gem from the factories.rb. These records are cleared after every test case.

Following factories were used to create records in the table
*question
*response_record
*response_map
*answer

'''Rspec Unit Test : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

The factories are created such a way that the query would return an output and the tests will pass if the query returns a non nil record. The functionality of these functions would be tested by the integration tests of the controller

'''Validation and Dependency Rspec Test'''

Apart from testing functions, the models are also tested for validations and external dependencies. Model answer.rb does not have any validations but does have a dependency on question.rb. Answer belongs_to question and this was tested using a simple dependency rspec test.
<pre>
it { should belong_to(:question) }
</pre>
===Running Rspec===
*To run the test suite for a particular file only( answer_spec.rb):
<pre>
root@ubuntu:~/expertiza$ rspec spec/models/answer_spec.rb
</pre>
*To run the entire suite of test cases:
<pre>
root@ubuntu:~/expertiza$ rspec spec
</pre>

===Rspec Test Results===

<pre>
1 deprecation warning total

Finished in 12.39 seconds (files took 11.25 seconds to load)
17 examples, 0 failures

Randomized with seed 37447

Coverage report generated for RSpec to /home/root/expertiza/coverage. 998 / 3919 LOC (25.47%) covered.
[Coveralls] Outside the CI environment, not sending data.
</pre>

CSC/ECE 517 Fall 2016/E1670. Unit tests for answers.rb

2016-10-29T00:14:06Z

Arattili:

==E1670 . Unit tests for answers.rb==

This wiki page is for the description of changes made under E1670 OSS assignment for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to take assignments posted by the course instructors. Expertiza allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on this feedback.

===Project Description===

In Expertiza, each questionnaire contains many questions, those question may have different types (e.g. checkbox, criterion, etc). When a user fills in a rubric, the responses for each question will become an answer record. The responses of rubrics are stored in answers table in DB. The answer.rb is the model for the answers table in DB. Answer.rb model does not have any test cases and the aim of the project is to write fast, effective and flexible unit test cases that offer maximum code coverage.

===Files Created/Modified===
*answer_spec.rb
*factories.rb

===RSpec===
====RSpec Introduction====
RSpec is a testing framework for Ruby for behavior-driven development (BDD) licensed under MIT. It is inspired by JBehave and contains fully integrated JMock based framework which has a very rich and powerful DSL (domain-specific language) which resembles a natural language specification.
Composed of multiple libraries structured to work together, RSpec provides encapsulated testing via the describe block to specify the behavior of the class and the context for the unit test case.

==== Why RSpec? ====
RSpec is easy to learn and implement and can be used with other testing tools like Cucumber and Minitest independently. It is extremely powerful for testing states with complicated setup and also helps in tearing down complex code to access the objects required for testing
RSpec semantics encourage agile thinking and practice and it structures the tests in a more intuitive way.

===Functions in answers.rb===

'''Function Name : Compute_scores'''

Compute_scores is a function in model answer.rb which gives the average, maximum and minimum scores obtained in a series a responses/assessments. It has two input parameters: List of assessments and questions. The function iterates over each assessment to get the total score of that assessment. If the response or review is invalid, that assessment won’t be considered in the calculation of the score average. After iterating over all assessments, Max score, and Min scores are calculated along with the average score based on the number of valid assessments. Their scores are returned by the function.

'''Rspec Unit Test : Compute_scores'''

Following scenarios are tested:

* To return scores as nil if the input list of assessments is nil. This is to make sure no Null Pointer exceptions are thrown by the code
*To return a particular score when a single valid assessment is given as an input.
*To return a particular score when multiple valid assessments are given as an input. This is to test the looping functionality of the method.
*To return a particular score when invalid assessments are given as an input. The validity and total scores are returned by a mock and not by the actual functions. This is to make the test cases less rigid so that failure of dependent functions do not disrupt the functionality of interface level tests.
*To return a particular score when invalid flag is nil. Invalid flag can either be 0,1 or nil. Nil situation is tested to prevent NullPointer Exceptions
*To check if the method get_total_score is called with the right parameters.

This unit test uses a stub and returns a mock value.
<pre>
Answer.stub(:get_total_score)
</pre>
This is to eliminate tight coupling between compute_scores and get_total_scores. Failure in get_total_scores wouldn't break the compute_scores test cases.

'''Function Name : Get_total_scores'''

This function is called by the Compute_scores method of the answer.rb model to compute the total score of an assessment. The input consists of assessment for which the total score is being calculated and the list of questions being evaluated in the assessment. The method uses questionnaire id from the questions and response id to obtain a score view questionnaire data. This score view is a read-only record. The questionnaire data mainly consists of q1_max_question_score, sum_of_weights and weighted_score. Before calculating the score, the function performs two crucial tasks.
*Checks if the answer for a scored question is nil. If it is nil or unanswered, the question will be ignored and not counted towards the score of this response.
* Calls the submission_valid function by passing the response record to set the @invalid flag based on the validity of the response.
The total score is calculated using the below formula

<pre>
(weighted_score / (sum_of_weights * max_question_score)) * 100
</pre>

Any edge cases would return -1 indicating no score

'''Rspec Unit Test : Get_total_scores'''

Following scenarios are tested:

*To return an anticipated total score of a single response without any edge cases. Since this function will be called only on one response at a time, there is no need to test for multiple responses at the same time.
*To return an anticipated total score of a response where nil answer is for a scored question. This is to check if its weight gets removed from the sum_of_weights.
*To return -1 when the sum of weights becomes 0. This can happen when all the scored questions are unanswered. Return value of -1 is checked at the calling function to ensure if a score is returned or not.
*To return -1 when weighted_score of questionnaireData is nil
* To check if submission_valid is called. This method is called to set invalid flag to indicate whether the response entered is valid or not. The validity criteria is explained in the submission_valid? Function.

This unit test uses two stubs and returns mock results
<pre>
ScoreView.stub(:find_by_sql)
</pre>
<pre>
Answer.stub(:where)
</pre>
This is to reduce the outcome of the test to depend on DB calls. For example, in case the connection to DB fails, this unit test would still pass making it less rigid.

'''Function Name : submission_valid?'''

This purpose of this function is to verify the validity of a review based on a deadline. This function obtains a list of AssignmentDueDate objects in descending order which is then compared against the current time to determine which deadlines are valid and which ones are not. The flag variable is used to represent whether or not a deadline was available in the previous iteration of the loop. If the flag is set to TRUE and the deadline is less than the current date, then latest_review_phase_start_time is set to this deadline. A list of ResubmissionTime objects is also retrieved from the controller. These objects are then compared against the then latest_review_phase_start_time variable to determine a response.

Observations: The current implementation of the function is bugged. It retrieves a list of sorted AssignmentDueDate objects and proceeds to check if this list is empty. However, instead of exiting if the function if the list is empty, it carries on execution and raises an exception on hitting the for loop.

*Checks if a review is valid or not by comparing its date with a list of deadlines.
*Returns 1 or 0 depending on validity
*Current implementation is bugged. Throws an exception if no AssignmentDueDate objects are passed, returns nil if any objects are passed.

'''Rspec Unit Test : submission_valid?'''

Following scenarios are tested:

*Passing valid AssignmentDueDate objects
*Not passing any AssignmentDueDate objects

When valid AssignmentDueDate objects are passed, stubs are used to create fake AssignmentDueDate Objects and ResubmissionTime objects. These objects are then populated with valid deadline dates and deadline_type values. These values are then supplied when requested by the submission_valid? Function rather than actually calling the function. The current implementation of this test case expects the program to throw an error when it reaches the for loop. Once this bug is fixed, this test case may be re-written to test a more legitimate test case.

In case an empty list of AssignmentDueDate objects is passed back to the submission_valid?() method. This would cause the function to return nil. When this function is fixed, the following test case may be re-written to test for a more legitimate test-case.

This unit test uses two stubs and returns mock results
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
The above stub returns two AssignmentDueDate objects whenever the where() and order() method are chained on AssignmentDueDate.
<pre>
ResubmissionTime.stub_chain(:where, :order)
</pre>
The above stub returns two ResubmissionTime objects whenever the where() and order() method are chained on ResubmissionTime.
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
This stub is used in the second test case to return nil objects.

the stub_chain method can be used to create stubs where chained methods are expected.

'''Function Name : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

These three functions are sql queries that hit the DB to get a output record after a series of selections and joins. SQL queries that hit DB often do not have a high priority when it comes to testing, so the project does not aggressively test these functions. However, these functions are tested to make sure the queries are able to find the right column names and tables successfully. Any change in the table schema would be detected in these test cases. The functionality of these queries are not tested but instead existence of an output is tested. This ensures that answer.rb is able to make a successful db connection and is sync with the latest db schema. Since the function actually hits the DB, mocks can no longer be used, instead active records were created and saved in test db using FactoryGirl gem from the factories.rb. These records are cleared after every test case.

Following factories were used to create records in the table
*question
*response_record
*response_map
*answer

'''Rspec Unit Test : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

The factories are created such a way that the query would return an output and the tests will pass if the query returns a non nil record. The functionality of these functions would be tested by the integration tests of the controller

'''Validation and Dependency Rspec Test'''

Apart from testing functions, the models are also tested for validations and external dependencies. Model answer.rb does not have any validations but does have a dependency on question.rb. Answer belongs_to question and this was tested using a simple dependency rspec test.
<pre>
it { should belong_to(:question) }
</pre>

'''Rspec Test Results'''

<pre>
1 deprecation warning total

Finished in 12.39 seconds (files took 11.25 seconds to load)
17 examples, 0 failures

Randomized with seed 37447

Coverage report generated for RSpec to /home/root/expertiza/coverage. 998 / 3919 LOC (25.47%) covered.
[Coveralls] Outside the CI environment, not sending data.
root@ubuntu:~/expertiza$
</pre>

CSC/ECE 517 Fall 2016/E1670. Unit tests for answers.rb

2016-10-29T00:12:56Z

Arattili:

==E1670 . Unit tests for answers.rb==

This wiki page is for the description of changes made under E1670 OSS assignment for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to take assignments posted by the course instructors. Expertiza allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on this feedback.

===Project Description===

In Expertiza, each questionnaire contains many questions, those question may have different types (e.g. checkbox, criterion, etc). When a user fills in a rubric, the responses for each question will become an answer record. The responses of rubrics are stored in answers table in DB. The answer.rb is the model for the answers table in DB. Answer.rb model does not have any test cases and the aim of the project is to write fast, effective and flexible unit test cases that offer maximum code coverage.

===Files Created/Modified===
*answer_spec.rb
*factories.rb

===RSpec===
====RSpec Introduction====
RSpec is a testing framework for Ruby for behavior-driven development (BDD) licensed under MIT. It is inspired by JBehave and contains fully integrated JMock based framework which has a very rich and powerful DSL (domain-specific language) which resembles a natural language specification.
Composed of multiple libraries structured to work together, RSpec provides encapsulated testing via the describe block to specify the behavior of the class and the context for the unit test case.

==== Why RSpec? ====
RSpec is easy to learn and implement and can be used with other testing tools like Cucumber and Minitest independently. It is extremely powerful for testing states with complicated setup and also helps in tearing down complex code to access the objects required for testing
RSpec semantics encourage agile thinking and practice and it structures the tests in a more intuitive way.

===Functions in answers.rb===

'''Function Name : Compute_scores'''

Compute_scores is a function in model answer.rb which gives the average, maximum and minimum scores obtained in a series a responses/assessments. It has two input parameters: List of assessments and questions. The function iterates over each assessment to get the total score of that assessment. If the response or review is invalid, that assessment won’t be considered in the calculation of the score average. After iterating over all assessments, Max score, and Min scores are calculated along with the average score based on the number of valid assessments. Their scores are returned by the function.

'''Rspec Unit Test : Compute_scores'''

Following scenarios are tested:

* To return scores as nil if the input list of assessments is nil. This is to make sure no Null Pointer exceptions are thrown by the code
*To return a particular score when a single valid assessment is given as an input.
*To return a particular score when multiple valid assessments are given as an input. This is to test the looping functionality of the method.
*To return a particular score when invalid assessments are given as an input. The validity and total scores are returned by a mock and not by the actual functions. This is to make the test cases less rigid so that failure of dependent functions do not disrupt the functionality of interface level tests.
*To return a particular score when invalid flag is nil. Invalid flag can either be 0,1 or nil. Nil situation is tested to prevent NullPointer Exceptions
*To check if the method get_total_score is called with the right parameters.

This unit test uses a stub and returns a mock value.
<pre>
Answer.stub(:get_total_score)
</pre>
This is to eliminate tight coupling between compute_scores and get_total_scores. Failure in get_total_scores wouldn't break the compute_scores test cases.

'''Function Name : Get_total_scores'''

This function is called by the Compute_scores method of the answer.rb model to compute the total score of an assessment. The input consists of assessment for which the total score is being calculated and the list of questions being evaluated in the assessment. The method uses questionnaire id from the questions and response id to obtain a score view questionnaire data. This score view is a read-only record. The questionnaire data mainly consists of q1_max_question_score, sum_of_weights and weighted_score. Before calculating the score, the function performs two crucial tasks.
*Checks if the answer for a scored question is nil. If it is nil or unanswered, the question will be ignored and not counted towards the score of this response.
* Calls the submission_valid function by passing the response record to set the @invalid flag based on the validity of the response.
The total score is calculated using the below formula

<pre>
(weighted_score / (sum_of_weights * max_question_score)) * 100
</pre>

Any edge cases would return -1 indicating no score

'''Rspec Unit Test : Get_total_scores'''

Following scenarios are tested:

*To return an anticipated total score of a single response without any edge cases. Since this function will be called only on one response at a time, there is no need to test for multiple responses at the same time.
*To return an anticipated total score of a response where nil answer is for a scored question. This is to check if its weight gets removed from the sum_of_weights.
*To return -1 when the sum of weights becomes 0. This can happen when all the scored questions are unanswered. Return value of -1 is checked at the calling function to ensure if a score is returned or not.
*To return -1 when weighted_score of questionnaireData is nil
* To check if submission_valid is called. This method is called to set invalid flag to indicate whether the response entered is valid or not. The validity criteria is explained in the submission_valid? Function.

This unit test uses two stubs and returns mock results
<pre>
ScoreView.stub(:find_by_sql)
</pre>
<pre>
Answer.stub(:where)
</pre>
This is to reduce the outcome of the test to depend on DB calls. For example, in case the connection to DB fails, this unit test would still pass making it less rigid.

'''Function Name : submission_valid?'''

This purpose of this function is to verify the validity of a review based on a deadline. This function obtains a list of AssignmentDueDate objects in descending order which is then compared against the current time to determine which deadlines are valid and which ones are not. The flag variable is used to represent whether or not a deadline was available in the previous iteration of the loop. If the flag is set to TRUE and the deadline is less than the current date, then latest_review_phase_start_time is set to this deadline. A list of ResubmissionTime objects is also retrieved from the controller. These objects are then compared against the then latest_review_phase_start_time variable to determine a response.

Observations: The current implementation of the function is bugged. It retrieves a list of sorted AssignmentDueDate objects and proceeds to check if this list is empty. However, instead of exiting if the function if the list is empty, it carries on execution and raises an exception on hitting the for loop.

*Checks if a review is valid or not by comparing its date with a list of deadlines.
*Returns 1 or 0 depending on validity
*Current implementation is bugged. Throws an exception if no AssignmentDueDate objects are passed, returns nil if any objects are passed.

'''Rspec Unit Test : submission_valid?'''

Following scenarios are tested:

*Passing valid AssignmentDueDate objects
*Not passing any AssignmentDueDate objects

When valid AssignmentDueDate objects are passed, stubs are used to create fake AssignmentDueDate Objects and ResubmissionTime objects. These objects are then populated with valid deadline dates and deadline_type values. These values are then supplied when requested by the submission_valid? Function rather than actually calling the function. The current implementation of this test case expects the program to throw an error when it reaches the for loop. Once this bug is fixed, this test case may be re-written to test a more legitimate test case.

In case an empty list of AssignmentDueDate objects is passed back to the submission_valid?() method. This would cause the function to return nil. When this function is fixed, the following test case may be re-written to test for a more legitimate test-case.

This unit test uses two stubs and returns mock results
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
The above stub returns two AssignmentDueDate objects whenever the where() and order() method are chained on AssignmentDueDate.
<pre>
ResubmissionTime.stub_chain(:where, :order)
</pre>
The above stub returns two ResubmissionTime objects whenever the where() and order() method are chained on ResubmissionTime.
<pre>
AssignmentDueDate.stub_chain(:where, :order)
</pre>
This stub is used in the second test case to return nil objects.

the stub_chain method can be used to create stubs where chained methods are expected.

'''Function Name : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

These three functions are sql queries that hit the DB to get a output record after a series of selections and joins. SQL queries that hit DB often do not have a high priority when it comes to testing, so the project does not aggressively test these functions. However, these functions are tested to make sure the queries are able to find the right column names and tables successfully. Any change in the table schema would be detected in these test cases. The functionality of these queries are not tested but instead existence of an output is tested. This ensures that answer.rb is able to make a successful db connection and is sync with the latest db schema. Since the function actually hits the DB, mocks can no longer be used, instead active records were created and saved in test db using FactoryGirl gem from the factories.rb. These records are cleared after every test case.

Following factories were used to create records in the table
*question
*response_record
*response_map
*answer

'''Rspec Unit Test : answers_by_question, answers_by_question_for_reviewee,answers_by_question_for_reviewee_in_round'''

The factories are created such a way that the query would return an output and the tests will pass if the query returns a non nil record. The functionality of these functions would be tested by the integration tests of the controller

'''Validation and Dependency Rspec Test'''

Apart from testing functions, the models are also tested for validations and external dependencies. Model answer.rb does not have any validations but does have a dependency on question.rb. Answer belongs_to question and this was tested using a simple dependency rspec test.
<pre>
it { should belong_to(:question) }
</pre>

'''Rspec Test Results'''

<pre>
1 deprecation warning total

Finished in 12.39 seconds (files took 11.25 seconds to load)
17 examples, 0 failures

Randomized with seed 37447

Coverage report generated for RSpec to /home/attili/expertiza/coverage. 998 / 3919 LOC (25.47%) covered.
[Coveralls] Outside the CI environment, not sending data.
root@ubuntu:~/expertiza$
</pre>

CSC/ECE 517 Fall 2016/E1670. Unit tests for answers.rb

2016-10-28T05:24:40Z

Arattili:

==E1670 . Unit tests for answers.rb==

This wiki page is for the description of changes made under E1670 OSS assignment for Fall 2016, CSC/ECE 517.

__TOC__

===Background===

Expertiza is an Open Source web application developed on Ruby On Rails platform. It is a platform which allows students to take assignments posted by the course instructors. Expertiza allows students to select assignment topics, form teams and submit their work. It also allows them to review other students' submissions and improve their work based on this feedback.

===Project Description===

In Expertiza, each questionnaire contains many questions, those question may have different types (e.g. checkbox, criterion, etc). When a user fills in a rubric, the responses for each question will become an answer record. The responses of rubrics are stored in answers table in DB. The answer.rb is the model for the answers table in DB. Answer.rb model does not have any test cases and the aim of the project is to write fast, effective and flexible unit test cases that offer maximum code coverage.

===Functions in answers.rb===

'''Function Name : Compute_scores'''

Compute_scores is a function in model answer.rb which gives the average, maximum and minimum scores obtained in a series a responses/assessments. It has two input parameters: List of assessments and questions. The function iterates over each assessment to get the total score of that assessment. If the response or review is invalid, that assessment won’t be considered in the calculation of the score average. After iterating over all assessments, Max score, and Min scores are calculated along with the average score based on the number of valid assessments. Their scores are returned by the function.

'''Rspec Unit Test : Compute_scores'''

Following scenarios are tested:

* To return scores as nil if the input list of assessments is nil. This is to make sure no Null Pointer exceptions are thrown by the code
*To return a particular score when a single valid assessment is given as an input.
*To return a particular score when multiple valid assessments are given as an input. This is to test the looping functionality of the method.
*To return a particular score when invalid assessments are given as an input. The validity and total scores are returned by a mock and not by the actual functions. This is to make the test cases less rigid so that failure of dependent functions do not disrupt the functionality of interface level tests.
*To return a particular score when invalid flag is nil. Invalid flag can either be 0,1 or nil. Nil situation is tested to prevent NullPointer Exceptions
*To check if the method get_total_score is called with the right parameters.

This unit tes uses a stub and returns a mock value.
<pre>
Answer.stub(:get_total_score)
</pre>
This is to eliminate tight coupling between compute_scores and get_total_scores. Failure in get_total_scores would'nt break the compute_scores test cases.

'''Function Name : Get_total_scores'''

This function is called by the Compute_scores method of the answer.rb model to compute the total score of an assessment. The input consists of assessment for which the total score is being calculated and the list of questions being evaluated in the assessment. The method uses questionnaire id from the questions and response id to obtain a score view questionnaire data. This score view is a read-only record. The questionnaire data mainly consists of q1_max_question_score, sum_of_weights and wieghted_score. Before calculating the score, the function performs two crucial tasks.
*Checks if the answer for a scored question is nil. If it is nil or unanswered, the question will be ignored and not counted towards the score of this response.
* Calls the subsission_valid function by passing the response record to set the @invalid flag based on the validity of the response.
The total score is calculated using the below formula

<pre>
(weighted_score / (sum_of_weights * max_question_score)) * 100
</pre>

Any edge cases would return -1 indicating no score

'''Rspec Unit Test : Get_total_scores'''

Following scenarios are tested:

*To return an anticipated total score of a single response without any edge cases. Since this function will be called only on one response at a time, there is no need to test for multiple responses at the same time.
*To return an anticipated total score of a response where nil answer is for a scored question. This is to check if its weight gets removed from the sum_of_weights.
*To return -1 when the sum of weights becomes 0. This can happen when all the scored questions are unanswered. Return value of -1 is checked at the calling function to ensure if a score is returned or not.
*To return -1 when weighted_score of questionnaireData is nil
* To check if submission_valid is called. This method is called to set invalid flag to indicate whether the response entered is valid or not. The validity criteria is explained in the submission_valid? Function.

This unit test uses two stubs and returns mock results
<pre>
ScoreView.stub(:find_by_sql)
</pre>
<pre>
Answer.stub(:where)
</pre>
This is to reduce the outcome of the test to depend on DB calls. For example, in case the connection to DB fails, this unit test would still pass making it less rigid.

'''Function Name : submission_valid?'''

This purpose of this function is to verify the validity of a review based on a deadline. This function obtains a list of AssignmentDueDate objects in decending order which are then compared against the current time to determine which deadlines are valid and which ones are not. The flag variable is used to represent whether or not a deadline was available in the previous iteration of the loop. If the flag is set to TRUE and the deadline is less than current date, then latest_review_phase_start_time is set to this deadline. A list of ResubmissionTime objects are also retrieved from the controller. These objects are then compared against the then latest_review_phase_start_time variable to determine a response.

Observations: The current implementation of the function is bugged. It retrieves a list of sorted AssignmentDueDate objects and proceeds to check if this list is empty. However, instead of exiting if the function if the list is empty, it carries on execution and raises an exception on hitting the for loop.

*Checks if a review is valid or not by comparing its date with a list of deadlines.
*Returns 1 or 0 depending on validity
*Current implementation is bugged. Throws an exception if no AssignmentDueDate objects are passed, returns nil if any objects are passed.

'''Rspec Unit Test : submission_valid?'''

Following scenarios are tested:

*Passing valid AssignmentDueDate objects
*Not passing any AssignmentDueDate objects

When valid AssignmentDueDate objects are passed, stubs are used to create fake AssignmentDueDate Objects and ResubmissionTime objects. These objects are then populated with valid deadline dates and deadline_type values. These values are then supplied when requested by the submission_valid? Function rather than actually calling the function. The current implementation of this test case expects the program to throw an error when it reaches the for loop. Once this bug is fixed, this test case may be re-written to test a more legitimate test case.

In case an empty list of AssignmentDueDate objects is passed back to the submission_valid?() method. This would cause the function to return nil. When this function is fixed, the following test case may be re-written to test for a more legitimate test-case.

This unit test uses two stubs and returns mock results
<pre>
AssignmentDueDate.stub_chain(:where, :order).and_return(due_date1, due_date2)
</pre>
The above stub returns two AssignmentDueDate objects whenever the where() and order() method are chained on AssignmentDueDate.
<pre>
ResubmissionTime.stub_chain(:where, :order).and_return(ResubmissionTime1, ResubmissionTime2)
</pre>
The above stub returns two ResubmissionTime objects whenever the where() and order() method are chained on ResubmissionTime.
<pre>
AssignmentDueDate.stub_chain(:where, :order).and_return(nil)
</pre>
This stub is used in the second test case to return nil objects.

the stub_chain method can be used to create stubs where chained methods are expected.