Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-11T19:09:52Z

Sbasnet2: /* Proposed changes */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

File(s) involved in making API Call: response_controller.rb
FIle(s) involved in displaying the received output: response.html.erb

===Proposed changes===
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default view from displaying analysis for each review to summarized analysis for all reviews
** Do not include comment text in analysis view
** Focus on sentiment_score, sentiment_tone, and suggestions metrics returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* evaluate how much time this API is taking and if possible work a way out to improve it.

=== Anticipated View ===

[[File:y.png]]

The user will be given a summary of the feedback in a colorful format. The user will not see all the fields of the JSON and only the necessary text fields, whereas currently the user sees all the fields in the output from the API call. We expect to make the detailed view optional so that it can be used for debug purposes, and not be seen in the production server.

===Files that will change===
* '''app/views/response/response.html.erb''': Fix grammar issues, generate view with metrics
* '''app/controllers/response_controller.rb''': Call API here to pass to view

==Testing plan==
* Use RSpec testing on response_controller.rb to test the method(s) we implement
* Use manual testing on response.html.erb to test view we create

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]

File:Y.png

2019-04-11T19:06:25Z

Sbasnet2:

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-11T18:53:16Z

Sbasnet2: /* Previous work */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

More information about the suggestion detection service can be found at https://www.peerlogic.org

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

File(s) involved in making API Call: response_controller.rb
FIle(s) involved in displaying the received output: response.html.erb

===Proposed changes===
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default view from displaying analysis for each review to summarized analysis for all reviews
** Do not include comment text in analysis view
** Focus on sentiment_score, sentiment_tone, and suggestions metrics returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* evaluate how much time this API is taking and if possible work a way out to improve it.

===Files that will change===
* '''app/views/response/response.html.erb''': Fix grammar issues, generate view with metrics
* '''app/controllers/response_controller.rb''': Call API here to pass to view

==Testing plan==
* Use RSpec testing on response_controller.rb to test the method(s) we implement
* Use manual testing on response.html.erb to test view we create

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-11T18:52:16Z

Sbasnet2: /* Previous work */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

[[File:Prev.png]]

=== Flowchart to Describe Plan of Action ===

[[FIle:x.png]]

File(s) involved in making API Call: response_controller.rb
FIle(s) involved in displaying the received output: response.html.erb

===Proposed changes===
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default view from displaying analysis for each review to summarized analysis for all reviews
** Do not include comment text in analysis view
** Focus on sentiment_score, sentiment_tone, and suggestions metrics returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* evaluate how much time this API is taking and if possible work a way out to improve it.

===Files that will change===
* '''app/views/response/response.html.erb''': Fix grammar issues, generate view with metrics
* '''app/controllers/response_controller.rb''': Call API here to pass to view

==Testing plan==
* Use RSpec testing on response_controller.rb to test the method(s) we implement
* Use manual testing on response.html.erb to test view we create

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]

File:X.png

2019-04-11T18:49:30Z

Sbasnet2:

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-11T18:45:12Z

Sbasnet2: /* Problem statement */

==Introduction==
=== Team ===
Dr. Gehringer (mentor)
* Sushan Basnet (sbasnet2)
* Jasmine Wang (jfwang2)
* Bill Mwaniki (bnmwanik)
* Pratik Kumar Kundanmal Jain (pjain22)

==Project plan==
===Problem statement===
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, we hope students learn from the reviews they receive to improve their own performance. In order to make this happen, we would like to have everyone give quality reviews instead of generic ones. Currently we have a few classifiers that can detect useful features of review comments, such as how many suggestions they contain. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms will be so coded in the future.

===How it will work===

In order to make the API call, the response_controller.rb will be responsible for sending a JSON input to the web service. The input will contain the review comment submitted by the user in the following format:

Below is a sample input
Sample Input:
{
"reviews":[{
"text":"review text here",
"metrics":["problem","suggestion","sentiment"]
},{
"text":"another review here",
"metrics":["problem"]
},{
"text":"more text, maybe a large para or whatever you like",
"metrics":["sentiment", "suggestion"]
},{
...
}]
}

Once the request is send, we expect the output to be in the following format:

Sample Output: (as 'suggestion' and 'volume' as you might expect)
{
"metrics":[{
"suggestion":{
"suggestions_chances":30,
"suggestions":"absent"
},
"volume":{
"total_volume":10,
"volume_without_stopwords":3
}
},{
...
},{
...
}]
}

The output (which is a JSON) will be parsed and the suggestion metrics such as the tone and presence of suggestion will be extracted so the user will be able to view a summarized result of how well their review comments were. In addition, an average score will be computed based on the scores they received for each comment section, and the result will be presented in a colorful format to the user after they hit the submit button.

===Previous work===
[https://github.com/expertiza/expertiza/pull/1308 Fall 2018 pull request]
* They had a functional suggestion detection API call that successfully communicated with the PeerLogic Server and retrieved the output.
* They included their API call in response.html.erb using JavaScript.
* They were able to display the output for each review beside the review. They displayed all of the information returned from the endpoint, which can look clunky.
* Since the code is added in the views, they performed manual testing in the views.

[[File:Prev.png]]

===Proposed changes===
* Move API calls of suggestion-detection algorithm from view to response_controller.rb
* Change default view from displaying analysis for each review to summarized analysis for all reviews
** Do not include comment text in analysis view
** Focus on sentiment_score, sentiment_tone, and suggestions metrics returned from API
* Include displaying analysis for each review as a "debug" option
* Ensure that CORS does not need to be enabled for API call to work
* Write unit tests for our method(s) in response_controller.rb
* Fix grammar issues in response.html.erb
* evaluate how much time this API is taking and if possible work a way out to improve it.

===Files that will change===
* '''app/views/response/response.html.erb''': Fix grammar issues, generate view with metrics
* '''app/controllers/response_controller.rb''': Call API here to pass to view

==Testing plan==
* Use RSpec testing on response_controller.rb to test the method(s) we implement
* Use manual testing on response.html.erb to test view we create

==Links to our work==
* [https://github.com/pratikkumar-jain/expertiza/tree/beta Our repository]
* [https://github.com/expertiza/expertiza/pull/1427 Pull request]

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-07T17:03:37Z

Sbasnet2: /* Proposed changes */

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-07T16:54:55Z

Sbasnet2: /* Proposed changes */

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-07T16:52:48Z

Sbasnet2:

CSC/ECE 517 Spring 2019 - Project E1937. Integrate suggestion detection algorithm.rb

2019-04-07T16:52:24Z

Sbasnet2:

File:Prev.png

2019-04-07T16:50:32Z

Sbasnet2:

File:Testrun.png

2019-03-25T17:54:00Z

Sbasnet2:

CSC/ECE 517 Spring 2019 - Project E1906. Refactor stage deadlines in Assignment.rb

2019-03-25T17:52:45Z

Sbasnet2:

This wiki page is for the description of changes made under E1906 OSS assignment for Spring 2019, CSC/ECE 517.

=='''Expertiza Background'''==
[http://expertiza.ncsu.edu/ Expertiza] is a web application developed using Ruby on Rails Framework whose creation and maintenance is taken care of by students as well as the faculty of NCSU.It's code is available on Github [https://github.com/expertiza/expertiza Expertiza on GitHub].Expertiza allows the instructor to create and edit new as well as existing assignments.This also includes creating a wide range of topics under each assignment which students can sign up for.They can also publish surveys and reviews,view statistical results, set deadlines for assignments and make announcements.It provides a platform for students to signup for topics,form teams,view and submit assignments and give peer reviews and feedback.

=='''Stage Deadline Background'''==
An assignment in Expertiza has many deadlines possible: deadlines for submission and review in each round,deadlines for signing up and dropping topics,submitting meta-reviews,etc.Depending on what the next deadline is,an Expertiza assignment is said to be in a particular kind of what is called "stage".For example,if the next deadline(after the current time) is a submission deadline which is a DueDate object,then the assignment is said to be in a "submission" phase.

[[File: StageBackground.png|center]]

Depending on which stage an assignment is in, certain activities may be permissible or impermissible.For example, the default for a submission stage is to allow submission but not review,and in a review stage,the default is to allow review but not submission.These defaults may be changed by checking the relevant boxes on the Due Dates tab of assignment creation or editing.In the figure below it can be seen the "Other's work" link is grayed out as review is not permissible during submission phase.

[[File: Statusinadeadline.jpg|center]]

=='''Important Links'''==

[http://oss.flazzle.com/ Deployed_Project_Link]

[https://github.com/jwboykin/expertiza Expertiza_Link_for_this_Project]

=='''Problem Statement'''==
E1906 is an Expertiza based OSS project which deals basically with refactoring stage deadlines in assignment.rb file.Class assignment.rb has several methods for checking what kind of stage an assignment is in at the current time.These are:

* current_stage_name(topic_id = nil)
* find_current_stage(topic_id = nil)
* get_current_stage(topic_id = nil)
* link_for_current_stage(topic_id = nil)
* stage_deadline(topic_id = nil)

The goal of the project focuses on refactoring some of the above more complex methods, modifying some of the language to make it more Ruby friendly, removing some redundant code. This project is basically an attempt to make this part of the application easier to read and maintain.

=='''Solutions Implemented'''==

==='''Problem 1'''===

The above methods were being used at various places to check if the assignment is 'Finished' which made the code very redundant. Assignment is said to be finished if the next_due_date is nil.

===='''Solution'''====

We have created a new method "finished?" that checks if the next_due_date is nil (which means that the assignment is "finished").

<pre>
# New function to check if the assignment is finished
def finished?( topic_id = nil )
DueDate.get_next_due_date(self.id, topic_id).nil?
end
</pre>

We have called this method at all the places where previously different methods were being used to check the same thing.
*Signup sheet table uses assignment finished? method instead of current_stage_name
[[File:Problem1_1.png‎|center]]

*Use assignment finished? method where only a comparison to "Finished" was being done using get_current_stage and find_current_stage
[[File:Problem1_2.png|center]] [[File:Problem1_3.png|center]]

==='''Problem 2'''===

The check for a topic_id to be nil when it is a staggered assignment and return 'Unknown' when it is true was being done at many places.This was not following Ruby and Rails rules.

===='''Solution'''====

To make the code DRY and more easy to understand,we have created a new private method "topic_missing?" to check if the topic_id is nil in case of staggered assignment.

<pre>
# Function to check if topic id is null when its a staggered assignment
def topic_missing?( topic_id = nil)
topic_id.nil? and self.staggered_deadline?
end
</pre>

*Refactoring with new method topic_missing?

[[File:Topic missing.png|center]]

==='''Problem 3'''===

find_current_stage(topic_id=nil) method is being used only locally in the assignment.rb and once in the student_teams controller to check to check whether to display or not the reviews option for team members.This method was calling another function to get the next_due_date for an assignment that was creating a chain of calls.

===='''Solution'''====

We have removed this function.We have replaced it with finished? method in the student_teams controller(shown in screenshot above in Problem 1) and with DueDate.get_next_due_date where the next due date was required.

<pre>
Before :
due_date = find_current_stage(topic_id)

After :
due_date = DueDate.get_next_due_date(self.id, topic_id)
</pre>

==='''Problem 4'''===

get_current_stage method is returning the stage name which the assignment is in at current time.This is not very clear from the name of the method.

===='''Solution'''====

We have changed the method name to get_current_stage_name(topic_id=nil) to make it more clear to understand.

<pre>
def get_current_stage_name(topic_id = nil)
return 'Unknown' if topic_missing?(topic_id)
due_date = DueDate.get_next_due_date(self.id, topic_id)
finished?(topic_id)? "Finished" : DeadlineType.find(due_date.deadline_type_id).name
end
</pre>

*Refactored get_current_stage with get_current_stage_name

[[File:Get current stage name.png|center]]

==='''Problem 5'''===

current_stage_name(topic_id=nil) method was implementing things which was already being done by other methods and thus this method was redundant.
The initial code given was:

<pre>
def current_stage_name(topic_id = nil)
if self.staggered_deadline?
return (topic_id.nil? ? 'Unknown' : get_current_stage(topic_id))
end
due_date = find_current_stage(topic_id)

unless self.staggered_deadline?
if due_date != 'Finished' && !due_date.nil? && !due_date.deadline_name.nil?
return due_date.deadline_name
else
return get_current_stage(topic_id)
end
end
end
</pre>

First thing we noticed was that due_date.deadline_name was always nil because there was no field to enter the deadline name on the form, and therefore, the statement <pre> return due_date.deadline_name </pre> was never getting executed.

===='''Solution'''====

This method was checking for the due_date.deadline_name which was always nil. After removing the dead code, we get:

<pre>
def current_stage_name(topic_id = nil)
if topic_missing?(topic_id)
return 'Unknown'
else
get_current_stage(topic_id)
end
end
</pre>

Looking at the get_current_stage_name(topic_id=nil) method shown below and comparing it to what we have above, this code was surely redundant.That is why we removed this code and made appropriate changes wherever required within assignment.rb.
*Below is the get_current_stage_name method for reference

<pre>
def get_current_stage_name(topic_id = nil)
return 'Unknown' if topic_missing?(topic_id)
due_date = DueDate.get_next_due_date(self.id, topic_id)
finished?(topic_id)? "Finished" : DeadlineType.find(due_date.deadline_type_id).name
end
</pre>

After removing the current_stage_name method, its uses were replaced with get_current_stage_name. One example of the refactoring is shown below:

[[File:Current_stage.png|center]]

The associated rspec tests that tested the current_stage method were also no longer needed.

==='''Problem 6'''===

===='''Solution'''====

=='''Automated Testing using RSPEC'''==

===='''Tests for get_current_stage_name'''====

The current version of expertiza did not have any tests for get_current_stage(topic_id=nil) method.Now as we have changed it to get_current_stage_name(topic_id=nil),we have added its tests as well.

<pre>
describe '#get_current_stage_name' do
context 'when topic id is nil and current assignment has staggered deadline' do
it 'returns Unknown' do
allow(assignment).to receive(:topic_missing?).and_return(true)
expect(assignment.get_current_stage_name).to eq('Unknown')
end
end

context 'when current assignment does not have staggered deadline' do
context 'when due date is nil' do
it 'returns Finished' do
allow(assignment).to receive(:finished?).with(123).and_return(true)
expect(assignment.get_current_stage_name(123)).to eq('Finished')
end
end

context 'when due date is not nil and due date is not equal to Finished' do
it 'returns current stage name' do
allow(assignment).to receive(:finished?).with(123).and_return(false)
allow(assignment).to receive(:topic_missing?).with(123).and_return(false)
allow(DueDate).to receive(:get_next_due_date).with(1,123).and_return(assignment_due_date)
deadline = create(:deadline_type, id: 1, name:"Review")
allow(DeadlineType).to receive(:find).with(1).and_return(deadline)
expect(assignment.get_current_stage_name(123)).to eq('Review')
end
end
end
end
</pre>

===='''Tests for finished?'''====

We have added tests for the new method that we have added finished?.

<pre>
describe '#finished?' do
context 'when assignment next due date is nil' do
it 'returns True' do
allow(DueDate).to receive(:get_next_due_date).with(1, 123).and_return(nil)
expect(assignment.finished?(123)).to eq(TRUE)
end
end
end

describe '#finished?' do
context 'when there is a next due date' do
it 'returns False' do
allow(DueDate).to receive(:get_next_due_date).with(1, 123).and_return('2021-11-11 11:11:11')
expect(assignment.finished?(123)).to eq(false)
end
end
end
</pre>

As topic_missing? method is made private,there was no need to test this.

===='''Tests for stage_deadline'''====

We also have corrected the tests for stage_deadline according to the modifications done(It is using finished? and topic_missing? methods).

<pre>
describe '#stage_deadline' do
context 'when topic id is nil and current assignment has staggered deadline' do
it 'returns Unknown' do
allow(assignment).to receive(:topic_missing?).and_return(true)
expect(assignment.stage_deadline).to eq('Unknown')
end
end

context 'when current assignment does not have staggered deadline' do
context 'when due date is nil' do
it 'returns nil' do
allow(assignment).to receive(:finished?).with(123).and_return(true)
expect(assignment.stage_deadline(123)).to be nil
end
end

context 'when due date is not nil and due date is not equal to Finished' do
it 'returns due date' do
allow(assignment).to receive(:finished?).with(123).and_return(false)
allow(DueDate).to receive(:get_next_due_date).with(1, 123).and_return(assignment_due_date)
expect(assignment.stage_deadline(123)).to match('2011-11-11 11:11:11')
end
end
end
end
</pre>

=='''Team'''==
[mailto:jwboykin@ncsu.edu Jimmy Boykin]<br>
[mailto:rkaur@ncsu.edu Ramandeep Kaur]<br>
[mailto:sbasnet2@ncsu.edu Sushan Basnet]

CSC/ECE 517 Spring 2019 - Project E1906. Refactor stage deadlines in Assignment.rb

2019-03-24T22:23:27Z

Sbasnet2:

File:Csn2.png

2019-03-24T22:01:23Z

Sbasnet2: uploaded a new version of "File:Csn2.png"

File:Csn2.png

2019-03-24T21:58:21Z

Sbasnet2:

CSC/ECE 517 Spring 2019 - Project E1906. Refactor stage deadlines in Assignment.rb

2019-03-24T21:50:28Z

Sbasnet2:

File:Current stage name initial.png

2019-03-24T21:49:38Z

Sbasnet2: