Expertiza_Wiki - User contributions [en]

File:Jjj259.png

2018-12-18T18:21:08Z

Wwu24: uploaded a new version of "File:Jjj259.png"

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-12-18T18:19:30Z

Wwu24: /* Result */

==''' Introduction '''==

=== Background ===
One of the fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answering these questions. The team did that job can also get a detailed feedback for different aspects of the project.

=== Motivation ===
One of the problems for the review system is that for each assignment, different topics are included. Students can choose the one topic they like, and those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, the topic can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have the same rubric, which may lead to unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assigning different rubies for different projects in a specified appointment.

==''' Analysis & Plan '''==

To realize such purpose, we have the following tasks need to be done:

===Check Box===
For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.

[[File:2018F1873rubric.png]]

===Dropdown List===
To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. The number of dropdown list should decide by review round number. Therefore, each time users choose to identify different rubrics for different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.

[[File:2018F1873project.png]]

===Controller===
Make changes to the controller so that these functions can work. Most of our logic control codes will be written in ''helpers/sign_up_sheet_helper.rb''.

logic flowchart:

[[File:umlj.png]]

===Database===
Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

[[File:379jjj.png]]

===Test===
Test what we changed to make sure it works as intended and not influence the original system.

==''' Implement Steps '''==

=== Task 1 Add checkbox===
1. edit the file views/assignments/edit/_rubrics.html.erb

2. add a checkbox at the top of the page which says "Vary rubric by topic"

3. set the default state for this checkbox as unchecked

===Task 2 Add dropdown list===
1. edit the file views/assignment/edit/_general.html.erb

2. add a variable to indicate if the checkbox said in Task 1 is checked

3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list

4. edit the file views/sign_up_sheet/_table_line.html.erb

5. add the code to render the dropdown list

6. making a judgment before rendering the dropdown list, only if the checkbox in Task 1ist checked to render the page

===Task 3 Change controllers===
Change the update method in sign_up_sheet_controller.rb to make sure when new rubric is chosen for a specific topic, it can be stored in the database properly

===Task 4 Create migration===
1. create a new migration to add questionnaire_id in sign_up_topics

2. the questionnaire_id is a foreign key which references to questionnaires

3. change the file models/sign_up_topic.rb, and add the relations with the questionnaire, the relation between them is one-to-one

===Task 5 Test the changes===
1. make a test plan for the features that need to be tested

2. follow the test plan to write automatic test codes

3. evaluate the results and refactor codes

==''' Test plan '''==
We mainly use cucumber and capybara to test UI, and the following are detailed plans

===Test checkbox===
1. go to the rubrics page under the assignment

2. we can see the checkbox says "Vary rubric by topic" shows on this page

3. the initial state of the checkbox is unchecked

===Test dropdown list===
====Scenario 1====
1. the checkbox "Vary rubric by topic" is unchecked

2. go to the topics page under assignment

3.there are no dropdown lists beside topics
====Scenario 2====
1. the checkbox "Vary rubric by topic" is checked

2. go to the topics page under assignment

3. the table to show the topics have a row called "rubrics"

4. under this title, each topic has a dropdown list

==''' Result '''==
[[File:Www11.png]]
[[File:Jjj259.png]]
===Test===
Instead of testing UI, we did some unit tests using Rspec.

For testing update_topic_questionnaires.
*when attributes are nil
<pre>
it 'returns false' do
expect(assignment_form.update_topic_questionnaires(nil)).to be false
end
</pre>
*when attributes are not nil and at least one topic_questionnaire's id is nil or blank
<pre>
let(:attributes) { [topic_questionnaire, topic_questionnaire2] }
before(:each) do
allow(topic_questionnaire).to receive(:[]).with(:id).and_return(nil)
allow(topic_questionnaire2).to receive(:[]).with(:id).and_return(1)
allow(TopicQuestionnaire).to receive(:where).with(sign_up_topic_id: SignUpTopic.where(assignment_id: 1)).and_return([])
allow(TopicQuestionnaire).to receive(:new).with(topic_questionnaire).and_return(topic_questionnaire)
allow(TopicQuestionnaire).to receive(:find).with(1).and_return(topic_questionnaire2)
end
</pre>
*when both save and update_attributes method do not work
<pre>
it 'changes @has_errors value to true and returns attributes (args)' do
allow(topic_questionnaire).to receive(:save).and_return(false)
allow(topic_questionnaire2).to receive(:update_attributes).with(topic_questionnaire2).and_return(false)
expect(assignment_form.update_topic_questionnaires(attributes)).to eq(attributes)
expect(assignment_form.instance_variable_get(:@has_errors)).to be true
end
</pre>
*when both save and update_attributes method work well
<pre>
it 'returns attributes (args) and @has_errors value is nil' do
allow(topic_questionnaire).to receive(:save).and_return(true)
allow(topic_questionnaire2).to receive(:update_attributes).with(topic_questionnaire2).and_return(true)
expect(assignment_form.update_topic_questionnaires(attributes)).to eq(attributes)
expect(assignment_form.instance_variable_get(:@has_errors)).to be nil
end
</pre>

For testing review_by_rounds, check the number of rounds which decides the rounds of the questionnaire that each assignment needs.
*when used in round is nil
<pre>
it 'returns false' do
expect(@review_by_rounds).to be nil
end
</pre>

File:Jjj259.png

2018-12-18T18:18:37Z

Wwu24:

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-12-18T18:17:21Z

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:39:41Z

Wwu24: /* Test dropdown list= */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===
<pre>change update method in sign_up_sheet_controller.rb to make sure when new rubric is chosen for a specific topic, it can be stored in the database properly</pre>

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

===Task 5 Test the changes===
<pre>1. make a test plan for the features that need to be tested
2. follow the test plan to write automatic test codes
3. evaluate the results and refactor codes</pre>

= Test plan =
We mainly use cucumber and capybara to test UI, and the following are detailed plans

==Test checkbox==
1. go to the rubrics page under the assignment
2. we can see the checkbox says "Vary rubric by topic" shows on this page
3. the initial state of the checkbox is unchecked

==Test dropdown list==
===Scenario 1===
<pre>1. the checkbox "Vary rubric by topic" is unchecked
2. go to the topics page under assignment
3.there are no dropdown lists beside topics</pre>
===Scenario 2===
<pre>1. the checkbox "Vary rubric by topic" is checked
2. go to the topics page under assignment
3. the table to show the topics have a row called "rubrics"
4. under this title, each topic has a dropdown list</pre>

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:39:30Z

Wwu24: /* Test dropdown list= */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===
<pre>change update method in sign_up_sheet_controller.rb to make sure when new rubric is chosen for a specific topic, it can be stored in the database properly</pre>

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

===Task 5 Test the changes===
<pre>1. make a test plan for the features that need to be tested
2. follow the test plan to write automatic test codes
3. evaluate the results and refactor codes</pre>

= Test plan =
We mainly use cucumber and capybara to test UI, and the following are detailed plans

==Test checkbox==
1. go to the rubrics page under the assignment
2. we can see the checkbox says "Vary rubric by topic" shows on this page
3. the initial state of the checkbox is unchecked

==Test dropdown list===
===Scenario 1===
<pre>1. the checkbox "Vary rubric by topic" is unchecked
2. go to the topics page under assignment
3.there are no dropdown lists beside topics</pre>
===Scenario 2===
<pre>1. the checkbox "Vary rubric by topic" is checked
2. go to the topics page under assignment
3. the table to show the topics have a row called "rubrics"
4. under this title, each topic has a dropdown list</pre>

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:38:41Z

Wwu24: /* Test plan */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===
<pre>change update method in sign_up_sheet_controller.rb to make sure when new rubric is chosen for a specific topic, it can be stored in the database properly</pre>

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

===Task 5 Test the changes===
<pre>1. make a test plan for the features that need to be tested
2. follow the test plan to write automatic test codes
3. evaluate the results and refactor codes</pre>

= Test plan =
We mainly use cucumber and capybara to test UI, and the following are detailed plans

==Test checkbox==
1. go to the rubrics page under the assignment
2. we can see the checkbox says "Vary rubric by topic" shows on this page
3. the initial state of the checkbox is unchecked

==Test dropdown list===
===Scenario 1===
1. the checkbox "Vary rubric by topic" is unchecked
2. go to the topics page under assignment
3.there are no dropdown lists beside topics
===Scenario 2===
1. the checkbox "Vary rubric by topic" is checked
2. go to the topics page under assignment
3. the table to show the topics have a row called "rubrics"
4. under this title, each topic has a dropdown list

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:31:37Z

Wwu24: /* Test plan */

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:31:18Z

Wwu24: /* Test plan */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===
<pre>change update method in sign_up_sheet_controller.rb to make sure when new rubric is chosen for a specific topic, it can be stored in the database properly</pre>

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

===Task 5 Test the changes===
<pre>1. make a test plan for the features that need to be tested
2. follow the test plan to write automatic test codes
3. evaluate the results and refactor codes</pre>

= Test plan =
We mainly use�� cucumber and capybara to test UI, and the following are detailed plans

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:27:07Z

Wwu24: /* Design */

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:26:26Z

Wwu24: /* Task 3 Change controllers */

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:20:03Z

Wwu24: /* Task 4 Create migration */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

===Task 5 Test the changes===
<pre>1. make a test plan for the features that need to be tested
2. follow the test plan to write automatic test codes
3. evaluate the results and refactor codes</pre>

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T21:14:43Z

Wwu24: /* Task 4 Create migration */

= Introduction =

== Background ==
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

= Design =

== Tasks ==

To realize such purpose, we have the following tasks need to be done:

1. For current design, the rubric used for a specified assignment is set at the following page. To make sure users can choose to set different rubrics for different projects, we need first add a checkbox at this page. Therefore, users can use this box to indicate if they want to use the same rubric for all the projects or set some different rubrics for some projects.
[[File:2018F1873rubric.png]]

2.To make sure users can choose rubrics for each project, we should add a new dropdown list beside each project in the following page. Therefore, each time users choose to identify different rubrics fro different projects, the list will appear and users can choose proper rubrics. The default rubric set at last page will be overwritten in this case.
[[File:2018F1873project.png]]

3.Make changes to the controller so that these functions can work.

4. Add questionnaire_id in sign_up_topics table to make sure the projects can always relate to correct rubrics

5. Test what we changed to make sure it works as intended and not influence the original system.

== Technical design ==

=== Task 1 Add checkbox===
<pre>1. edit the file views/assignments/edit/_rubrics.html.erb
2. add a checkbox at the top of the page which says "Vary rubric by topic"
3. set the default state for this checkbox as unchecked</pre>

===Task 2 Add dropdown list===
<pre>1. edit the file views/assignment/edit/_general.html.erb
2. add a variable to indicate if the checkbox said in Task 1 is checked
3. create a new file under views/sign_up_sheet called "_rubrics_list.html.erb" to store the code for the dropdown list
4. edit the file views/sign_up_sheet/_table_line.html.erb
5. add the code to render the dropdown list
6. making a judgment before render the dropdown list, only if the checkbox in Task 1is checked render the page
</pre>

===Task 3 Change controllers===

===Task 4 Create migration===
<pre>1. create a new migration to add questionnaire_id in sign_up_topics
2. the questionnaire_id is a foreign key which references to questionnaires
3. change the file models/sign_up_topic.rb, and add the relations with questionnaire, the relation between them is one-to-one</pre>

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T17:06:50Z

Wwu24: /* Motivation */

== Introduction ==

=== Background ===
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

=== Motivation ===
There is problem that for each assignment, it includes several different topics and students can choose from these topics as they like. Those topics fall into different categories. That is, an assignment always include different kind of projects. In Expertiza, these projects can be refactoring projects, testing projects, Mozilla projects, etc. Apparently, for different kinds of projects, we have different criteria to evaluate their performance. However, due to the current design of the system, all projects belong to the same assignment can only have one same rubric, which may lead unnecessary criteria for some projects and inadequate criteria for other projects.
To make sure all kinds of projects can be evaluated properly. We plan to refactor the system to allow assign different rubies for different projects in a specified appointment.

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T16:56:33Z

Wwu24:

CSC/ECE 517 Fall 2018/E1873 Specialized rubics for different topic types

2018-11-12T16:53:34Z

Wwu24: /* Introduction */

[http://www.example.com link title]== Introduction ==

=== Background ===
One of fantastic features that Expertiza provides is for each assignment, it allows students providing reviews for others' jobs. This is done by offering a pre-defined questionnaire for the whole assignment, which is called the rubric for this assignment. Each rubric has several questions, each question provides a criterion to evaluate the performance from a specific angle. Then students can evaluate the entire job by rating and answer these questions. The team did that job can also get a detailed feedback for different aspects of the project.

== Motivation ==

2018-11-10T02:54:49Z

Wwu24: /* File Involvement */

For this progect, the goal is to wirte up unit tests for assignment_team.rb

==Project Introduction==
====Background====
assignment_team.rb is the child class of team.rb. It is used to handle multiple problems relates to team in the assignment. Its responsibilities can mainly fall in three categories: participant of the team, reviews of the team, and the operation for the whole team. For the participant, it can be used to decide if a participant is in a given team and view the members of the team or remove a member. For reviews, it deals with the problem that getting the reviews for the team, assign reviewer for the team and get if the team has been reviewed by a specific reviewers. For the whole team, we can delete the team or view the scores, etc. by using this class.
====Motivation====
Make sure assignment_team.rb provides all functions as expected is important for the whole system. It requires enough tests for all the functions and the edge cases may occur. However, there are not enough unit tests for this model in expertiza. The following tests are added to assignment_team.rb in this project.

==Memebers of Project==
Jianshu Zhang

Wanjing Kuang

Wei Wu

==Mentor==
Zhewei Hu

==File Involvement==
1.app/models/assignment_team.rb

2.spec/models/assignment_team_spec.rb

3.spec/factories/factories.rb

==Test Plan==
1. two test cases for method "include?": When the team includes a given participant and When the team doesn't include a given participant

2. one test case for method "parent_model": It returns "Assignment" when the method is called.

3. two test cases for method "self.parent_model(id)": When it's given a correct id and When it's given an incorrect id.

4. one test case for method "fullname": When the participant has an full name.

5. one test case for method "review_map_type": It returns ReviewResponseMap when the method is called.

6. one test case for method "self.prototype": It returns an new instance of AssignmentTeam when the method is called.

7. two test cases for method "assign_reviewer(reviewer)": When the team has an assignment and When the assignment record can not be found.

8. one test case for method "reviewd_by?": When it gets correct reviewer and returns true as an result.

9. one test case for method " topic": When it returns the correct id.

10. three test cases for method "has_submissions?": When the team doesn't submit any file or link, when team submits a link instead of files and
when the team submits some files.

11. two test cases for method "participants": When no participants in this team and When adding some participants and get all the participants.

12. one test case for method "add_participant": When adding an participant, it will return an instance of AssignmentParticipant.

13. two test cases for method " delete and destroy": Testing delete and destory.

==Unit Tests==

===Unit Test Tool===
Rspec

===Unit Test File===
expertiza/spec/models/assignment_team_spec.rb

===Unit Test Steps===

*Create unit test cases in the assignment_team_spec.rb

*run rspec spec/models/assignment_team_spec.rb under expertiza directory

*the rspec outputs the number of test cases that are passed and those that are failed.

===Unit Test Cases===

====Testing include?====
2 test cases are designed to test this method:

1. The team includes a given participant.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, parent_id: 1, name: "full name") }
let(:participant1) { build(:participant, id: 2, user: user) }
it "returns true" do
allow(assignment_team).to receive(:add_participants).with(participant1)
expect(assignment_team.includes?(participant1))
end
</pre>

2. The team doesn't include a given participant.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, parent_id: 1, name: "full name") }
let(:participant1) { build(:participant, id: 2, user: user) }
let(:participant2) { build(:participant, id: 3) }
it "returns false" do
allow(assignment_team).to receive(:add_participants).with(participant1)
expect(assignment_team.includes?(participant2))
end
</pre>

====Testing parent_model====
1 test case is designed to test this method:

<pre>
it "returns Assignment as result" do
expect(assignment_team.parent_model).to eq("Assignment")
end
</pre>

====Testing self.parent_model(id)====
2 test cases are designed to test this method:

1.When it's given a correct id.
<pre>
let(:assignment) { build(:assignment, id: 1) }
it "returns an assignemt" do
allow(Assignment).to receive(:find).with(1).and_return(assignment)
expect(AssignmentTeam.parent_model(1)).to eq(assignment)
end
</pre>

2.When it's given an incorrect id.
<pre>
it "raises an exception" do
expect { AssignmentTeam.parent_model 2 }.to raise_exception(ActiveRecord::RecordNotFound)
end
</pre>

====Testing fullname====
1 test case is designed to test this method:

<pre>
it "returns the full name of assignment team" do
expect(assignment_team.fullname).to eq("full name")
end
</pre>

====Testing review_map_type====
1 test case is designed to test this method:

<pre>
it "returns ReviewResponseMap as result" do
expect(assignment_team.review_map_type).to eq("ReviewResponseMap")
end
</pre>

====Testing self.prototype====
1 test cases is designed to test this method:

<pre>
it "returns an new instance of AssignmentTeam" do
expect(AssignmentTeam.prototype).to be_instance_of(AssignmentTeam)
end
</pre>

====Testing assign_reviewer(reviewer)====
2 test cases are designed to test this method:

1. When the team has an assignment.
<pre>
let(:reviewer) { build(:participant, id: 1) }
it "returns an instance of ReviewResponseMap" do
expect(assignment_team.assign_reviewer(reviewer)).to be_instance_of(ReviewResponseMap)
end
</pre>

2. When the assignment record can not be found
<pre>
let(:assignment_team2) { build(:assignment_team, id: 2, parent_id: 2) }
it "returns an exception" do
expect { assignment_team2.assign_reviewer(reviewer) }.to raise_exception(ActiveRecord::RecordNotFound)
end
</pre>

====Testing reviewd_by?====
1 test case is designed to test this method:

<pre>
it "returns true" do
allow(ReviewResponseMap).to receive(:where).\
with('reviewee_id = ? && reviewer_id = ? && reviewed_object_id = ?', 1, 1, 1).and_return([review_response_map])
expect(assignment_team.reviewed_by?(reviewer)).to be true
end
</pre>

====Testing topic====
1 test case is designed to test this method:

<pre>
let(:signed_up_team) { build(:signed_up_team, id: 1, team_id: 1, is_waitlisted: 0, topic_id: 1) }
it "returns a topic id" do
allow(SignedUpTeam).to receive(:find_by).with(team_id: 1, is_waitlisted: 0).and_return(signed_up_team)
expect(assignment_team.topic).to eq(1)
end
</pre>

====Testing has_submissions? ====
3 test cases are designed to test this method:

1.The team doesn't submit any file or link.

<pre>
let(:team2) { build(:assignment_team, id: 2, parent_id: 1, name: "team2", submitted_hyperlinks: "") }
it "no file or no link" do
expect(team2.has_submissions?).to eq(false)
end
</pre>

2.The team submits a link instead of files.

<pre>
let(:team1) { build(:assignment_team, id: 1, parent_id: 1, name: "team1", submitted_hyperlinks: "http://example.com") }
it "submitted hyperlinks" do
expect(team1.has_submissions?).to eq(true)
end
</pre>

3. The team submits some files. Stub is used to emulate the scenario that the team has submitted a file.

<pre>
it "returns true" do
allow(team2).to receive(:submitted_files).and_return([double(:File)])
expect(team2.has_submissions?).to be true
end
</pre>

====Testing participants ====

1. No participants in this team

<pre>
it '#no participant' do
expect(team1.participants).to eq([])
end
</pre>

2. add some participants and get all the participants

<pre>
let(:student1) { build(:student, id: 1, name: 'johns', fullname: 'johns franklin') }
let(:student2) { build(:student, id: 2, name: 'kate', fullname: 'kate moss') }
let(:par1) { build(:participant, id: 1, parent_id: 1, user_id: 1) }
let(:par2) { build(:participant, id: 2, parent_id: 1, user_id: 2) }
it '#1 participant' do
allow(AssignmentTeam).to receive(:users).with(id: team1.id).and_return([student1,student2])
expect(team1.participants).to eq([par1, par2])
end
</pre>

====Testing add_participant ====

<pre>
it '#add participants' do
expect(team1.add_participant(ass1.id, par1)).to be_instance_of(AssignmentParticipant)
end
</pre>

====Testing the delete and destroy====

<pre>
it '#delete' do
expect(team1.delete).to be_instance_of(AssignmentTeam)
end
</pre>

<pre>
it '#destroy' do
expect(team1.destroy).to be_instance_of(AssignmentTeam)
end
</pre>

====Testing members====

<pre>
it '#get_first_member' do
allow(AssignmentTeam).to receive(:find_by).with(id: team1.id).and_return(team1)
allow(team1).to receive(:participants).and_return([par1, par2])
expect(AssignmentTeam.get_first_member(team1.id)).to eq(par1)
end
</pre>

====Testing import and export====

1. import a team to a non-existing assignment and expect an exception

<pre>
it '#import an nonexisting assignment id' do
row = {teamname: "hello_world", teammembers: %w[johns kate]}
options = {has_teamname: "true_first"}
expect { AssignmentTeam.import(row, 99_999, options) }.to raise_error(ImportError)
end
</pre>

2. export teams into a csv file

<pre>
it '#export' do
options = {}
csv = CSV.open("assignment_team_export.csv", "w")
assignment_id = ass1.id
allow(AssignmentTeam).to receive(:where).with(parent_id: assignment_id).and_return([team1, team2, team3])
allow(TeamsUser).to receive(:where).and_return([par1, par2])
expect(AssignmentTeam.export(csv, assignment_id, options)).to be_instance_of(CSV)
end
</pre>

====Testing copy====

<pre>
it '#copy' do
allow(TeamsUser).to receive(:where).with(team_id: team1.id).and_return([par1])
expect(team1.copy(course1.id)).to eq([par1])
end
</pre>

====Testing hyperlinks====
2 test cases are designed to test this method:

1. when the current teams submitted hyperlinks

<pre>
let(:assignment_team) { build(:assignment_team) }
context "when current teams submitted hyperlinks" do
it "returns the hyperlinks submitted by the team" do
expect(assignment_team.hyperlinks).to eq(["https://www.expertiza.ncsu.edu"])
end
end
</pre>

2. when current teams did not submit hyperlinks

<pre>
let(:team_without_submitted_hyperlinks) { build(:assignment_team, submitted_hyperlinks: "") }
context "when current teams did not submit hyperlinks" do
it "returns an empty array" do
expect(team_without_submitted_hyperlinks.hyperlinks).to eq([])
end
end
</pre>

====Testing files====

<pre>
before :each do
@directory = "a"
@files = ["b.txt", "c.java", "d.txt"]
@files1 = ["b/c", "d/e"]
end
it "call the method in Dir" do
expect(Dir).to receive(:[]).with(@directory + "/*").and_return(@files)
assignment_team.files(@directory)
end
</pre>

====Testing submit_hyperlink====
3 test cases are designed to test this method:

1. when the hyperlink is empty

<pre>
context "when the hyperlink is empty" do
it "raise excpetion" do
expect{(assignment_team.submit_hyperlink(""))}.to raise_error('The hyperlink cannot be empty!')
end
</pre>

2. when the hyperlink is not empty and it calls the method on NET::HTTP

<pre>
before :each do
@link = "htp.aa/.."
end
it "call the method on NET::HTTP" do
expect(Net::HTTP).to receive(:get_response).with(URI(@link+'http://'))
assignment_team.submit_hyperlink(@link)
end
</pre>

3. when the hyperlink is not empty and it raises error

<pre>
it "raise error" do
allow(Net::HTTP).to receive(:get_response).with(URI(@link+'http://')).and_return("402")
expect{(assignment_team.submit_hyperlink(@link))}.to raise_error('HTTP status code: 402')
end
</pre>

====Testing remove_hyperlink====

<pre>
before :each do
@hyperlink = "http://a.com"
end
it 'call the hyperlinks method' do
expect(assignment_team).to receive(:hyperlinks).and_return(["https://www.expertiza.ncsu.edu"])
assignment_team.remove_hyperlink(@hyperlink)
end
</pre>

====Testing team====
3 test cases are designed to test this method

1. when the participant is nil then this method will return nil

<pre>
context 'when the participant is nil then this method will return nil' do
it 'the participant is nil' do
expect(AssignmentTeam.team(nil)).to eq(nil)
end
end
</pre>

2. when it can find the participant

<pre>
let(:participant) { build(:participant) }
context 'can find the participant' do
it 'send the correct user_id to the TeamsUser.where method' do
expect(TeamsUser).to receive(:where).with(user_id: participant.user_id).and_return([team_user])
AssignmentTeam.team(participant)
end
</pre>

3. when the team user exists

<pre>
let(:team_user) { build(:team_user) }
context 'the team user exists' do
before :each do
allow(TeamsUser).to receive(:where).with(user_id: 1).and_return([team_user])
AssignmentTeam.team(participant)
end
</pre>

====Testing export_fields====
2 test cases are designed to test this method

1. when the team_name equals false

<pre>
it 'the team_name equals false' do
options = {:team_name =>"false"}
expect(AssignmentTeam.export_fields(options)).to eq(["Team Name", "Team members","Assignment Name"])
end
</pre>

2. when the team_name equals true

<pre>
it 'the team_name equals true' do
options = {:team_name =>"true"}
expect(AssignmentTeam.export_fields(options)).to eq(["Team Name", "Assignment Name"])
end
</pre>

====Testing remove_team_by_id====

<pre>
it 'send find to Assignment' do
expect(AssignmentTeam).to receive(:find).with(1)
AssignmentTeam.remove_team_by_id(1)
end
</pre>

====Testing path====

<pre>
it 'can get the path' do
expect(assignment_team.path).to eq(Rails.root.to_s+'/pg_data/instructor6/csc517/test/final_test/0')
assignment_team.path
end
</pre>

====Testing set_student_directory_num====
3 test cases are designed to test this method

1. when directory_num >= 0

<pre>
context 'directory_num >= 0' do
it 'return when num>=0' do
expect(assignment_team.set_student_directory_num).to eq(nil)
end
end
</pre>

2. when the directory_num does not exist and it gets max num

<pre>
let(:assignment_team1) {build(:assignment_team, directory_num: nil)}
it 'get max num' do
expect(AssignmentTeam).to receive_message_chain(:where,:order,:first,:directory_num).with(parent_id: assignment_team1.parent_id).with('directory_num desc').with(no_args).with(no_args).and_return(1)
assignment_team1.set_student_directory_num
end
</pre>

3. when the directory_num does not exist and it updates attribute

<pre>
it 'update attribute' do
allow(AssignmentTeam).to receive_message_chain(:where,:order,:first,:directory_num).with(parent_id: assignment_team1.parent_id).with('directory_num desc').with(no_args).with(no_args).and_return(1)
expect(assignment_team1).to receive(:update_attributes).with(directory_num: 2)
assignment_team1.set_student_directory_num
end
</pre>

====Testing received_any_peer_review?====

<pre>
it 'send the request to where of the ResponseMap' do
expect(ResponseMap).to receive(:where).with(reviewee_id: assignment_team.id, reviewed_object_id: assignment_team.parent_id).and_return([])
assignment_team.received_any_peer_review?
end</pre>

==Test Coverage==
There is screenshot of the coverage page.
[https://drive.google.com/open?id=12jHYbHoL_MpjnM1tdy52DVjqasGmnHie]