Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T02:08:14Z

Tkundra: /* Problem Statement */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.

2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

We have forked the repository [https://github.com/CarlColglazier/expertiza CarlColglazier/expertiza/gh-integration] currently doing work upon for an independent study project by Carl. We have extended his work and added upon that to show the metrices.
The link for our project PR is [https://github.com/CarlColglazier/expertiza/pull/1 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a horizontal stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T02:07:49Z

Tkundra: /* Problem Statement */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.

2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

We have forked the repository [https://github.com/CarlColglazier/expertiza gh-integration] currently doing work upon for an independent study project by Carl. We have extended his work and added upon that to show the metrices.
The link for our project PR is [https://github.com/CarlColglazier/expertiza/pull/1 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a horizontal stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T02:06:35Z

Tkundra: /* Problem Statement */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

1. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

We have forked the repository [https://github.com/CarlColglazier/expertiza gh-integration] currently doing work upon for an independent study project by Carl. We have extended his work and added upon that to show the metrices.
The link for our project PR is [https://github.com/CarlColglazier/expertiza/pull/1 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a horizontal stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T02:06:08Z

Tkundra: /* Problem Statement */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

We have forked the repository [https://github.com/CarlColglazier/expertiza gh-integration] currently doing work upon for an independent study project by Carl. We have extended his work and added upon that to show the metrices.
The link for our project PR is [https://github.com/CarlColglazier/expertiza/pull/1 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a horizontal stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

File:Githubmetrics1.jpeg

2019-12-07T02:00:50Z

Tkundra: uploaded a new version of "File:Githubmetrics1.jpeg"

File:Githubmetrics3.png

2019-12-07T01:59:43Z

Tkundra: uploaded a new version of "File:Githubmetrics3.png"

File:Githubmetrics2.png

2019-12-07T01:59:25Z

Tkundra: uploaded a new version of "File:Githubmetrics2.png"

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:57:35Z

Tkundra: /* UI */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a horizontal stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:56:35Z

Tkundra: /* UI */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics2.png]]

[[File:githubmetrics3.png]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:55:47Z

Tkundra: /* UI */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:githubmetrics1.jpeg]]

[[File:githubmetrics2.jpeg]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

File:Githubmetrics3.png

2019-12-07T01:55:08Z

Tkundra:

File:Githubmetrics2.png

2019-12-07T01:54:57Z

Tkundra:

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:51:43Z

Tkundra: /* Resolve merge conflicts of the existing PR with expertiza:master */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:Mock.jpg]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:51:06Z

Tkundra: /* Code Climate Issues */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:Mock.jpg]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:50:41Z

Tkundra: /* Rspec Test */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:Mock.jpg]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also, some of the modules can be subdivided into smaller modules.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

<pre>
context "when graph type is number of commits and group by week" do
it 'should return commits group by week' do
git_variable = {}

git_variable[:parsed_data] = {
"tushar.h.dahibhate@gmail.com"=>{
"2018-11-14"=> {
:commits=>1, :additions=>2, :deletions=>2
},
"2018-11-23"=> {
:commits=>0, :additions=>0, :deletions=>0
}
},
"ssbhoyar@gmail.com"=>{
"2018-11-14"=>{
:commits=>0, :additions=>0, :deletions=>0
},
"2018-11-23"=>{
:commits=>1, :additions=>0, :deletions=>3292
}
}
}
git_variable[:authors] = ["tushar.h.dahibhate@gmail.com", "ssbhoyar@gmail.com"]
git_variable[:dates] = ["2018-11-14", "2018-11-23"]
graph_type = '0'
timeline_type = '0'
due_date = "2017-09-08 23:59:00 -0400"

data = helper.get_chart_data(git_variable, graph_type, timeline_type, due_date)

expected_data = {
:labels=>[-10, -11],
:datasets=>[
{"borderWidth"=>1, "data"=>[1, 0], "stack"=>1, "label"=>"tushar.h.dahibhate@gmail.com", "backgroundColor"=>"#ed1c1c"},
{"borderWidth"=>1, "data"=>[0, 1], "stack"=>1, "label"=>"ssbhoyar@gmail.com", "backgroundColor"=>"#ffea00"}
]
}

expect(data).to eq(expected_data)
end
end
</pre>

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-12-07T01:50:06Z

Tkundra: /* Rspec Test */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/saxenaakshay/expertiza/tree/gh-integration here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as a vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner. Assignment policy contains variables for due date and start date which can be used to get the timeline to plot week-wise data, this way we'll have max around 3-4 weeks of bars. 
[[File:Mock.jpg]]

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UmlDiagram.jpg|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:githubmetrics1.jpeg]]

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of the code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also, some of the modules can be subdivided into smaller modules.

====Add horizontal bar charts for user statistics====
A bar graph needs to be added to display data like the number of commits, the number of lines of code added/removed per user basis. The current work consists of cluttered graphs for code frequency for the entire team which makes it difficult to gather user-level activities/submissions in different timelines. We intend to add horizontal bar charts that can be mapped to user-level contributions in different per week.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:

Github Metrics By Week
* Number Of Commits
* Lines Added
* Lines Deleted
Github Metrics By Student
* Number Of Commits
* Lines Added
* Lines Deleted

"get_chart_data" function parses the input github data based on the type of the graph and timeline selected to the required data format required by the chartjs-ror "horizontal_bar_chart" function

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-16T02:56:12Z

Tkundra: /* UI */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
The data is shown as vertical stacked graph grouped by the time range for eg: weekly or daily. The bar will show the no of commits, lines of code in a stacked manner.
[[File:MockGraph.png]]

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:Final2.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-16T02:54:07Z

Tkundra: /* UI */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
[[File:MockGraph.png]]

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:Final2.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-16T02:53:39Z

Tkundra: /* Project Task */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.
===UI===
#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.
*Old Graph Representation
[[File:OldScreen.png]]
*New Graph Representation
[[File:OldScreen.png]]

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:Final2.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

File:OldScreen.png

2019-11-16T02:52:05Z

Tkundra:

File:MockGraph.png

2019-11-16T02:51:42Z

Tkundra:

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-16T02:32:57Z

Tkundra: /* Project Task */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

#The current screen looks cluttered and needs to be changed to display the data in more organised and easy to read way. The github commit data can be shown on weekly basis instead of the current day wise. Showing the data day wise does not add much for the instructor grading. A bar graph needs to be added to display data like no of commits, no of lines of code, etc. per uses basis.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentors===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:Final2.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

==== Resolve merge conflicts of the existing PR with expertiza:master====
The merge conflicts in app/views/grades/_tabbing.html.erb and app/assets/stylesheets/grades.scss have to fixed for auto-merge to work.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T02:05:55Z

Tkundra: /* "Dry" the Redundant Code */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on. We will refactor their code and fix code smells with the help of code climate platform.
Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T02:04:39Z

Tkundra: /* Move JavaScript Code */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

==== Move controller code to helper====
The controller code contains auxiliary functions that make calls to Github for third party resources. These can be moved to a helper class.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:50:15Z

Tkundra: /* Our Improvements */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Feedbacks and Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
We will test all the existing functionality for the page where we are showing GitHub matrices.

New Features which we will test:
*get_statuses_for_pull_request
*retrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:49:41Z

Tkundra: /* Our Improvements */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1858, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:48:49Z

Tkundra: /* Our Improvements */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1983, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:48:10Z

Tkundra: /* References */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:46:51Z

Tkundra: /* Implementation */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:40:47Z

Tkundra: /* "Dry" the Redundant Code */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

==== Code Climate Issues====
'''Problem:''' Currently there are 134 code climate issues to be corrected
For example, the size of functions and the depth exceeds the limit. Also some of the modules can be sub divided into smaller modules.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:34:30Z

Tkundra: /* Design Principles */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE. To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:33:13Z

Tkundra: /* Design Principles */

=='''Introduction'''==

===Problem Statement===
Expertiza provides teammate reviews to gauge how much each team member contributed, but we would like to augment this data with data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. This information should prove useful for differentiating the performance of team members for grading purposes. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api - Representational State Transfer REST web services helps in establishing the interoperability between different applications. RESTful API uses the HTTP requests for performing the actions GET, PUT, POST and DELETE.
To get the data from Github we will use their query api.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we will add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller, moving javascript code and after adding new UI changes.

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:27:16Z

Tkundra: /* Design Principles */

=='''Introduction'''==

===Problem Statement===
'''Expertiza''' provides '''teammate reviews''' to gauge how much each team member contributed, this information could be generated from data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

* Restful Api -

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller and moving javascript codes.

Management -> Assignment -> Github Metrics

You can see the test result in [https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T01:26:08Z

Tkundra: /* Use Case Diagram Details */

=='''Introduction'''==

===Problem Statement===
'''Expertiza''' provides '''teammate reviews''' to gauge how much each team member contributed, this information could be generated from data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*Arshdeep Singh Syal (asyal)
*Akshay Saxena (asaxena5)
*Piyush Tiwari (ptiwari)
*Tushar Kundra (tkundra)

===Mentor===
*Suraj Siddharudh
*Edward Gehringer

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

=='''Design Principles'''==

* MVC – The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively). We intend to follow the same when implementing our end-point for pulling GitHub data.

* Dry Principle – We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

Some code like the format below can be rewritten and shorten by putting } in one line.

Also, there are many useless spaces make the code look less elegant.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existing test, we need to mock roles:

All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new RSpec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our RSpec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller and moving javascript codes.

Management -> Assignment -> Github Metrics

You can see the test result in [https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view

2019-11-12T00:42:52Z

Tkundra: Created page with "=='''Introduction'''== ===Problem Statement=== '''Expertiza''' provides '''teammate reviews''' to gauge how much each team member contributed, this information could be generate..."

=='''Introduction'''==

===Problem Statement===
'''Expertiza''' provides '''teammate reviews''' to gauge how much each team member contributed, this information could be generated from data from external tools like Github (for example, number of commits, number of lines of code modified, number of lines added, number of lines deleted.) from each group’s submitted repo link. Currently, Expertiza provides '''Teammate Reviews''' under '''View Scores''' functionality for each assignment.

:1. '''Teammate Reviews''' functionality in the View Scores page gauges teammate views on how much other team members contributed to the project. We need to augment this data with data from external tools like GitHub in order to validate that feedback. New metrics will be appended under each student data under the same functionality.
:2. '''Github Metrics''' under '''View Submissions''' page should include a bar chart that shows the number of commits by the team throughout the assignment timeline. This will help instructors to get a team overview, and aid grading process.

While this data will not have marks associated directly, it will prove useful to the instructor in differentiating the performance of team members and hence awarding marks as per contribution. Overall data for the team, like the number of committers and number of commits may also help instructors to predict which projects are likely to be merged.

The link for our project PR is [https://github.com/expertiza/expertiza/pull/1455 here]

===Project Task===
Extract Github metadata of the submitted repos and pull requests.
#The metadata should be stored in the local Expertiza DB. For each participant, record should include at least:
#*Committer id
#*Total number of commits
#*Number of files changed
#*Lines of code changed
#*Lines of code added
#*Lines of code removed
#*Lines of code added that survived until final submission [if available from Github]
#The code should sync the data with Github whenever someone (student or instructor) looks at a view that shows Github data.
#The data for teams should be shown in the instructor’s View Scores window, in a new tab, probably between Reviews and Author Feedback.
#*Design a good view for showing data on individuals. Please discuss this with the project mentor(s).
#*It seems to me that this should be on the Teammate Reviews tab, right below the grid for teammate reviews. The reason for this is that we’d like to see all the data on an individual in a single view. For teams, by contrast, there is already a pretty large grid, and potentially multiple grids for multiple rounds, so adding a new grid is more likely to clutter the display.
#Create a bar chart for the # of lines changed for each assignment team on “view_submissions” page. The x-axis should be the time starting from the assignment creation time, till the last deadline of the assignment, or current time, whichever is earlier.

This task has been partially implemented by another group for project''' E1858. Github Metrics Integration''' in 2018 Fall semester. Detailed document about project E1858 on framework design and implementation can be found in [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration here] and the PR for Project E1858 is shown in [https://github.com/expertiza/expertiza/pull/1179 Here]. However, their work has been rejected with the feedback "They have integrated the github metrics into expertiza to show the number of commits, pull requests status, etc against every project. They have also integrated it into the metrics. Looks like they covered the edge cases. The code looks good but needs comments as it is pretty complex. The documentation feels like it is flooded with code, if there was a description of the changes, it would have been better. Extensive tests, but it might be good to see if additions to existing tests really belong in those same tests". The goal of our current project is to resolve issues existing in their previous work, refactor codes they created and modify their code following "DRY" principles. The ultimate goal is to have the '''Github Metric Integration''' work in Expertiza.

===Team===
*swang28 (Shuai Wang)
*zwu17 (Ziwei Wu)
*hlu6 (Hao Lu)
*ychen239( Yuhan Chen)
*zhu6 (Zhewei Hu, mentor)

=='''Plan of Work'''==

===Use Case Diagram===
[[File:UC_1.png|none|frame|1. Use Case diagram of two approaches to append 'GitHub contribution metric' in teammate review. 2. Use Case diagram explaining approach to add new column 'GitHub contribution metric' in 'View submission]]

====Use Case Diagram Details====
'''Actors:'''

*Instructor: This actor is responsible for viewing GitHub metrics of teams and team members of an assignment.

'''Pre-Conditions:'''

*The Team should have submitted the assignment with a PR link or GitHub repository.

'''Primary Sequence:'''

*The instructor should login.

*The instructor should browse teams for an assignment.

'''Post Conditions:'''

*Instructor will be able to see the team contribution done by each team member in 'View Submissions' page using graph diagrams, as shown in the figure.
*Instructor will be able to see the work done by each student in 'Teammate Review Tab' with new metrics table appended at the end, as shown in the figure.

===Github Metrics Features===

Github Metrics Features can be accessed from manage content UI

[[File:Githubflow1.png]]

Then click the 'view submissions'

[[File:Githubflow2.png]]

Then we can see 'Github Metrics button' in each project submission

[[File:Githubflow3.png]]

Below is the bar chart of commit numbers.

[[File:Githubflow4.png]]

We can see the details in the following part.

[[File:Githubflow5.png]]

===Our Improvements===

After understanding the project E1851, We found some issues in this project and give our solutions below.

====Add New Controller====
'''Problem:''' The related codes for Github related functionalities are most implemented under "Grades_Controller". This design obviously violates a good design pattern because Grade_Controller involves too many functions.

'''Solution:''' To improve it, we should create a separate "Github_Metrics_Controller" which is specifically responsible for functions related to Github Metrics. Following the MVC architecture, we will also need to create corresponding '''Models''' and '''Views''' for the new controller.

====Move JavaScript Code====
'''Problem:''' There are some JavaScript codes in inappropriate positions. For example:

'''
<script type="text/javascript">
toggle_tag_prompt = function() {
$('.tag_prompt_container').toggle();
};
$( document ).ready(function() {
$('#tag_prompt_toggler').click(function () {
if ($('#tag_prompt_toggler').text() == "hide tags")
$('#tag_prompt_toggler').text("show tags")
else
$('#tag_prompt_toggler').text("hide tags")
});
});
</script>
'''

'''Solution:''' We need to replace JavaScript codes to 'assets' fold.

===="Dry" the Redundant Code====
'''Problem:''' Lots of codes in their current implementation violate ruby's "DRY" principles, such as redundant codes, meaningless names, long coding block and so on.

'''Solution:''' We will refactor their code and fix code smells with the help of code climate platform.

For example, some code like the format below can be rewritten in the shorter line.

'''
@head_refs = {}
@parsed_data = {}
@authors = {}
@dates = {}
@total_additions = 0
@total_deletions = 0
@total_commits = 0
@total_files_changed = 0
@merge_status = {}
@check_statuses = {}
'''

The solution to the example: create a hash table for all of the instance variables and refactor all the usage of the variables.

'''
@gitVariable = {
:head_refs => {},
:parsed_data => {},
:authors => {},
:dates => {},
:total_additions => 0,
:total_deletions => 0,
:total_commits => 0,
:total_files_changed => 0,
:merge_status => {},
:check_statuses => {}
}
'''
Some code like the format below can be rewritten and shorten by putting } in one line.

'''

def get_github_repository_details(hyperlink_data)
data = {
query: "query {
repository(owner: \"" + hyperlink_data["owner_name"] + "\", name: \"" + hyperlink_data["repository_name"] + "\") {
ref(qualifiedName: \"master\") {
target {
... on Commit {
id
history(first: 100) {
edges {
node {
id author {
name email date
}
}
}
}
}
}
}
}
}"
}
'''

Also, there are many useless spaces make the code look less elegant.

=='''Test Plan'''==

To make sure the refactor code can work correctly, we need to run the original rspec test code and add some new test. Besides, we are plaining to test from UI to make sure all the features work. The test results are shown below.

*Run and pass existing RSpec Tests after refactoring
*Develop New RSpec Tests for the new features
*UI testing on the deployed project

===Rspec Test===
For the existting test, we need to mock roles:
'''
let(:review_response) { build(:response) }
let(:assignment) { build(:assignment, id: 1, questionnaires: [review_questionnaire], is_penalty_calculated: true) }
let(:assignment_questionnaire) { build(:assignment_questionnaire, used_in_round: 1, assignment: assignment) }
let(:participant) { build(:participant, id: 1, assignment: assignment, user_id: 1) }
let(:participant2) { build(:participant, id: 2, assignment: assignment, user_id: 1) }
let(:review_questionnaire) { build(:questionnaire, id: 1, questions: [question]) }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:question) { build(:question) }
let(:team) { build(:assignment_team, id: 1, assignment: assignment, users: [instructor]) }
let(:student) { build(:student) }
let(:review_response_map) { build(:review_response_map, id: 1) }
let(:assignment_due_date) { build(:assignment_due_date) }
'''
All the test can be found in "expertiza/spec/controllers/grades_controller_spec.rb" now, we will refactor it since we need to build new controller.

We test several conditions :
*Views
**when user has logged into to GitHub
**when user hasn\'t logged in to GitHub
**when current assignment does not vary rubric by round
*view_my_scores
**when view_my_scores page is not allow to access
**when view_my_scores page is allow to access
*view_team
*edit
*instructor_review
**when review exists
**when review does not exist
*update
**when total is not equal to participant\'s grade
**when total is equal to participant\'s grade
*save_grade_and_comment_for_submission
*get_statuses_for_pull_request
*etrieve_pull_request_data
*retrieve_repository_data
*retrieve_github_data
**when pull request links have been submitted
**when pull request links have not been submitted
*retrieve_check_run_statuses
*view_github_metrics
**when user has logged in to GitHub
*authorize_github
*get_github_repository_details
*get_pull_request_details
*process_github_authors_and_dates
*parse_github_pull_request_data
*parse_github_repository_data
*make_github_graphql_request
*get_query
*team_statistics
*organize_commit_dates

The new rspec test file is [https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb here]. You can run the following code

'''
rspec spec/controllers/github_metrics_controller_spec.rb
'''

to test the result. Our rspec test coverage is 100. The test video is [https://www.youtube.com/watch?v=1pOVQzHT7jg here]

===UI Test===
For this project, we add an API from the GitHub, all we need to do is to test whether the API can work appropriately after changing codes to another controller and moving javascript codes.

Management -> Assignment -> Github Metrics

You can see the test result in [https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

=='''Implementation'''==

====Add New Controller====
We added and changed the new controller '''github_metrics controller''' and some ralated files.
*[https://github.com/HohoCoco/expertiza/blob/master/app/controllers/github_metrics_controller.rb github_metrics controller.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/app/helpers/github_metrics_helper.rb github_metrics_helper.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/spec/controllers/github_metrics_controller_spec.rb github_metrics_controller_spec.rb]
*[https://github.com/HohoCoco/expertiza/blob/master/config/routes.rb routes.rb]

The GitHub metrics part is separated into the new files.

====Move JavaScript Code====

Previous work includes JavaScript code. After carefully testing and examination, we found these JavaScript code were another version of the implementation of our task. So we remove those redundant codes to make our code clean.

*[https://github.com/HohoCoco/expertiza/commit/02de332e9d1c2fc463ef0120dca70360b6356eda Remove redundant JavaScript codes]

====Refactor Redandent Variables====

We create a hash table to cover all the created instance variables.

*[https://github.com/HohoCoco/expertiza/commit/fab8468a296f0abcb336869283bd6acb282bff61 Refactor instance variables]

====Callback setup for github token====

we set the callback URL as: ./auth/github/callback

[[File:callback.png]]

=='''References'''==

[https://www.youtube.com/watch?v=QMVXceN7XFg Project E1925 Video]

[https://www.youtube.com/watch?v=1pOVQzHT7jg&feature=youtu.be rspec test]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018-_Project_E1858._Github_metrics_integration Project E1858 wiki]

[https://github.com/expertiza/expertiza/pull/1179 Project E1858 PR Link]

[https://developer.github.com/v3/ GitHub API documentation]

CSC/ECE 517 Fall 2019

2019-11-12T00:41:40Z

Tkundra:

* [[CSC/ECE 517 Fall 2019 - Project E1947. Refactor quiz_questionnaire_controller.rb]]
* [[CSC/ECE 517 Fall 2019 - Project E1965. Review report should link to the usual view for reviews]]
* [[CSC/ECE 517 Fall 2019 - Project E1943. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Fall 2019 - E1972. OSS project J. Skellington: Accessing Assignment Rubrics]]
* [[CSC/ECE 517 Fall 2019 - E1961. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2019 - E1971. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2019 - E1953. Tagging report for student]]
* [[CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student_task.rb]]
* [[CSC/ECE 517 Fall 2019 - E1954. Auto-generate submission directory names based on assignment names]]
* [[CSC/ECE 517 Fall 2019 - E1958. Two issues related to assignment management]]
* [[CSC/ECE 517 Fall 2019 - E1948. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2019 - E1959. Intelligent copying of assignments without topics]]
* [[CSC/ECE 517 Fall 2019 - E1968. Fixes for adding members to teams]]
* [[CSC/ECE 517 Fall 2019 - E1969. Fixes for reviews not being available]]
* [[CSC/ECE 517 Fall 2019 - E1951. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2019 - E1957. Time travel Not Allowed..!!! Restrict TAs’ ability to change their own grade + limit file-size upload]]
* [[CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role]]
* [[CSC/ECE 517 Fall 2019 - E1941. Issues related to topic deadlines]]
* [[CSC/ECE 517 Fall 2019 - E1966. Tabbed_reviews partial file refactor for displaying the alternate view of reviews]]
* [[CSC/ECE 517 Fall 2019 - E1962. Email notification upon account creation]]
* [[CSC/ECE 517 Fall 2019 - E1967. Fix glitches in author feedback]]
* [[CSC/ECE 517 Fall 2019 - E1960. Create new late policy successfully and fixing "Back" link]]
* [[CSC/ECE 517 Fall 2019 - E1939. OSS Project Juniper: Bookmark enhancements]]
* [[CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation]]
* [[CSC/ECE 517 Fall 2019 - E1938. OSS project Duke Blue: Fix import glitches]]
* [[CSC/ECE 517 Fall 2019 - E1985. Let course staff and students do reviews]]
* [[CSC/ECE 517 Fall 2019 - M1951. Implement missing OffscreenCanvas APIs]]
* [[CSC/ECE 517 Fall 2019 - E1940. Improving email notification]]
* [[CSC/ECE 517 Fall 2019 - E1956. There is no shortcut to get free review points: Review Assignment Bug]]
* [[CSC/ECE 517 Fall 2019 - E1942. Refactor stage deadlines in assignment.rb]]
* [[CSC/ECE 517 Fall 2019 - M1952. Missing DOM features project]]
* [[CSC/ECE 517 Fall 2019 - E1945. Refactor users_controller.rb]]
* [[CSC/ECE 517 Fall 2019 - E1964. Export review scores for projects]]
* [[CSC/ECE 517 Fall 2019 - E1949. Write Unit Tests for Importing assignment participants and import glitches]]
* [[CSC/ECE 517 Fall 2019 - E1944. Refactor review mapping controller]]
* [[CSC/ECE 517 Fall 2019 - E1946. Refactor Questionnaire controller]]
* [[CSC/ECE 517 Fall 2019 - E1982. Regulate changing of rubrics while projects are in progress]]
* [[CSC/ECE 517 Fall 2019 - E1989. Track the time students look at other submissions]]
* [[CSC/ECE 517 Fall 2019 - E1990. Integrate suggestion detection algorithm]]
* [[CSC/ECE 517 Fall 2019 - E1995. Tests for email functionality]]
* [[CSC/ECE 517 Fall 2019 - E1993 Track Time Between Successive Tag Assignments]]
* [[CSC/ECE 517 Fall 2019 - E1979. Completion/Progress view]]
* [[CSC/ECE 517 Fall 2019 - E1980. Sort instructor reports by name, ID, score, etc.]]
* [[CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view]]
* [[CSC/ECE 517 Fall 2019 - E1984. Improve self-review Link peer review & self-review to derive grades]]
* [[CSC/ECE 517 Fall 2019 - E1994. Mentor management for assignments without topics]]
* [[CSC/ECE 517 Fall 2019 - E1997. Issues related to meta-reviewing]]
* [[CSC/ECE 517 Fall 2019 - E1981. Student-generated questions added to rubric]]
* [[CSC/ECE 517 Fall 2019 - E1996. Enhancements to review grader]]
* [[CSC/ECE 517 Fall 2019 - E1987. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies]]
* [[CSC/ECE 517 Fall 2019 - E1991. Improvements to anonymized view]]
* [[CSC/ECE 517 Fall 2019 - E1998. Weights in grade calculation]]
* [[CSC/ECE 517 Fall 2019 - E1986. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2019 -E1974 Allow users to create an account and submit work to an ”assignment” Design]]
* [[CSC/ECE 517 Fall 2019 -E1988 Allow reviewer to say review can be shown to class as an example]]
* [[CSC/ECE 517 Fall 2019 - E1975. Generalize Review Versioning]]
* [[CSC/ECE 517 Fall 2019 - E1976. Issues Related to Assignment Creation]]
* [[CSC/ECE 517 Fall 2019 - E1991. Improvements to anonymized view]]

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T01:21:21Z

Tkundra: /* DB Schema */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== DB Schema ==
Below are the tables that are related ti student task functionality
[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg DB Schema]

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]

[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

The following functions were tested:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
This function return the StudentTask from the participant with assignment, topic, current_stage
* from_participant_id(id)
This function return the StudentTask from the participant with assignment, topic, current_stage using the participant id
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
This function return the list of all the students that the logged on user has teamed up until now.
* started?
Checks if the current stage is "incomplete" and content_submitted_in_current_stage? reviews_given_in_current_stage? || metareviews_given_in_current_stage? and return true and false
* topic_name
Return the name of the topic

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.
This method is an instance method, having a user passed to it. It return the list of students that the current user has teamed up. It does not consider the teammates that are from calibration assignments
The test cases described check for the following scenarios:
1. When not in any team returns empty
2. When assigned in a cource_team returns empty
3. When assigned in a assignment_team return the list of teammates

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:54:16Z

Tkundra: /* Description of the current project */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== DB Schema ==

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg Full DB Schema]

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]

[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

The following functions were tested:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
This function return the StudentTask from the participant with assignment, topic, current_stage
* from_participant_id(id)
This function return the StudentTask from the participant with assignment, topic, current_stage using the participant id
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
This function return the list of all the students that the logged on user has teamed up until now.
* started?
Checks if the current stage is "incomplete" and content_submitted_in_current_stage? reviews_given_in_current_stage? || metareviews_given_in_current_stage? and return true and false
* topic_name
Return the name of the topic

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.
This method is an instance method, having a user passed to it. It return the list of students that the current user has teamed up. It does not consider the teammates that are from calibration assignments
The test cases described check for the following scenarios:
1. When not in any team returns empty
2. When assigned in a cource_team returns empty
3. When assigned in a assignment_team return the list of teammates

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:53:34Z

Tkundra: /* Description of the current project */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]

[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg Full DB Schema]

The following functions were tested:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
This function return the StudentTask from the participant with assignment, topic, current_stage
* from_participant_id(id)
This function return the StudentTask from the participant with assignment, topic, current_stage using the participant id
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
This function return the list of all the students that the logged on user has teamed up until now.
* started?
Checks if the current stage is "incomplete" and content_submitted_in_current_stage? reviews_given_in_current_stage? || metareviews_given_in_current_stage? and return true and false
* topic_name
Return the name of the topic

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.
This method is an instance method, having a user passed to it. It return the list of students that the current user has teamed up. It does not consider the teammates that are from calibration assignments
The test cases described check for the following scenarios:
1. When not in any team returns empty
2. When assigned in a cource_team returns empty
3. When assigned in a assignment_team return the list of teammates

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:47:18Z

Tkundra: /* Test Plan */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]

[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg Full DB Schema]

tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
This function return the StudentTask from the participant with assignment, topic, current_stage
* from_participant_id(id)
This function return the StudentTask from the participant with assignment, topic, current_stage using the participant id
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
This function return the list of all the students that the logged on user has teamed up until now.
* started?
Checks if the current stage is "incomplete" and content_submitted_in_current_stage? reviews_given_in_current_stage? || metareviews_given_in_current_stage? and return true and false
* topic_name
Return the name of the topic

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.
This method is an instance method, having a user passed to it. It return the list of students that the current user has teamed up. It does not consider the teammates that are from calibration assignments
The test cases described check for the following scenarios:
1. When not in any team returns empty
2. When assigned in a cource_team returns empty
3. When assigned in a assignment_team return the list of teammates

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:42:32Z

Tkundra: /* Description of the current project */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]

[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg Full DB Schema]

tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
This function return the StudentTask from the participant with assignment, topic, current_stage
* from_participant_id(id)
This function return the StudentTask from the participant with assignment, topic, current_stage using the participant id
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
This function return the list of all the students that the logged on user has teamed up until now.
* started?
Checks if the current stage is "incomplete" and content_submitted_in_current_stage? reviews_given_in_current_stage? || metareviews_given_in_current_stage? and return true and false
* topic_name
Return the name of the topic

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

File:ExpertizaDbSchema.jpg

2019-11-07T00:33:04Z

Tkundra: uploaded a new version of "File:ExpertizaDbSchema.jpg"

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:27:26Z

Tkundra: /* Test Plan */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]
[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg DB Schema]

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>
Below are some of the functions tested
* Function: teamed_students - Write a test case to find teamed up students.

<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

* Function: get_due_date_data - Write a test case to get the due dates of the assignment.
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

* Function: get_peer_review_data - Write a test case to get the peer review data.===
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_author_feedback_data - Write a test case to get the feedback response
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

* Function: get_submission_data - Write a test case to import participants
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:20:23Z

Tkundra: /* Description of the current project */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]
[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

[http://wiki.expertiza.ncsu.edu/images/7/7a/ExpertizaDbSchema.jpg DB Schema]

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>

===Task 1. Write a test case to . ===
* teamed_students
<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

Lorem Ipsum

===Task 2. Write a test case to .===
* get_due_date_data
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

Lorem Ipsum

===Task 3. Write a test case to .===
* get_peer_review_data
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 4. Write a test case to .===
* get_author_feedback_data
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 5. Write a test case to import participants.===
* get_submission_data
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

Lorem Ipsum

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

File:ExpertizaDbSchema.jpg

2019-11-07T00:19:14Z

Tkundra:

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:06:05Z

Tkundra: /* Description of the current project */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.
The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.
* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.
* Cover edge cases.
* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]
[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>

===Task 1. Write a test case to . ===
* teamed_students
<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

Lorem Ipsum

===Task 2. Write a test case to .===
* get_due_date_data
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

Lorem Ipsum

===Task 3. Write a test case to .===
* get_peer_review_data
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 4. Write a test case to .===
* get_author_feedback_data
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 5. Write a test case to import participants.===
* get_submission_data
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

Lorem Ipsum

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:05:27Z

Tkundra: /* Problem Statement */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>

===Task 1. Write a test case to . ===
* teamed_students
<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

Lorem Ipsum

===Task 2. Write a test case to .===
* get_due_date_data
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

Lorem Ipsum

===Task 3. Write a test case to .===
* get_peer_review_data
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 4. Write a test case to .===
* get_author_feedback_data
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 5. Write a test case to import participants.===
* get_submission_data
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

Lorem Ipsum

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-07T00:04:43Z

Tkundra: /* Test Plan */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
The following mock objects were created/built before the commencement of automated testing for student_task.rb (model) code.
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>

===Task 1. Write a test case to . ===
* teamed_students
<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

Lorem Ipsum

===Task 2. Write a test case to .===
* get_due_date_data
This method is an instance method, having an assignment and timeline_list list passed to it. The test cases described check for the following scenarios:
1. When an assignment passed to the method has no assignment attributes.
2. When an assignment passed to the method has some attributes but not the attribute due_at
3. When an assignment passed to the method has some attributes along with due_at

due_at attribute is checked, upon which the timeline_list is populated with the updated_at and label values.
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

Lorem Ipsum

===Task 3. Write a test case to .===
* get_peer_review_data
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 4. Write a test case to .===
* get_author_feedback_data
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 5. Write a test case to import participants.===
* get_submission_data
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

Lorem Ipsum

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Problem Statement==

The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.

* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.

* Cover edge cases.

* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]
[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-06T21:23:32Z

Tkundra: /* Test Plan */

This page provides a description of the Expertiza based OSS project.

== About Expertiza ==

[https://expertiza.ncsu.edu/ Expertiza] is an open source project based on [https://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

This project in particular intends that the students collaborate with each other and work on making enhancements to the code base by applying the concepts of Rails,RSpec, DRY code,Test driven development etc. This provides an opportunity for students to contribute to an open source project and learn further about software deployment etc.

== About RSpec ==

RSpec is a unit test framework for the Ruby programming language. RSpec is different than traditional xUnit frameworks like JUnit because RSpec is a Behavior driven development tool. What this means is that, tests written in RSpec focus on the "behavior" of an application being tested. RSpec does not put emphasis on, how the application works but instead on how it behaves, in other words, what the application actually does.Each RSpec file contains one or more tests. Each test ensures if a particular feature of our website is working properly.The output of an RSpec run will tell you exactly what features aren't working. The benefit is that tested code is unlikely to break unnoticed.The tests are run every time someone makes, or updates, a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests Pull Request].

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the student_task.rb and student_task_spec.rb. It focuses on writing RSpec unit tests for the code affected or added. The goal of this project is to attempt to add sufficient unit tests to this part of the application and increase its path coverage to above 90 percent.

There are few tests for student_task.rb. We had to test the following functions:

* complete?
This function returns true if the participant stage deadline is "complete" or else return false.
* content_submitted_in_current_stage?
This function returns true if the participant has submitted hyperlinks in the current stage and the stage is in "submission"
* hyperlinks
This function returns all the hyperlinks submitted by the participant team
* in_work_stage?
A assignment is said to be in work stage if its stage is any of "submission", "review" or "metareview"
* incomplete?
This function returns true if the participant stage deadline is not "complete" or else return false.
* metareviews_given? * reviews_given?
A participant can review other people's work and add comments.
Also a user can review a review, called "metareview" that is given to him.
A review comment is mapped to assignments or other reviews by the table response_tags via the reviewed_object_id.
This method checks if the participant has given any metareview and return true otherwise.
* metareviews_given_in_current_stage?
This function checks if the assignment is in "metareview" stage and metareviews.
* not_started?
This function checks if the assignment is in any of "submission", "review" or "metareview" stage
* relative_deadline
* reviews_given_in_current_stage?
* revision?
* from_participant(participant)
* from_participant_id(id)
* from_user(user)
* get_author_feedback_data(participant_id, timeline_list)
* get_due_date_data(assignment, timeline_list)
* get_peer_review_data(participant_id, timeline_list)
* get_submission_data(assignment_id, team_id, timeline_list)
* get_timeline_data(assignment, participant, team)
* teamed_students(user, ip_address = nil)
* started?
* topic_name

== Test Plan ==

* Mock Objects
<pre>
let(:participant) { build(:participant, id: 1, user_id: user.id, parent_id: assignment.id) }
let(:participant2) { build(:participant, id: 2, user_id: user2.id, parent_id: assignment.id) }
let(:participant3) { build(:participant, id: 3, user_id: user3.id, parent_id: assignment2.id) }
let(:user) { create(:student) }
let(:user2) { create(:student, name: "qwertyui", id: 5) }
let(:user3) { create(:student, name: "qwertyui1234", id: 6) }
let(:course) { build(:course) }
let(:assignment) { build(:assignment, name: 'assignment 1') }
let(:assignment2) { create(:assignment, name: 'assignment 2', is_calibrated: true) }
let(:team) { create(:assignment_team, id: 1, name: 'team 1', parent_id: assignment.id, users: [user, user2]) }
let(:team2) { create(:assignment_team, id: 2, name: 'team 2', parent_id: assignment2.id, users: [user3]) }
let(:team_user) { create(:team_user, id: 3, team_id: team.id, user_id: user.id) }
let(:team_user2) { create(:team_user, id: 4, team_id: team.id, user_id: user2.id) }
let(:team2_user3) { create(:team_user, id: 5, team_id: team2.id, user_id: user3.id) }
let(:course_team) { create(:course_team, id: 3, name: 'course team 1', parent_id: course.id) }
let(:cource_team_user) { create(:team_user, id: 6, team_id: course_team.id, user_id: user.id) }
let(:cource_team_user2) { create(:team_user, id: 7, team_id: course_team.id, user_id: user2.id) }
let(:topic) { build(:topic) }
let(:topic2) { create(:topic, topic_name: "TestReview") }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
let(:deadline_type) { build(:deadline_type, id: 1) }
let(:review_response_map) { build(:review_response_map, assignment: assignment, reviewer: participant, reviewee: team2) }
let(:metareview_response_map) { build(:meta_review_response_map, reviewed_object_id: 1) }
let(:response) { build(:response, id: 1, map_id: 1, response_map: review_response_map) }
let(:response2) { build(:response, id: 2, map_id: 1, response_map: review_response_map) }
let(:submission_record) {build(:submission_record, id:1, team_id: 1, assignment_id: 1) } #added for submission_record method call test.
let(:student_task) do
StudentTask.new(
participant: participant,
assignment: participant.assignment,
topic: participant.topic,
current_stage: participant.current_stage,
stage_deadline: (Time.parse(participant.stage_deadline) rescue Time.now + 1.year)
)
end
</pre>

===Task 1. Write a test case to . ===
* teamed_students
<pre>
describe "#teamed_students" do
context 'when not in any team' do
it 'returns empty' do
expect(StudentTask.teamed_students(user3)).to eq({})
end
end
context 'when assigned in a cource_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(StudentTask.teamed_students(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
# allow(Team).to receive(:find).with(team.id).and_return(team)
expect(StudentTask.teamed_students(user)).to eq({assignment.course_id => [user2.fullname]})
end
end
end
</pre>

Lorem Ipsum

===Task 2. Write a test case to .===
* get_due_date_data
<pre>
describe "#get_due_date_data" do
context 'when called with assignment having empty due dates' do
it "return empty time_list array" do
timeline_list = []
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it "return empty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at=nil;
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it "return iiiempty time_list array" do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
StudentTask.get_due_date_data(assignment, timeline_list)
expect(timeline_list).to eq([{
:label=>(due_date.deadline_type.name + ' Deadline').humanize,
:updated_at=>due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end
</pre>

Lorem Ipsum

===Task 3. Write a test case to .===
* get_peer_review_data
<pre>
describe "#get_peer_review_data" do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_peer_review_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list=[]
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_peer_review_data(1,timeline_list)).to eq([{:id=>1, :label=>"Round 1 peer review", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 4. Write a test case to .===
* get_author_feedback_data
<pre>
describe "#get_author_feedback_data" do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list=[]
StudentTask.get_author_feedback_data(user2,timeline_list)
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list=[]
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_author_feedback_data(1,timeline_list)).to eq([{:id=>1, :label=>"Author feedback", :updated_at=>timevalue}])
end
end
end
</pre>

Lorem Ipsum

===Task 5. Write a test case to import participants.===
* get_submission_data
<pre>
describe '#get_submission_data' do
context 'when no submission data mapped' do
it 'returns nil' do
timeline_list=[]
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq(nil)
end
end
context 'when submission data mapped and not submit hyperlink or Remove hyperlink' do
it 'returns timeline_list' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('testing_label')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Testing label", :updated_at=>timevalue}])
end
end
context 'when submission data mapped and operation is submit_hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Submit Hyperlink')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Submit hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
context 'when submission data mapped and operation is Remove Hyperlink' do
it 'returns timeline_list with link' do
timeline_list=[]
allow(SubmissionRecord).to receive_message_chain(:where, :find_each).with(team_id: 1, assignment_id: 1).with(no_args).and_yield(submission_record)
allow(submission_record).to receive(:operation).and_return('Remove Hyperlink')
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
allow(submission_record).to receive(:updated_at).and_return(Time.new(2019))
expect(StudentTask.get_submission_data(1,1,timeline_list)).to eq([{:label=>"Remove hyperlink", :updated_at=>timevalue, :link=>"www.wolfware.edu"}])
end
end
end
</pre>

Lorem Ipsum

=== Team ===

Carmen Bentley,Mentor

* Tushar Kundra,tkundra

* Ram Chavali,ramlohith

* Ayushi Rungta,Rungta1001

=== Running Tests ===

What we need to do is to set up the environment and complete the 'student_task.rb' and 'student_task_spec.rb' to increase the path coverage from only 43.0% with 43 lines covered and 57 lines missed to above 90%.

You can run RSpec tests by executing the command:

<pre>

rspec spec/models/student_task_spec.rb

</pre>

After that, you can see the detailed coverage information by opening this file in your Expertiza folder.

<pre>

coverage/index.html

</pre>

====Our work====
The code we created can be found below. We have also linked the video of our tests running with coverage to showcase the work we have done.
*[https://github.com/expertiza/expertiza/pull/1549 Pull request]
*[https://drive.google.com/file/d/1O-1k3mqo1yRMp0yxgTIuM3P5cegB5DCy/view?usp=sharing Video of tests running]

Test Coverage: [http://wiki.expertiza.ncsu.edu/images/b/b0/E1955before.png Initial] [http://wiki.expertiza.ncsu.edu/images/0/05/E1955after.png Final]

== Problem Statement==

The following tasks were accomplished in this project:

* Complete the insufficient unit tests for student_task.rb.

* Increase path coverage from only 31.91% with 30 lines covered to above 92.55% with 87 lines covered.

* Cover edge cases.

* High branch coverage to be achieved.

There are different tasks that a student can perform.
* He can see all the assignments that he has been assigned to.
* He can see details of each assignment like marks, his team, send invitation to student to join a team
* Review other students' work

[http://wiki.expertiza.ncsu.edu/images/4/4c/StudentTaskHomePage.png Student Task Home Page]
[http://wiki.expertiza.ncsu.edu/images/4/4d/StudentTaskAssignmentTasks.png Assignment Submission Tasks]

== Running the Project Locally ==
The project could be run locally by cloning the Github repository [https://github.com/tusharkundra/expertiza Expertiza] and then running the following commands sequentially.

<pre>

bundle install
rake db:create:all
rake db:migrate
rails s

</pre>

== Issues/Erros During Testing ==
* While creating the test for "reviews_given?", given below, it seems the function is returning string value instead of boolean value as "j.class.to_s[/Review/]" gives a string when the class of "j" starts with "Review"

<pre>
def reviews_given?
response_maps.inject(nil) {|i, j| i || (j.response && j.class.to_s[/Review/]) }
end
</pre>

CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student task.rb

2019-11-06T21:14:23Z

Tkundra: /* Test Plan */