https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Ppraman2Expertiza_Wiki - User contributions [en]2026-05-17T00:13:03ZUser contributionsMediaWiki 1.41.0https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107982CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:34:24Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Use Cases==<br />
<br />
The project can be broken down into two primary use cases.<br />
<br />
* The user wants to view the scores before the assignment is finished. Scores are calculated "on the fly" and presented to the user.<br />
* The user wants to view the scores after the assignment is finished. Scores are calculated on assignment completion and stored in the database for quick retrieval.<br />
<br />
==Test Plan==<br />
<br />
The above two use cases can then be translated into three major scenarios we need to test. The use case where the assignment is completed and scores are stored into the database is broken down into two scenarios to test the data input and data retrieval parts separately.<br />
<br />
<br />
The following table contains the main scenarios we will cover when testing our project.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
<br />
The following diagrams show how the chosen scenarios above map to functionality.<br />
<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
<br />
<br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107981CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:31:47Z<p>Ppraman2: /* Use Cases */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Use Cases==<br />
<br />
The project can be broken down into two primary use cases.<br />
<br />
* The user wants to view the scores before the assignment is finished. Scores are calculated "on the fly" and presented to the user.<br />
* The user wants to view the scores after the assignment is finished. Scores are calculated on assignment completion and stored in the database for quick retrieval.<br />
<br />
==Test Plan==<br />
<br />
<br />
The following table contains the main scenarios we will cover when testing our project.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
<br />
The following diagrams show how the chosen scenarios above map to functionality.<br />
<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
<br />
<br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107980CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:28:58Z<p>Ppraman2: </p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Use Cases==<br />
<br />
==Test Plan==<br />
<br />
<br />
The following table contains the main scenarios we will cover when testing our project.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
<br />
The following diagrams show how the chosen scenarios above map to functionality.<br />
<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
<br />
<br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107979CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:26:09Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
The following table contains the main scenarios we will cover when testing our project.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
<br />
The following diagrams show how the chosen scenarios above map to functionality.<br />
<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
<br />
<br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107978CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:25:37Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
The following table contains the main scenarios we will cover when testing our project.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
<br />
The following diagrams show how the chosen scenarios above map to functionality<br />
<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
<br />
<br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107977CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-07T00:24:10Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The "answers" table only contains the scores that user A has given user B on each criterion. This means that if we need to know what score A has given B based on 100, we have to rely on the code to calculate it every time the score is requested. This design slows down Expertiza as every time an instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. In this case, the system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanisms to handle the holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc<br />
** This is similar to the current scenario<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, they will be fetched using a single db query and displayed<br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in the table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record to be inserted is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated and stored for each of the review rounds because it is possible that user A only reviews user B in one out of several rounds<br />
* When a request is made to view the scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}<br />
<br />
[[File:E1731-scenario-1.jpg|frame|center]] <br />
[[File:E1731-scenario-2-3.jpg|frame|center]]</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=File:E1731-scenario-2-3.jpg&diff=107976File:E1731-scenario-2-3.jpg2017-04-07T00:22:32Z<p>Ppraman2: </p>
<hr />
<div></div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=File:E1731-scenario-1.jpg&diff=107975File:E1731-scenario-1.jpg2017-04-07T00:21:44Z<p>Ppraman2: </p>
<hr />
<div></div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107968CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:53:06Z<p>Ppraman2: </p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in this new db table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated for all the review rounds because it is possible that user A only review user B in one out of several rounds<br />
* When a request is made to view scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| 1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| 2<br />
| Assignment is NOT finished and user wants to view scores. First, set up an assignment with a deadline in the future. Put in some score information. The score should be calculated correctly on the fly using OnTheFlyCalc.<br />
| After the assignment is created, this test will run on the UI. The user will click the view scores link and the page should display the expected score.<br />
|-<br />
| 3<br />
| Assignment is finished and the user wants to view scores. This test will mainly just be a check if clicking view scores on the UI will result in the expected value showing up on the UI. The interaction in getting the information in the database is already tested in Scenario 1.<br />
| User clicks on view scores on a past assignment and sees the expected score on the UI<br />
|}</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107967CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:42:14Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in this new db table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated for all the review rounds because it is possible that user A only review user B in one out of several rounds<br />
* When a request is made to view scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
|1<br />
| An assignment is finished and a score is calculated correctly and placed into the local_db_score table using the scheduled task feature. First, set up an assignment with some score information. Create a scheduled task to calculate the score and insert the score into the database upon assignment completion.<br />
| Query the database and verify score is correct<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107964CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:34:08Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in this new db table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated for all the review rounds because it is possible that user A only review user B in one out of several rounds<br />
* When a request is made to view scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Description<br />
! Expected Result for Pass<br />
|-<br />
| row 1, cell 1<br />
| row 1, cell 2<br />
| row 1, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107963CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:28:45Z<p>Ppraman2: </p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==<br />
* A general ScoreCalc class will be created<br />
* OnTheFlyCalc and LocalDBCalc classes will be created which will be subclasses of ScoreCalc class<br />
* A new database table "local_db_scores" with following columns will be created to store the holistic scores:<br />
** id: int<br />
** type: string<br />
** round: int<br />
** score: int<br />
** reference_id: int<br />
* When an assignment finishes (that is when the deadline has passed), holistic scores will be calculated in LocalDBCalc and then inserted in this new db table "local_db_score"<br />
** This will be done using scheduled tasks feature<br />
** If the record is a finalized peer-review score, the type stored in the database will be "ReviewLocalDBScore" and the reference_id will be the response_map id<br />
** The peer-review scores will be calculated for all the review rounds because it is possible that user A only review user B in one out of several rounds<br />
* When a request is made to view scores, depending on whether the assignment is ongoing or finished, either OnTheFlyCalc or LocalDBCalc will be called to calculate the score or query the score from the "local_db_scores" table<br />
<br />
==Test Plan==</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107960CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:07:48Z<p>Ppraman2: /* Proposed Solution */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work only for peer-review scores. As future projects will introduce other types of scores, the solution must be extensible.<br />
<br />
==Design Plan==</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107959CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T23:04:19Z<p>Ppraman2: /* Current Scenario */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Today, Expertiza stores the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work for peer-review scores only, by making sure the code is extensible for further work.<br />
<br />
==Design Plan==</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017/E1731_Improve_Score_Calculation&diff=107958CSC/ECE 517 Spring 2017/E1731 Improve Score Calculation2017-04-06T22:59:35Z<p>Ppraman2: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
<br />
<nowiki> Expertiza is an opensource web based platform developed to assist students in educational institutions to perform peer reviews and group projects. The reviewing is done through a mechanism where students will be sent request to review work and the system will analyze and publish a summarized report. The software is designed in MVC (Model-View-Controller) architecture using Ruby on Rails.<br />
</nowiki><br />
<br />
==Problem Description==<br />
===Current Scenario===<br />
Expertiza store the scores based on each response to each criterion, but no holistic scores are stored. The answers table only contains the score that A gives B on each criterion. This means that if we need to know what score user A gives to user B based on 100, we have to rely on the code to calculate it every time the scores are requested. This design slows down Expertiza as every time instructor clicks on "View Scores", all the calculations are done to display the score. The situation is even worse if we want to weight the scores by the reputation of each reviewer, which is a measure of how closely that reviewer's scores match other reviewers. The system potentially has to do thousands of arithmetic calculations to display the score for a particular assignment.<br />
<br />
===Proposed Solution===<br />
We propose that we have two mechanism to handle holistic scores, depending on the current state of the assignment:<br />
* OnTheFlyCalc: Calculates holistic scores over a set of data: A set of records in answers table, namely the responses from user A to user B on each criterion.<br />
** When an assignment is still ongoing, the reputations for each reviewer will be calculated and handled by OnTheFlyCalc.<br />
* LocalDBCalc: Calculates the holistic score over a single db query: "get the score that user A gives user B on assignment 999 on round 2"<br />
** When an asignment has finished, all the reputations will be calculated by LocalDBCalc and stored, since they are finalized. So, when the scores are requested, it is fetched using a single db query and displayed. <br />
<br />
In this project, our goal is to make the OnTheFlyCalc and LocalDBCalc work for peer-review scores only, by making sure the code is extensible for further work.<br />
<br />
==Design Plan==</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107690CSC/ECE 517 Spring 2017 E17112017-03-31T22:50:54Z<p>Ppraman2: /* Extra Credit */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:E1711.Slide1.jpg|frame|center]] <br />
[[File:Slide2.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Unit<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Unit<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Unit<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy_params<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy_params)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107689CSC/ECE 517 Spring 2017 E17112017-03-31T22:50:30Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:E1711.Slide1.jpg|frame|center]] <br />
[[File:Slide2.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Unit<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Unit<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Unit<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Unit<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Unit<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107622CSC/ECE 517 Spring 2017 E17112017-03-30T23:45:52Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:E1711.Slide1.jpg|frame|center]] <br />
[[File:Slide2.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107621CSC/ECE 517 Spring 2017 E17112017-03-30T23:42:22Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:E1711.Slide1.jpg|frame|center]] <br />
[[File:E1711.Slide2.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107620CSC/ECE 517 Spring 2017 E17112017-03-30T23:41:56Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:E1711.Slide1.jpg|frame|center]] <br />
[[File:E1711.Slide2r.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=File:Slide2.jpg&diff=107619File:Slide2.jpg2017-03-30T23:38:29Z<p>Ppraman2: </p>
<hr />
<div></div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=File:E1711.Slide1.jpg&diff=107618File:E1711.Slide1.jpg2017-03-30T23:37:30Z<p>Ppraman2: </p>
<hr />
<div></div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107617CSC/ECE 517 Spring 2017 E17112017-03-30T23:32:46Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107616CSC/ECE 517 Spring 2017 E17112017-03-30T23:25:42Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.<br />
<br />
<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107612CSC/ECE 517 Spring 2017 E17112017-03-30T22:47:33Z<p>Ppraman2: /* Extra Credit */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To fix this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107611CSC/ECE 517 Spring 2017 E17112017-03-30T22:46:20Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107582CSC/ECE 517 Spring 2017 E17112017-03-30T01:19:36Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107581CSC/ECE 517 Spring 2017 E17112017-03-30T01:18:11Z<p>Ppraman2: /* Refactor the perform mehtod */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Fucntional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We made the existing tests more complete by adding in sections that properly created the data objects. We also added verification that once the job is executed, the deadline type for the job is what we expected. We also added verification to make sure that the number of jobs were changing and the mail delivery counts were increasing as expected. <br />
<br />
The six existing tests that we modified were scenarios 1 to 6 listed above.<br />
<br />
===Our Testing===<br />
<br />
We modified existing test cases for the <code>perform</code> method to be more thorough. We continuously would run these tests during development to make sure they continue to pass.<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107580CSC/ECE 517 Spring 2017 E17112017-03-30T01:11:02Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Number<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| 1<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 2<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 3<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 4<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 5<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 6<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| 7<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Fucntional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 8<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 9<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| 10<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107579CSC/ECE 517 Spring 2017 E17112017-03-30T01:09:06Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests. The selection of the added tests were to verify the functions that were restructured as a part of this effort. Functions that were not touched are out of the scope of this assignment so no tests were added there. Adding tests for other functions can be a future assignment.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Verify <code>find_team_members_email_for_all_topics</code> works.<br />
| Fucntional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| Verify <code>mail_signed_up_users</code> works when there are sign up topics.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.<br />
| Rspec<br />
| Added<br />
|-<br />
| Verify <code>find_signed_up_team_members_email</code> works.<br />
| Functional<br />
| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.<br />
| Rspec<br />
| Added<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107578CSC/ECE 517 Spring 2017 E17112017-03-30T00:47:52Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| <br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107577CSC/ECE 517 Spring 2017 E17112017-03-30T00:47:06Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful. Also note that for each of the groups getting emails, the test cases only deliver one email. That is because the DB has a minimum amount of test data where each group to send the emails to only has one member and one email address.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadline reminders to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email review deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email drop topic deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
-<br />
| Email sign up deadline reminders to all assignment participants <br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email team formation deadline reminders to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| <br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107576CSC/ECE 517 Spring 2017 E17112017-03-30T00:35:51Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
Also you will note at the start of the tests, a lot of information is created in the DB. All these things need to be in the DB in order to verify that the mailer is successful.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadlines to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email review deadlines to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email metareview deadlines to metareviews and team members of the assignment<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email drop topic deadlines to reviewers<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified|<br />
-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107575CSC/ECE 517 Spring 2017 E17112017-03-30T00:26:04Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadlines to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches.\n Verify that the submission type of the job is submission deadline.\n Verify the count of mail deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| Email review deadlines to reviewers<br />
| Functional<br />
| <br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107574CSC/ECE 517 Spring 2017 E17112017-03-30T00:22:46Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadlines to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches and the mailer deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107573CSC/ECE 517 Spring 2017 E17112017-03-30T00:21:59Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the test cases for ''delayed_mailer.rb''<br />
Much of our work consisted of modifying the existing tests so they were more thorough and adding some tests.<br />
<br />
You can find the test cases in ''delayed_mailer_spec.rb''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
! Test Tool<br />
! Test Added/Modified<br />
|-<br />
| Email submission deadlines to signed up users<br />
| Functional<br />
| A new delayed mailing task is created. The number of delayed jobs pending is increased by 1. One second later, the job launches and the mailer deliveries increase by 1.<br />
| Rspec<br />
| Modified<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107572CSC/ECE 517 Spring 2017 E17112017-03-30T00:00:56Z<p>Ppraman2: /* Future Refactoring Opportunities */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the <b>new</b> test cases as a result of the refactoring effort.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
|-<br />
| row 1, cell 1<br />
| row 1, cell 2<br />
| row 1, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
5. We found out that all assignments in Expertiza are team assignments and querying if the assignment is a team assignment is hardcoded to return true. <code>perform</code> does have some business logic where the recipient of the email depends on whether or not the assignment is a team assignment. This business logic needs to be revisited by the Expertiza team before the method can be further simplified to ensure the correct mail goes out in the correct scenario. We kept the logic the same as it was out of our scope to change business logic.<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107571CSC/ECE 517 Spring 2017 E17112017-03-29T23:45:10Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead the below table summarizes the <b>new</b> test cases as a result of the refactoring effort.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Scenario Description<br />
! Test Type<br />
! Test Description<br />
|-<br />
| row 1, cell 1<br />
| row 1, cell 2<br />
| row 1, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107570CSC/ECE 517 Spring 2017 E17112017-03-29T23:42:05Z<p>Ppraman2: </p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead below is a table summarizing the <b>new</b> test cases as a result of the refactoring effort.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Header 1<br />
! Header 2<br />
! Header 3<br />
|-<br />
| row 1, cell 1<br />
| row 1, cell 2<br />
| row 1, cell 3<br />
|-<br />
| row 2, cell 1<br />
| row 2, cell 2<br />
| row 2, cell 3<br />
|}<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107569CSC/ECE 517 Spring 2017 E17112017-03-29T23:39:58Z<p>Ppraman2: /* Test Plan */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
Note that the recommended format for a test plan included creating a flowchart. However, our assignment cannot be easily explained by a flow chart. First, none of the changes impact user behavior (refactoring only). Second, the changes were in an area of the code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart.<br />
<br />
Instead below is a table summarizing the <b>new</b> test cases as a result of the refactoring effort.<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107568CSC/ECE 517 Spring 2017 E17112017-03-29T23:32:09Z<p>Ppraman2: </p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.<br />
<br />
<br />
=Extra Credit=<br />
<br />
During our testing, we found that the "create new late policy" function was broken. It was throwing a ActiveModel::ForbiddenAttributesError on LatePoliciesController#create, as seen below:<br />
<br />
[[File:Late_Policy_Ruby_Error.jpg|frame|center]] <br />
<br />
To find this, we had to add the following code to the private section of late_policies_controller.rb:<br />
<br />
def late_policy<br />
params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)<br />
end<br />
<br />
and change the argument in the LatePolicy.new() to just <br />
<br />
@late_policy = LatePolicy.new(late_policy)<br />
<br />
After these two small changes, we were able to create new late policies from the UI.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107200CSC/ECE 517 Spring 2017 E17112017-03-23T02:37:24Z<p>Ppraman2: /* Future Refactoring Opportunities */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107199CSC/ECE 517 Spring 2017 E17112017-03-23T02:37:04Z<p>Ppraman2: </p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.<br />
<br />
1. Scheduled Task feature does not belong in the mailers. It needs to be a standalone file with new tests added.<br />
2. There are still methods that look like they should be collapsed into one function and opportunities for DRYing out code once other tightly coupled methods are also refactored.<br />
3. There were practically no tests for this area of the code. We added tests for what we modified but much code still remains that is not being tested.<br />
4. There are many calls to the database for the same information in different methods. These repeated calls could probably be reduced to one call and save the result from the database.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107198CSC/ECE 517 Spring 2017 E17112017-03-23T02:32:23Z<p>Ppraman2: /* Quantitative Results from Refactoring Effort */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107196CSC/ECE 517 Spring 2017 E17112017-03-23T02:27:17Z<p>Ppraman2: /* Quantitative Results from Refactoring Effort */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
The following are some highlighted statistics showing our refactoring efforts <i>delayed_mailer.rb</i>.<br />
<br />
Note that the new statistics are incorporating code that used to be in the scheduled tasks file.<br />
<br />
Also note that we did not try to fix issues in areas of the code that were outside the scope of the assignment. We recommend such changes are taken up in future assignments.<br />
<br />
Finally, our selection of statistics for this project was to focus on reducing complexity since code needs to be easily understandable in order to be effectively maintained.<br />
<br />
'''Total Rubocop detected offenses:''' <br />
<br />
Old = 63<br />
New = <br />
<br />
'''Statistics on <code>perform </code>'''<br />
<br />
Old=<br />
<br />
Assignment Branch Condition size for perform is too high. [41.11/15]<br />
<br />
Cyclomatic complexity for perform is too high. [13/6]<br />
<br />
Perceived complexity for perform is too high. [13/7]<br />
<br />
'''Statistics on <code>mail_signed_up_users</code>'''<br />
<br />
Old=<br />
Assignment Branch Condition size for mail_signed_up_users is too high. [33.02/15]<br />
<br />
Cyclomatic complexity for mail_signed_up_users is too high. [10/6]<br />
<br />
Perceived complexity for mail_signed_up_users is too high. [13/7]<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107195CSC/ECE 517 Spring 2017 E17112017-03-23T02:26:34Z<p>Ppraman2: /* Quantitative Results from Refactoring Effort */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
The following are some highlighted statistics showing our refactoring efforts <i>delayed_mailer.rb</i>.<br />
<br />
Note that the new statistics are incorporating code that used to be in the scheduled tasks file.<br />
<br />
Also note that we did not try to fix issues in areas of the code that were outside the scope of the assignment. We recommend such changes are taken up in future assignments.<br />
<br />
Finally, our selection of statistics for this project was to focus on reducing complexity since code needs to be easily understandable in order to be effectively maintained.<br />
<br />
Total Rubocop detected offenses: <br />
<br />
Old = 63<br />
New = <br />
<br />
Statistics on <code>perform </code><br />
<br />
Old=<br />
<br />
Assignment Branch Condition size for perform is too high. [41.11/15]<br />
<br />
Cyclomatic complexity for perform is too high. [13/6]<br />
<br />
Perceived complexity for perform is too high. [13/7]<br />
<br />
Statistics on <code>mail_signed_up_users</code><br />
<br />
Old=<br />
Assignment Branch Condition size for mail_signed_up_users is too high. [33.02/15]<br />
<br />
Cyclomatic complexity for mail_signed_up_users is too high. [10/6]<br />
<br />
Perceived complexity for mail_signed_up_users is too high. [13/7]<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107194CSC/ECE 517 Spring 2017 E17112017-03-23T02:25:54Z<p>Ppraman2: /* Quantitative Results from Refactoring Effort */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
The following are some highlighted statistics showing our refactoring efforts <i>delayed_mailer.rb</i>.<br />
<br />
Note that the new statistics are incorporating code that used to be in the scheduled tasks file.<br />
<br />
Also note that we did not try to fix issues in areas of the code that were outside the scope of the assignment. We recommend such changes are taken up in future assignments.<br />
<br />
Finally, our selection of statistics for this project was to focus on reducing complexity since code needs to be easily understandable in order to be effectively maintained.<br />
<br />
Total Rubocop detected offenses: <br />
<br />
Old = 63<br />
New = <br />
<br />
Statistics on <code>perform </code><br />
<br />
Old=<br />
Assignment Branch Condition size for perform is too high. [41.11/15]<br />
Cyclomatic complexity for perform is too high. [13/6]<br />
Perceived complexity for perform is too high. [13/7]<br />
<br />
Statistics on <code>mail_signed_up_users</code><br />
<br />
Old=<br />
Assignment Branch Condition size for mail_signed_up_users is too high. [33.02/15]<br />
Cyclomatic complexity for mail_signed_up_users is too high. [10/6]<br />
Perceived complexity for mail_signed_up_users is too high. [13/7]<br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107193CSC/ECE 517 Spring 2017 E17112017-03-23T02:14:18Z<p>Ppraman2: </p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We replaced the existing single method <code>mail_signed_up_users</code> with a shorter version and a new method <code>find_team_members_email_for_all_topics</code>. We also heavily modified (including renaming) the existing method <code>getTeamMembersMail</code>, and it is now called <code>find_team_members_email</code>. As the naming of the methods suggest, there are still opportunities for DRYing the two functions to get team member emails, but exiting code makes it extremely difficult to combine the two functions exactly though they are extremely similar at first glance. Merging the two would require refactoring areas outside the scope of this assignment and a whole new set of test cases to verify a lot of basic functionality is not broken in the process. We recommend this is taken up as a part of a future assignment. See </b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We added test cases for each of the methods we changed. There are now 10 test cases that are covering this file. The four new test cases focus on verifying that the functions can access the database to protect against schema changes and making sure the right methods are called. Tests were not added for code that was not within the scope of this assignment but we recommend the remainder of the functions also get similar test cases. See details in <b>Future Refactoring Opportunities</b> below.<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
Some highlights from analysis of the original <i>delayed_mailer.rb</i> file compared with after our changes are: <br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107191CSC/ECE 517 Spring 2017 E17112017-03-23T01:52:22Z<p>Ppraman2: /* Refactor mail_signed_up_users */</p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code> method=<br />
<br />
<br />
===Background of Objective===<br />
<br />
The primary objective of this task was that the method is long and could be broken into smaller appropriately named methods.<br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. None of the six existing tests verified if the emails are being retrieved from the database so changes in the database schema would break the feature.<br />
<br />
=== Our Testing===<br />
<br />
We broke the existing <code>mail_signed_up_users</code> into three functions<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
Some highlights from analysis of the original <i>delayed_mailer.rb</i> file compared with after our changes are: <br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2017_E1711&diff=107177CSC/ECE 517 Spring 2017 E17112017-03-23T01:37:03Z<p>Ppraman2: </p>
<hr />
<div><font size="5"><b> E1711. Refactor delayed_mailer.rb and scheduled_task.rb</b></font><br />
<br />
<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
==Introduction to Expertiza==<br />
<br />
[http://expertiza.ncsu.edu/ Expertiza] is a web based tool that allows instructors to create collaborative assignments where students can provide peer feedback on each others work. It provides instructors a system to manage assignments and different courses.<br />
<br />
==Scope of project E1711==<br />
<br />
The goal of E1711 was to refactor code found in the files <i>delayed_mailer.rb</i> and <i>scheduled_task.rb</i>. <br />
<br />
The following issues were identified as the scope of this project:<br />
<br />
<br />
:::* <i>scheduled_task.rb</i> duplicated most of its code from <i>delayed_mailer.rb</i>. Our objective is to reduce/remove the duplication in keeping with the DRY principle.<br />
:::* The <code>perform</code> method uses a giant case statement, instead we were to incorporate the use of polymorphism<br />
:::* The <code>mail_signed_up_users</code> is long and should be broken into smaller and better named methods<br />
:::* Add/modify test cases as we added/removed/modified areas of the code<br />
<br />
<br />
Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]<br />
<br />
==Test Plan==<br />
<br />
As this was a purely refactoring effort, our testing consisted of confirming existing tests did not break, modifying existing tests to match our changes, or adding tests as needed. The below sections will cover each objective in detail and will include information on how testing was done for each of those changes. See each of the <b>Our Testing</b> sections.<br />
<br />
<br />
=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=<br />
<br />
===Background of Objective===<br />
<br />
The main objective of this task was to reduce duplicated code as recommended by DRY principle.<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called [https://rubygems.org/gems/delayed_job/versions/4.1.2 delayed_job]. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
===Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
<br />
=Refactor the <code>perform</code> mehtod=<br />
<br />
===Background of Objective===<br />
<br />
The objective of this task was to clean up this method. It was identified as being badly named, long, and not taking advantage of good design. It is essentially a giant case statement where one of the variables passed into the <code>DelayedMailer</code> constructor determines the people who receives the email.. Some suggested ways to refactor this function was first rename the <code>perform</code> to better describe what it does and to use polymorphism in place of the case statement. The original thought was that polymorphism could be used to determine what was sent out in each email based on the type of the email.<br />
<br />
===Our Changes===<br />
<br />
The first item we looked at was to rename the method. A generic name such as <code>perform</code> usually means that the method is doing too much or does not have a clear objective. Unfortunately, we found we could not rename the method because the delayed_job gem requires a method named <code>perform</code> in order to work on a custom job. See documentation [http://www.rubydoc.info/gems/delayed_job/4.1.2 here]<br />
<br />
The second part of the planned refactoring was to use polymorphism to determine the content of the email. After simplifying much of the code in the file, we discovered that the content of the email was independent of the variables used to initialize the object. At that point, we weighed the complexity of new code to use polymorphism versus a significantly more simplified case statement, and because of the lack of existing tests, decided that the simplified case statement was not only short, it is also very simple to follow the flow through the code. We instead focused on DRYing out this code as a better return on immediate investment as opposed to adding polymorphism.<br />
<br />
===Existing Tests===<br />
<br />
There were six existing Rspec tests for <i>delayed_mailer.rb</i>, but the existing tests only verify that a new delayed job was added to the queue based on the type of deadline specified when creating a new <code>DelayedMalier</code>. We deemed the existing testing as adequate for this section of the file as the <code>perform</code> method calls other methods to find the email addresses and send the email.<br />
<br />
===Our Testing===<br />
<br />
We did not change existing testing for the <code>perform</code> method as the existing testing verified that a job to send out emails was added to the queue. We did, however, verify that our code changes did not break this portion of the code by continuously running the existing test cases.<br />
<br />
<br />
=Refactor <code>mail_signed_up_users</code>=<br />
<br />
<br />
===Background of Objective===<br />
<br />
After a deep investigation into understanding why the same code would appear in two separate files, we concluded that the authors of <i>scheduled_task.rb</i> found that <i>delayed_mailer.rb</i> already integrated with a Ruby gem called <i>delayed_job</i>. <i>delayed_job</i> is used to run tasks asynchronously in the background. It was used in <i>delayed_mailer</i> to add an outgoing email to a queue to send out in the future. Instead of recreating similar infrastructure, the authors copied over the file to a different location, added on the new desired functionality, and renamed it. The authors also pointed all existing code to use <i>scheduled_task.rb</i> instead of <i>delayed_mailer.rb</i><br />
<br />
===Our Changes===<br />
<br />
We found that the vast majority of the code in both the files applied to sending emails so we decided to merge the <i>scheduled_task.rb</i> into <i>delayed_mailer.rb</i> by porting the enhancements made for the scheduled tasks into <i>delayed_mailer.rb</i>. Doing so allowed us to meet the objective of DRYing out the code. However, we still have a situation where scheduled tasks feature has code in a section devoted to mailer code. We recommend that a future project take up the needed changes to pull out the scheduled task code out of the mailer file and make it a standalone feature as it should have been originally. See details in the <b>Future Refactoring Opportunities</b> below.<br />
<br />
===Existing Tests===<br />
<br />
We did not find any existing automated testing targeting this area of the code. All existing tests in the <code>spec</code> file associated with this feature were copies of the tests in the delayed mailer feature and did not exercise any of the new code that was introduced with adding the new types of scheduled tasks.<br />
<br />
=== Our Testing===<br />
<br />
We went back to the demonstration of this feature and manually tested all the same scenarios. We verified that no functionality presented in the scheduled tasks demonstration was broken. Tests were added for the delayed mailer feature (covered in more details in the following sections). We recommend tests focused towards scheduled tasks are added once the scheduled tasks code is removed from the delayed mailer file back into an independent file.<br />
<br />
=Quantitative Results from Refactoring Effort=<br />
<br />
We used [https://docs.codeclimate.com/v1.0/docs/rubocop Rubocop] to show the improvements in that resulted from this effort.<br />
<br />
Some highlights from analysis of the original <i>delayed_mailer.rb</i> file compared with after our changes are: <br />
<br />
=Future Refactoring Opportunities=<br />
<br />
Once we started to refactor the code, we found many additional opportunities to refactor the files that was beyond the planned scope. We note down some of the opportunities here and leave it to future projects to address.</div>Ppraman2