Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-22T00:09:20Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:number_of_cases.png|500px]]
[[File:lines_covered.jpg|500px]]
[[File:new_code.jpg|500px]]

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* GitHub Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza Github]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-22T00:08:24Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Number_of_cases.jpg|500px]]
[[File:lines_covered.jpg|500px]]
[[File:new_code.jpg|500px]]

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* GitHub Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza Github]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-22T00:05:32Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:number_of_cases.jpg|500px]]
[[File:lines_covered.jpg|500px]]
[[File:new_code.jpg|500px]]

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* GitHub Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza Github]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-22T00:04:03Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:number_of_cases.jpg]]
[[File:lines_covered.jpg]]
[[File:new_code.jpg]]

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* GitHub Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza Github]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

File:New code.jpg

2025-04-22T00:01:44Z

Pgandhi4:

File:Lines covered.jpg

2025-04-22T00:01:07Z

Pgandhi4:

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-21T23:59:44Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:number_of_cases.png]]

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* GitHub Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza Github]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T03:17:01Z

Pgandhi4: /* Conclusion */

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: TBD after implementation
* Current coverage: TBD after implementation

== Conclusion ==
This document presents a comprehensive strategy to improve testing and code coverage for the questionnaire_helper files in Expertiza. With clear objectives such as creating detailed test plans and scenarios, the project seeks to close existing coverage gaps. While the questionnaire_helper.rb file showed only slight improvements—mainly because the update_questionnaire_questions method was already fully covered—the focus now shifts to executing the proposed test plans to ensure robust testing and reliability across all key functionalities in both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T03:14:18Z

Pgandhi4: /* Questionnaire_helper */

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project focuses on developing test cases for the questionnaire_helper module within Expertiza, an open-source assignment and project management system built using Ruby on Rails. The platform supports collaborative learning by enabling instructors to design assignments, set up topics for sign-up, and organize student teams. Meanwhile, students can choose topics, work in groups, and engage in peer assessments to support each other's learning. The primary aim of this project is to create thorough test plans and improve code coverage for these helper modules, ensuring their functionality and dependability within the Expertiza system.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: TBD after implementation
* Current coverage: TBD after implementation

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T03:06:42Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2529. Testing for the Questionnaire Helper in Expertiza

== Project Overview ==

=== Problem Statement ===
Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. Instructors can create and customize assignments, define topics for student sign-ups, and manage teams for various projects. Students, on the other hand, can sign up for topics, form teams, and participate in peer reviews to enhance each other's learning experiences. Our goal is to develop comprehensive test plans and increase code coverage for these helper files to ensure their reliability and effectiveness in the Expertiza platform.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi (pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The adjust_advice_size method ensures that every ScoredQuestion has exactly one QuestionAdvice for each score in the range defined by its parent questionnaire. It removes advice entries outside the valid range and eliminates duplicates, while also creating missing entries for scores within range.

==== Test Setup ====
* Create a mock or real Questionnaire instance with:
min_question_score = 1
max_question_score = 5

* Create a ScoredQuestion with:
id assigned
question_advices association

* Populate the QuestionAdvice table with:
Advice entries within the valid range
Advice entries outside the valid range
Duplicate advice entries for the same score

* Stub or use an in-memory DB to test without affecting real data.

==== Test Contexts ====

* Context 1: question is not a ScoredQuestion
Should perform no changes.

* Context 2: question is a ScoredQuestion, with:
Valid advice range entries → should remain untouched.
Advice with scores outside [min, max] → should be deleted.
Duplicate advice entries → should be reduced to one.
Missing advice entries within valid range → should be created.

==== Expectations ====
* In Context 1, the method should exit early and make no database changes.
* In Context 2:
Only one QuestionAdvice should exist for each score in [min, max].
No QuestionAdvice should exist with scores outside [min, max].
All newly created QuestionAdvice entries should have the correct score and question_id.
The total number of QuestionAdvice entries for the question should equal (max - min + 1).

=== questionnaire_factory ===

==== Method Description ====
The questionnaire_factory method is responsible for dynamically creating a new instance of a questionnaire based on a type string provided as input. It uses the QUESTIONNAIRE_MAP constant to resolve the correct class. If the type is not recognized, it sets an error message in the flash hash and returns nil.

==== Test Setup ====
* Ensure QUESTIONNAIRE_MAP is correctly defined with mappings like:
{
"ReviewQuestionnaire" => ReviewQuestionnaire,
"SurveyQuestionnaire" => SurveyQuestionnaire
}
* Stub or create minimal versions of the questionnaire classes (ReviewQuestionnaire, etc.) that support .new.
* Mock the flash hash to observe changes when the type is invalid.

==== Test Contexts ====

* Context 1: Valid questionnaire type is provided (e.g., "ReviewQuestionnaire").
Should return a new instance of ReviewQuestionnaire.

* Context 2: Invalid questionnaire type is provided (e.g., "InvalidType").
Should set an error message in flash[:error].
Should return nil.

* Context 3: type is nil or an empty string.
Should be treated as an invalid type.
Should set flash error and return nil.

==== Expectations ====
* In Context 1:
A new instance of the correct class is returned.
No flash error is set.
* In Context 2:
flash[:error] is set to 'Error: Undefined Questionnaire'.
The method returns nil.
* In Context 3:
Same expectations as Context 2 (error set, return nil).

=== update_questionnaire_questions ===

==== Method Description ====
The update_questionnaire_questions method updates existing Question records with new attribute values received from the request parameters. It ensures that only the changed attributes are updated and saved, thereby optimizing database writes.

==== Test Setup ====
* Define params[:question] as a hash with:
{
"1" => { "txt" => "Updated question text", "weight" => "2" },
"2" => { "txt" => "Another text", "weight" => "1" }
}

* Create corresponding Question objects with:
IDs 1 and 2
Initial attributes set to different values or the same (for testing updates vs no-ops)

* Stub or set up the params object inside a test controller or context.

==== Test Contexts ====
* Context 1: params[:question] is nil
Method should return immediately and make no changes.

* Context 2: params[:question] contains valid data
Some attributes differ from the existing Question values → should update and save.
Some attributes match existing values → should not update those fields.

* Context 3: Mixed changes
One Question has all new values → should be updated and saved.
One Question has no changed values → should not call save.

==== Expectations ====
* In Context 1, no Question records should be loaded or updated.
* In Context 2:
Each Question should receive updated values only for attributes that differ.
question.save should be called only if at least one attribute is updated.
* In Context 3:
Only Question objects with modified attributes should trigger a .save call.
Attributes already matching current values should not be re-assigned.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage:
* Current coverage:

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T02:32:40Z

Pgandhi4:

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T02:13:18Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2440. Testing for questionnaire_helper.

== Project Overview ==

=== Problem Statement ===
Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. Instructors can create and customize assignments, define topics for student sign-ups, and manage teams for various projects. Students, on the other hand, can sign up for topics, form teams, and participate in peer reviews to enhance each other's learning experiences. Our goal is to develop comprehensive test plans and increase code coverage for these helper files to ensure their reliability and effectiveness in the Expertiza platform.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi(pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Dependency Injection Principle (DIP)
The QuestionnaireHelper methods accept objects like questionnaire or scored_question as parameters rather than instantiating them internally. This reflects the Dependency Injection Principle, promoting loose coupling. It also makes the methods easier to test and reuse, since dependencies are provided externally and can be mocked or substituted as needed.

* Single Responsibility Principle (SRP)
Each method in the QuestionnaireHelper module demonstrates the Single Responsibility Principle by handling a specific, well-defined task. For instance, the adjust_advice_size method is solely focused on resizing the advice fields based on score ranges, while the questionnaire_factory method exclusively deals with instantiating questionnaire objects depending on their type. This separation of concerns enhances both the clarity and maintainability of the code.

* Open/Closed Principle (OCP)
Although not immediately visible in limited code snippets, the design follows the Open/Closed Principle by being open to extension but closed to modification. For example, to support new questionnaire types, developers can extend the logic in questionnaire_factory without altering the existing structure, making the system more scalable and adaptable to future changes.

* Factory Method Pattern
The questionnaire_factory method resembles the Factory Method Pattern by generating different types of questionnaire instances based on input parameters. This pattern enables the dynamic creation of objects without hard-coding their specific classes, improving flexibility and extensibility.

* Strategy Pattern
Another applicable pattern is the Strategy Pattern, especially relevant if the behavior of questionnaires (e.g., scoring, rendering, or validation) varies by type. If such behaviors are encapsulated in interchangeable classes and selected at runtime (possibly via the factory method), it aligns well with the Strategy Pattern. This promotes code reusability and simplifies the addition of new behavior types without impacting existing logic.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The .adjust_advice_size method is being described. This method likely adjusts the size of advice related to questions based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a questionnaire, a scored_question, a non_scored_question, and a question_advice.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Question is a ScoredQuestion: This context tests the behavior when the question is a scored question. It sets up expectations related to the adjustment of advice size based on the questionnaire scores.
<pre>
context 'when question is a ScoredQuestion' do
it 'adjusts advice size based on questionnaire scores' do
allow(QuestionAdvice).to receive(:where).and_return([])
allow(QuestionAdvice).to receive(:new).and_return(double('QuestionAdvice', save: true))
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
described_class.adjust_advice_size(questionnaire, scored_question)
expect(QuestionAdvice).to have_received(:where).exactly(10).times
expect(scored_question.question_advices.size).to eq(10)
end
end

</pre>
* When Question is Not a ScoredQuestion: This context tests the behavior when the question is not a scored question. It verifies that in this case, the advice size is not adjusted.
<pre>
context 'when question is not a ScoredQuestion' do
it 'does not adjust advice size' do
allow(QuestionAdvice).to receive(:where)
allow(QuestionAdvice).to receive(:new)
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
described_class.adjust_advice_size(questionnaire, non_scored_question)
expect(QuestionAdvice).not_to have_received(:where)
expect(QuestionAdvice).not_to have_received(:new)
end
end

</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use allow and expect statements to verify the behavior of the method under different conditions.

=== questionnaire_factory ===

==== Method Description ====
The .questionnaire_factory method is described. It seems to be a factory method responsible for creating instances of different questionnaire types based on the given type parameter.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Given a Valid Type: This context verifies the behavior when a valid questionnaire type is provided. It expects that calling questionnaire_factory with a valid type results in an instance of the specified questionnaire type (ReviewQuestionnaire).

<pre>
context 'when given a valid type' do
it 'returns an instance of the specified questionnaire type' do
questionnaire_type = 'ReviewQuestionnaire'
expect(helper.questionnaire_factory(questionnaire_type)).to be_an_instance_of(ReviewQuestionnaire)
end

</pre>
* When Given an Invalid Type: This context tests how the method handles an invalid questionnaire type. It expects that calling questionnaire_factory with an invalid type sets an error flash message indicating that the questionnaire type is undefined.

<pre>
context 'when given an invalid type' do
it 'sets an error flash message' do
questionnaire_type = 'UnknownQuestionnaire'
expect { helper.questionnaire_factory(questionnaire_type) }.to change { flash[:error] }.from(nil).to('Error: Undefined Questionnaire')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect and change statements to verify the behavior of the method under different conditions.

=== update_questionnaire_questions ===

==== Method Description ====

==== Test Setup ====

==== Test Contexts ====

==== Expectations ====

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb
* Current coverage:

[[File:Questionnaire helper spec coverage.jpg]]

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T01:58:16Z

Pgandhi4:

This page describes the changes made for the Spring 2025 E2440. Testing for questionnaire_helper.

== Project Overview ==

=== Problem Statement ===
Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. Instructors can create and customize assignments, define topics for student sign-ups, and manage teams for various projects. Students, on the other hand, can sign up for topics, form teams, and participate in peer reviews to enhance each other's learning experiences. Our goal is to develop comprehensive test plans and increase code coverage for these helper files to ensure their reliability and effectiveness in the Expertiza platform.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Aniruddha Rajenkar (aarajenkar@ncsu.edu)

=== Team Members ===

* Priya Gandhi(pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

In Expertiza, the QuestionnaireHelper module plays a key role in managing questionnaires by providing methods to handle advice sizing, question updates, and questionnaire creation based on type. It also contains constants that assist in executing these tasks. These methods contribute to the smooth handling of questionnaire functionalities across the application. Below are the constants and methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Single Responsibility Principle (SRP):
Each method within the QuestionnaireHelper class appears to adhere to the SRP by focusing on a single task or responsibility. For example, the adjust_advice_size method is responsible for adjusting the size of advice based on questionnaire scores, while the questionnaire_factory method is responsible for creating instances of questionnaire types based on the given type parameter. This adherence ensures that each method has a clear and distinct purpose, promoting code maintainability and readability.

* Open/Closed Principle (OCP):
While not explicitly evident in the provided snippets, the design allows for extension without modification, which aligns with the OCP. For instance, new types of questionnaires can be added without altering existing code by simply extending the questionnaire_factory method to accommodate the new types.

* Dependency Injection Principle (DIP):
The methods in the QuestionnaireHelper class accept various objects (e.g., questionnaire, scored_question) as parameters, adhering to the principle of dependency injection. By accepting dependencies from external sources rather than creating them internally, these methods become more flexible and easily testable.

* Factory Method Pattern:
The questionnaire_factory method can be seen as exhibiting characteristics of the factory method pattern. It dynamically creates instances of different questionnaire types based on the given type parameter, promoting flexibility and extensibility.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The .adjust_advice_size method is being described. This method likely adjusts the size of advice related to questions based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a questionnaire, a scored_question, a non_scored_question, and a question_advice.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Question is a ScoredQuestion: This context tests the behavior when the question is a scored question. It sets up expectations related to the adjustment of advice size based on the questionnaire scores.
<pre>
context 'when question is a ScoredQuestion' do
it 'adjusts advice size based on questionnaire scores' do
allow(QuestionAdvice).to receive(:where).and_return([])
allow(QuestionAdvice).to receive(:new).and_return(double('QuestionAdvice', save: true))
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
described_class.adjust_advice_size(questionnaire, scored_question)
expect(QuestionAdvice).to have_received(:where).exactly(10).times
expect(scored_question.question_advices.size).to eq(10)
end
end

</pre>
* When Question is Not a ScoredQuestion: This context tests the behavior when the question is not a scored question. It verifies that in this case, the advice size is not adjusted.
<pre>
context 'when question is not a ScoredQuestion' do
it 'does not adjust advice size' do
allow(QuestionAdvice).to receive(:where)
allow(QuestionAdvice).to receive(:new)
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
described_class.adjust_advice_size(questionnaire, non_scored_question)
expect(QuestionAdvice).not_to have_received(:where)
expect(QuestionAdvice).not_to have_received(:new)
end
end

</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use allow and expect statements to verify the behavior of the method under different conditions.

=== questionnaire_factory ===

==== Method Description ====
The .questionnaire_factory method is described. It seems to be a factory method responsible for creating instances of different questionnaire types based on the given type parameter.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Given a Valid Type: This context verifies the behavior when a valid questionnaire type is provided. It expects that calling questionnaire_factory with a valid type results in an instance of the specified questionnaire type (ReviewQuestionnaire).

<pre>
context 'when given a valid type' do
it 'returns an instance of the specified questionnaire type' do
questionnaire_type = 'ReviewQuestionnaire'
expect(helper.questionnaire_factory(questionnaire_type)).to be_an_instance_of(ReviewQuestionnaire)
end

</pre>
* When Given an Invalid Type: This context tests how the method handles an invalid questionnaire type. It expects that calling questionnaire_factory with an invalid type sets an error flash message indicating that the questionnaire type is undefined.

<pre>
context 'when given an invalid type' do
it 'sets an error flash message' do
questionnaire_type = 'UnknownQuestionnaire'
expect { helper.questionnaire_factory(questionnaire_type) }.to change { flash[:error] }.from(nil).to('Error: Undefined Questionnaire')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect and change statements to verify the behavior of the method under different conditions.

=== update_questionnaire_questions ===
We did not implement test cases for this method because it was already covered in last semester by previous team.

==== Objective ====
Verify that the method get_intelligent_topic_row_review_bids correctly renders the topic row for the topics table in review_bids/show.html.erb. The #get_intelligent_topic_row_review_bids method is being described. This method likely generates HTML code for displaying topic rows based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a selected_topic, the number of participants (num_participants), and a review_bid.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system. For example, selected_topic is set with a topic ID of 1 and is not waitlisted initially.

==== Test Contexts ====

* When Selected Topics are Present: This context tests the behavior of the method when there are selected topics. It sets up a selected topic that is not waitlisted and expects the generated HTML to include a table row with a yellow background.
<pre>
context 'when selected topics are present' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(false)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="yellow">')
end
end
</pre>
* When Selected Topic is Waitlisted: This context tests the behavior when the selected topic is waitlisted. It sets up a selected topic that is waitlisted and expects the generated HTML to include a table row with a light gray background.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>
* When Selected Topics are Not Present: This context checks what happens when there are no selected topics. It mocks a method (get_topic_bg_color_review_bids) to return a specific background color and expects the generated HTML to include a table row with that background color.
<pre>
context 'when selected topics are not present' do
it 'returns HTML code for topic row with appropriate background color' do
allow(helper).to receive(:get_topic_bg_color_review_bids).and_return('rgb(255,255,255)')
selected_topics = []

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(255,255,255)">')
end
end
</pre>
* When Selected Topics are Nil: This context tests how the method handles cases where the selected topics parameter is nil. It expects the generated HTML to include a table row with a specific background color.
<pre>
context 'when selected topics are nil' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topics = nil

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(47,352,0)">')
end
end
end

</pre>
==== Expectations ====
Each context contains an it block with an expectation. These expectations use expect statements to verify that the HTML generated by the method meets certain criteria, such as containing specific table row elements with appropriate background colors.

==== Objective ====
Verify that the method get_topic_bg_color_review_bids correctly calculates the background color for a topic in the review_bids/show.html.erb template. The #get_topic_bg_color_review_bids method is being described. This method likely determines the background color for a topic based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* Returns RGB Color Code: This test checks if the method returns an RGB color code for the topic background color. It sets up an expectation that the returned color code matches the pattern rgb(\d+,\d+,\d+), indicating it's in the correct format.
<pre>
context 'when there are no review bids' do
it 'returns default RGB color code' do
allow(ReviewBid).to receive(:where).with(signuptopic_id: topic.id).and_return([])

expect(helper.get_topic_bg_color_review_bids(topic, num_participants)).to eq('rgb(47,352,0)')
end
end

</pre>
* When There Are No Review Bids: This context tests the behavior when there are no review bids associated with the topic. It sets up an expectation that the method returns a default RGB color code (rgb(47,352,0)), likely indicating a green color.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect statements to verify the behavior of the method under different conditions.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb
* Current coverage:

[[File:Questionnaire helper spec coverage.jpg]]

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T01:54:35Z

Pgandhi4:

This page describes the changes made for the Spring 2024 E2440. Testing for questionnaire_helper, review_bids_helper

== Project Overview ==

=== Problem Statement ===
Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. Instructors can create and customize assignments, define topics for student sign-ups, and manage teams for various projects. Students, on the other hand, can sign up for topics, form teams, and participate in peer reviews to enhance each other's learning experiences. Our goal is to develop comprehensive test plans and increase code coverage for these helper files to ensure their reliability and effectiveness in the Expertiza platform.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Improve code coverage for questionnaire_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb

=== Mentor ===

* Muhammet Mustafa Olmez (molmez@ncsu.edu)

=== Team Members ===

* Priya Gandhi(pgandhi4@ncsu.edu)
* Saisumanth Tallapragada (stallap@ncsu.edu)
* Ishani Rajput (irajput@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

The QuestionnaireHelper module contains several methods to assist with managing questionnaires in expertiza. QuestionnaireHelper provides methods for adjusting advice size, updating questionnaire questions, and creating questionnaire instances based on types. It also defines constants to facilitate these functionalities. These methods are likely used within the application to handle questionnaire-related tasks efficiently. Let's break down the class and its methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants serve as index references for different fields in a CSV row related to questionnaire data, such as the question text, type, parameters, and weight.

QUESTIONNAIRE_MAP
- A constant hash that maps string identifiers of questionnaire types to their respective Ruby class names.
- Enables dynamic creation of questionnaire objects based on type strings.
- Used by the questionnaire_factory method to instantiate the appropriate questionnaire class.
- Helps avoid repetitive conditional logic by centralizing type-to-class associations.
- Example mapping: 'ReviewQuestionnaire' => ReviewQuestionnaire

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- Ensures that for each valid score in a ScoredQuestion, there exists exactly one QuestionAdvice. It removes extra or invalid advice entries and adds missing ones.
- Parameters:
- `questionnaire`: An instance of a questionnaire that contains scoring boundaries (min_question_score and max_question_score)
- `question`: An instance of ScoredQuestion for which advice needs to be validated and adjusted.
- Functionality:
- Checks if the question is a ScoredQuestion.
- Retrieves the min and max possible scores for the questionnaire.
- Deletes any QuestionAdvice entries for this question that are outside the score bounds.
- Iterates through all valid scores in the range [min, max]:
- Adds a new QuestionAdvice if none exists for that score.
- Deletes extra advice entries if more than one exists for the same score.

2. update_questionnaire_questions
- Updates the attributes of questions in a questionnaire based on form parameters. It only updates attributes whose values have actually changed.
- Functionality:
- Returns early if params[:question] is nil.
- Iterates through each question ID (k) and corresponding attributes (v) in params[:question].
- Finds the Question object by ID.
- For each attribute:
- If the current value differs from the new value, updates the attribute.
- Saves the updated question to the database.

3. questionnaire_factory(type)
- Creates a new instance of a questionnaire based on its type string using a predefined mapping.
- Parameters:
- `type`: A String representing the name of the questionnaire type (e.g., "ReviewQuestionnaire")
- Functionality:
- Looks up the class constant from the QUESTIONNAIRE_MAP using the given type string.
- If no match is found, sets a flash error (flash[:error]).
- If a match is found, returns a new instance of the corresponding questionnaire class.

== Objective : Develop code testing scenarios for questionnaire_helper ==
* Single Responsibility Principle (SRP):
Each method within the QuestionnaireHelper class appears to adhere to the SRP by focusing on a single task or responsibility. For example, the adjust_advice_size method is responsible for adjusting the size of advice based on questionnaire scores, while the questionnaire_factory method is responsible for creating instances of questionnaire types based on the given type parameter. This adherence ensures that each method has a clear and distinct purpose, promoting code maintainability and readability.

* Open/Closed Principle (OCP):
While not explicitly evident in the provided snippets, the design allows for extension without modification, which aligns with the OCP. For instance, new types of questionnaires can be added without altering existing code by simply extending the questionnaire_factory method to accommodate the new types.

* Dependency Injection Principle (DIP):
The methods in the QuestionnaireHelper class accept various objects (e.g., questionnaire, scored_question) as parameters, adhering to the principle of dependency injection. By accepting dependencies from external sources rather than creating them internally, these methods become more flexible and easily testable.

* Factory Method Pattern:
The questionnaire_factory method can be seen as exhibiting characteristics of the factory method pattern. It dynamically creates instances of different questionnaire types based on the given type parameter, promoting flexibility and extensibility.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The .adjust_advice_size method is being described. This method likely adjusts the size of advice related to questions based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a questionnaire, a scored_question, a non_scored_question, and a question_advice.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Question is a ScoredQuestion: This context tests the behavior when the question is a scored question. It sets up expectations related to the adjustment of advice size based on the questionnaire scores.
<pre>
context 'when question is a ScoredQuestion' do
it 'adjusts advice size based on questionnaire scores' do
allow(QuestionAdvice).to receive(:where).and_return([])
allow(QuestionAdvice).to receive(:new).and_return(double('QuestionAdvice', save: true))
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
described_class.adjust_advice_size(questionnaire, scored_question)
expect(QuestionAdvice).to have_received(:where).exactly(10).times
expect(scored_question.question_advices.size).to eq(10)
end
end

</pre>
* When Question is Not a ScoredQuestion: This context tests the behavior when the question is not a scored question. It verifies that in this case, the advice size is not adjusted.
<pre>
context 'when question is not a ScoredQuestion' do
it 'does not adjust advice size' do
allow(QuestionAdvice).to receive(:where)
allow(QuestionAdvice).to receive(:new)
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
described_class.adjust_advice_size(questionnaire, non_scored_question)
expect(QuestionAdvice).not_to have_received(:where)
expect(QuestionAdvice).not_to have_received(:new)
end
end

</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use allow and expect statements to verify the behavior of the method under different conditions.

=== questionnaire_factory ===

==== Method Description ====
The .questionnaire_factory method is described. It seems to be a factory method responsible for creating instances of different questionnaire types based on the given type parameter.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Given a Valid Type: This context verifies the behavior when a valid questionnaire type is provided. It expects that calling questionnaire_factory with a valid type results in an instance of the specified questionnaire type (ReviewQuestionnaire).

<pre>
context 'when given a valid type' do
it 'returns an instance of the specified questionnaire type' do
questionnaire_type = 'ReviewQuestionnaire'
expect(helper.questionnaire_factory(questionnaire_type)).to be_an_instance_of(ReviewQuestionnaire)
end

</pre>
* When Given an Invalid Type: This context tests how the method handles an invalid questionnaire type. It expects that calling questionnaire_factory with an invalid type sets an error flash message indicating that the questionnaire type is undefined.

<pre>
context 'when given an invalid type' do
it 'sets an error flash message' do
questionnaire_type = 'UnknownQuestionnaire'
expect { helper.questionnaire_factory(questionnaire_type) }.to change { flash[:error] }.from(nil).to('Error: Undefined Questionnaire')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect and change statements to verify the behavior of the method under different conditions.

=== update_questionnaire_questions ===
We did not implement test cases for this method because it was already covered in last semester by previous team.

==== Objective ====
Verify that the method get_intelligent_topic_row_review_bids correctly renders the topic row for the topics table in review_bids/show.html.erb. The #get_intelligent_topic_row_review_bids method is being described. This method likely generates HTML code for displaying topic rows based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a selected_topic, the number of participants (num_participants), and a review_bid.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system. For example, selected_topic is set with a topic ID of 1 and is not waitlisted initially.

==== Test Contexts ====

* When Selected Topics are Present: This context tests the behavior of the method when there are selected topics. It sets up a selected topic that is not waitlisted and expects the generated HTML to include a table row with a yellow background.
<pre>
context 'when selected topics are present' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(false)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="yellow">')
end
end
</pre>
* When Selected Topic is Waitlisted: This context tests the behavior when the selected topic is waitlisted. It sets up a selected topic that is waitlisted and expects the generated HTML to include a table row with a light gray background.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>
* When Selected Topics are Not Present: This context checks what happens when there are no selected topics. It mocks a method (get_topic_bg_color_review_bids) to return a specific background color and expects the generated HTML to include a table row with that background color.
<pre>
context 'when selected topics are not present' do
it 'returns HTML code for topic row with appropriate background color' do
allow(helper).to receive(:get_topic_bg_color_review_bids).and_return('rgb(255,255,255)')
selected_topics = []

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(255,255,255)">')
end
end
</pre>
* When Selected Topics are Nil: This context tests how the method handles cases where the selected topics parameter is nil. It expects the generated HTML to include a table row with a specific background color.
<pre>
context 'when selected topics are nil' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topics = nil

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(47,352,0)">')
end
end
end

</pre>
==== Expectations ====
Each context contains an it block with an expectation. These expectations use expect statements to verify that the HTML generated by the method meets certain criteria, such as containing specific table row elements with appropriate background colors.

==== Objective ====
Verify that the method get_topic_bg_color_review_bids correctly calculates the background color for a topic in the review_bids/show.html.erb template. The #get_topic_bg_color_review_bids method is being described. This method likely determines the background color for a topic based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* Returns RGB Color Code: This test checks if the method returns an RGB color code for the topic background color. It sets up an expectation that the returned color code matches the pattern rgb(\d+,\d+,\d+), indicating it's in the correct format.
<pre>
context 'when there are no review bids' do
it 'returns default RGB color code' do
allow(ReviewBid).to receive(:where).with(signuptopic_id: topic.id).and_return([])

expect(helper.get_topic_bg_color_review_bids(topic, num_participants)).to eq('rgb(47,352,0)')
end
end

</pre>
* When There Are No Review Bids: This context tests the behavior when there are no review bids associated with the topic. It sets up an expectation that the method returns a default RGB color code (rgb(47,352,0)), likely indicating a green color.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect statements to verify the behavior of the method under different conditions.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb
* Current coverage:

[[File:Questionnaire helper spec coverage.jpg]]

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>

CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza

2025-04-08T01:16:40Z

Pgandhi4: Created page with "This page describes the changes made for the Spring 2024 E2440. Testing for questionnaire_helper, review_bids_helper == Project Overview == === Problem Statement === Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. In..."

This page describes the changes made for the Spring 2024 E2440. Testing for questionnaire_helper, review_bids_helper

== Project Overview ==

=== Problem Statement ===
Our project involves writing test cases for the `questionnaire_helper` and `review_bids_helper` files in Expertiza, an open-source assignment/project management portal built on the Ruby on Rails framework. This platform facilitates collaborative learning and feedback among both instructors and students. Instructors can create and customize assignments, define topics for student sign-ups, and manage teams for various projects. Students, on the other hand, can sign up for topics, form teams, and participate in peer reviews to enhance each other's learning experiences. Our goal is to develop comprehensive test plans and increase code coverage for these helper files to ensure their reliability and effectiveness in the Expertiza platform.

=== Current Code Coverage ===
* Questionnaire_helper: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb
* Review_bids_helper: 17.65%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Freview_bids_helper.rb

=== Objectives ===

* Develop test plans/scenarios for questionnaire_helper.rb
* Develop test plans/scenarios for review_bids_helper.rb
* Improve code coverage for questionnaire_helper.rb
* Improve code coverage for review_bids_helper.rb

=== Files Involved ===

* Questionnaire_helper.rb: /app/helpers/questionnaire_helper.rb
* Review_bids_helper.rb: /app/helpers/review_bids_helper.rb

=== Mentor ===

* Muhammet Mustafa Olmez (molmez@ncsu.edu)

=== Team Members ===

* Neha Vijay Patil (npatil2@ncsu.edu)
* Prachit Mhalgi (psmhalgi@ncsu.edu)
* Sahil Santosh Sawant (ssawant2@ncsu.edu)

== Class and Method Overview ==

=== QuestionnaireHelper ===

The QuestionnaireHelper module contains several methods to assist with managing questionnaires in expertiza. QuestionnaireHelper provides methods for adjusting advice size, updating questionnaire questions, and creating questionnaire instances based on types. It also defines constants to facilitate these functionalities. These methods are likely used within the application to handle questionnaire-related tasks efficiently. Let's break down the class and its methods:

==== Constants ====

CSV_QUESTION, CSV_TYPE, CSV_PARAM, CSV_WEIGHT
- These constants define indices for specific columns in a CSV file.

QUESTIONNAIRE_MAP
- This constant is a hash that maps questionnaire types to their respective questionnaire classes.
- It's used by the `questionnaire_factory` method to determine the appropriate class to instantiate.

==== Methods ====

1. adjust_advice_size(questionnaire, question)
- This method adjusts the size of advice associated with a given question in a questionnaire.
- Parameters:
- `questionnaire`: The questionnaire object.
- `question`: The question object whose advice size needs adjustment.
- Functionality:
- Checks if the question is a `ScoredQuestion`.
- Deletes any existing advice for the question outside the score range.
- Iterates over the score range and ensures each score has an associated advice.
- Deletes any duplicate advice records.

2. update_questionnaire_questions
- This method updates attributes of questionnaire questions based on form data, without modifying unchanged attributes.
- Functionality:
- Checks for presence of `params[:question]`.
- Iterates through each question and its attributes in the parameters.
- Compares each attribute's current value with the new value from the parameters and updates if changed.
- Saves the question.

3. questionnaire_factory(type)
- This method acts as a factory to create an appropriate questionnaire object based on the type provided.
- Parameters:
- `type`: The type of questionnaire.
- Functionality:
- Retrieves the questionnaire class from `QUESTIONNAIRE_MAP` based on the provided type.
- If the type is not found in the map, it sets an error flash message.
- Otherwise, it initializes a new instance of the corresponding questionnaire class and returns it.

=== ReviewBidsHelper ===

This Ruby module, `ReviewBidsHelper` serves as a helper module for views related to reviewing bids in expertiza. `ReviewBidsHelper` provides helper methods for rendering topic rows and determining the background color for topics based on their bid status and the number of participants. These methods are likely used in the views associated with reviewing bids in the application. Let's break down the class and its methods:

==== Methods ====

1. get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)
- This method seems to be responsible for generating HTML markup for a row in a table displaying topics for review bids.
- Parameters:
- `topic`: Represents a specific topic being reviewed.
- `selected_topics`: An array of topics that have been selected.
- `num_participants`: The number of participants involved in the review process.
- Functionality:
- Iterates through the `selected_topics`.
- Depending on the conditions (whether the topic is selected and not waitlisted, or selected and waitlisted), it generates a specific row HTML.
- Returns the generated row HTML as safe HTML.

2. get_topic_bg_color_review_bids(topic, num_participants)
- This method calculates the background color for a topic based on the number of participants and the number of bids for that topic.
- Parameters:
- `topic`: Represents the topic for which the background color is being determined.
- `num_participants`: The total number of participants.
- Functionality:
- Calculates the number of bids for the given `topic`.
- Determines the proportion of bids compared to the total number of participants and adjusts the color accordingly.
- Returns a string representing the RGB value of the background color.

== Objective 1: Develop code testing scenarios for questionnaire_helper ==
* Single Responsibility Principle (SRP):
Each method within the QuestionnaireHelper class appears to adhere to the SRP by focusing on a single task or responsibility. For example, the adjust_advice_size method is responsible for adjusting the size of advice based on questionnaire scores, while the questionnaire_factory method is responsible for creating instances of questionnaire types based on the given type parameter. This adherence ensures that each method has a clear and distinct purpose, promoting code maintainability and readability.

* Open/Closed Principle (OCP):
While not explicitly evident in the provided snippets, the design allows for extension without modification, which aligns with the OCP. For instance, new types of questionnaires can be added without altering existing code by simply extending the questionnaire_factory method to accommodate the new types.

* Dependency Injection Principle (DIP):
The methods in the QuestionnaireHelper class accept various objects (e.g., questionnaire, scored_question) as parameters, adhering to the principle of dependency injection. By accepting dependencies from external sources rather than creating them internally, these methods become more flexible and easily testable.

* Factory Method Pattern:
The questionnaire_factory method can be seen as exhibiting characteristics of the factory method pattern. It dynamically creates instances of different questionnaire types based on the given type parameter, promoting flexibility and extensibility.

After reviewing the QuestionnaireHelper class, we identified three methods in the class that require testing. These methods are as follows:

* adjust_advice_size
* questionnaire_factory
* update_questionnaire_questions

=== adjust_advice_size ===
==== Method Description ====
The .adjust_advice_size method is being described. This method likely adjusts the size of advice related to questions based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a questionnaire, a scored_question, a non_scored_question, and a question_advice.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Question is a ScoredQuestion: This context tests the behavior when the question is a scored question. It sets up expectations related to the adjustment of advice size based on the questionnaire scores.
<pre>
context 'when question is a ScoredQuestion' do
it 'adjusts advice size based on questionnaire scores' do
allow(QuestionAdvice).to receive(:where).and_return([])
allow(QuestionAdvice).to receive(:new).and_return(double('QuestionAdvice', save: true))
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
described_class.adjust_advice_size(questionnaire, scored_question)
expect(QuestionAdvice).to have_received(:where).exactly(10).times
expect(scored_question.question_advices.size).to eq(10)
end
end

</pre>
* When Question is Not a ScoredQuestion: This context tests the behavior when the question is not a scored question. It verifies that in this case, the advice size is not adjusted.
<pre>
context 'when question is not a ScoredQuestion' do
it 'does not adjust advice size' do
allow(QuestionAdvice).to receive(:where)
allow(QuestionAdvice).to receive(:new)
allow(scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
described_class.adjust_advice_size(questionnaire, non_scored_question)
expect(QuestionAdvice).not_to have_received(:where)
expect(QuestionAdvice).not_to have_received(:new)
end
end

</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use allow and expect statements to verify the behavior of the method under different conditions.

=== questionnaire_factory ===

==== Method Description ====
The .questionnaire_factory method is described. It seems to be a factory method responsible for creating instances of different questionnaire types based on the given type parameter.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* When Given a Valid Type: This context verifies the behavior when a valid questionnaire type is provided. It expects that calling questionnaire_factory with a valid type results in an instance of the specified questionnaire type (ReviewQuestionnaire).

<pre>
context 'when given a valid type' do
it 'returns an instance of the specified questionnaire type' do
questionnaire_type = 'ReviewQuestionnaire'
expect(helper.questionnaire_factory(questionnaire_type)).to be_an_instance_of(ReviewQuestionnaire)
end

</pre>
* When Given an Invalid Type: This context tests how the method handles an invalid questionnaire type. It expects that calling questionnaire_factory with an invalid type sets an error flash message indicating that the questionnaire type is undefined.

<pre>
context 'when given an invalid type' do
it 'sets an error flash message' do
questionnaire_type = 'UnknownQuestionnaire'
expect { helper.questionnaire_factory(questionnaire_type) }.to change { flash[:error] }.from(nil).to('Error: Undefined Questionnaire')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect and change statements to verify the behavior of the method under different conditions.

=== update_questionnaire_questions ===
We did not implement test cases for this method because it was already covered in last semester by previous team.

== Objective 2: Develop code testing scenarios for review_bids_helper ==
* Single Responsibility Principle (SRP):
Each method within the ReviewBidsHelper class seems to adhere to the SRP. For example, get_intelligent_topic_row_review_bids is responsible for generating HTML code for topic rows, while get_topic_bg_color_review_bids determines the background color for a topic. This adherence ensures that each method has a clear and distinct purpose, enhancing maintainability and readability.

* Factory Method Pattern:
Although not explicitly labeled as a factory method, get_intelligent_topic_row_review_bids can be interpreted as following a similar pattern. It dynamically generates HTML code based on different scenarios, akin to a factory producing instances of objects. This promotes flexibility and extensibility in generating HTML representations of topics.

After reviewing the ReviewBidsHelper module, we identified two methods that require testing:

=== get_intelligent_topic_row_review_bids ===
==== Objective ====
Verify that the method get_intelligent_topic_row_review_bids correctly renders the topic row for the topics table in review_bids/show.html.erb. The #get_intelligent_topic_row_review_bids method is being described. This method likely generates HTML code for displaying topic rows based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a selected_topic, the number of participants (num_participants), and a review_bid.
Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system. For example, selected_topic is set with a topic ID of 1 and is not waitlisted initially.

==== Test Contexts ====

* When Selected Topics are Present: This context tests the behavior of the method when there are selected topics. It sets up a selected topic that is not waitlisted and expects the generated HTML to include a table row with a yellow background.
<pre>
context 'when selected topics are present' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(false)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="yellow">')
end
end
</pre>
* When Selected Topic is Waitlisted: This context tests the behavior when the selected topic is waitlisted. It sets up a selected topic that is waitlisted and expects the generated HTML to include a table row with a light gray background.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>
* When Selected Topics are Not Present: This context checks what happens when there are no selected topics. It mocks a method (get_topic_bg_color_review_bids) to return a specific background color and expects the generated HTML to include a table row with that background color.
<pre>
context 'when selected topics are not present' do
it 'returns HTML code for topic row with appropriate background color' do
allow(helper).to receive(:get_topic_bg_color_review_bids).and_return('rgb(255,255,255)')
selected_topics = []

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(255,255,255)">')
end
end
</pre>
* When Selected Topics are Nil: This context tests how the method handles cases where the selected topics parameter is nil. It expects the generated HTML to include a table row with a specific background color.
<pre>
context 'when selected topics are nil' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topics = nil

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr id="topic_1" style="background-color:rgb(47,352,0)">')
end
end
end

</pre>
==== Expectations ====
Each context contains an it block with an expectation. These expectations use expect statements to verify that the HTML generated by the method meets certain criteria, such as containing specific table row elements with appropriate background colors.

=== get_topic_bg_color_review_bids ===

==== Objective ====
Verify that the method get_topic_bg_color_review_bids correctly calculates the background color for a topic in the review_bids/show.html.erb template. The #get_topic_bg_color_review_bids method is being described. This method likely determines the background color for a topic based on certain conditions.

==== Test Setup ====
Mock objects are set up using let statements. These include a topic, a review_bid, and the number of participants (num_participants). Each of these mock objects is prepared with predefined attributes that mimic the behavior of actual objects in the system.

==== Test Contexts ====

* Returns RGB Color Code: This test checks if the method returns an RGB color code for the topic background color. It sets up an expectation that the returned color code matches the pattern rgb(\d+,\d+,\d+), indicating it's in the correct format.
<pre>
context 'when there are no review bids' do
it 'returns default RGB color code' do
allow(ReviewBid).to receive(:where).with(signuptopic_id: topic.id).and_return([])

expect(helper.get_topic_bg_color_review_bids(topic, num_participants)).to eq('rgb(47,352,0)')
end
end

</pre>
* When There Are No Review Bids: This context tests the behavior when there are no review bids associated with the topic. It sets up an expectation that the method returns a default RGB color code (rgb(47,352,0)), likely indicating a green color.
<pre>
context 'when selected topic is waitlisted' do
it 'returns HTML code for topic row with appropriate background color' do
selected_topic = instance_double('SelectedTopic')
allow(selected_topic).to receive(:topic_id).and_return(1)
allow(selected_topic).to receive(:is_waitlisted).and_return(true)
selected_topics = [selected_topic]

expect(helper.get_intelligent_topic_row_review_bids(topic, selected_topics, num_participants)).to include('<tr bgcolor="lightgray">')
end
end
</pre>

==== Expectations ====
Each test contains an it block with an expectation. These expectations use expect statements to verify the behavior of the method under different conditions.

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 66%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Fquestionnaire_helper.rb
* Current coverage:

[[File:Questionnaire helper spec coverage.jpg]]

=== Review bids helper ===
* Previous coverage: 17.65%: https://coveralls.io/builds/66490075/source?filename=app%2Fhelpers%2Freview_bids_helper.rb
* Current coverage:

[[File:Review bid helper spec coverage.jpg]]

== Conclusion ==
This document outlines a thorough plan to enhance testing and code coverage for the questionnaire_helper and review_bids_helper files in Expertiza. With defined objectives, including developing detailed test plans and scenarios, the project aims to address current code coverage gaps. Notably, significant improvements were achieved in the review_bids_helper.rb file, with comprehensive test plans substantially increasing code coverage. Conversely, the questionnaire_helper.rb file saw marginal improvements, primarily due to existing full coverage in the update_questionnaire_questions method. Moving forward, the project will focus on implementing the outlined test plans, ensuring comprehensive testing and reliability for critical functionality across both helper files.

==Links==
* Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

* Link to Testing video: [https://youtu.be/jDfmPUgDDXA]

* Link to pull request : [https://github.com/expertiza/expertiza/pull/2799 here]

== References ==

1. Expertiza on GitHub (https://github.com/expertiza/expertiza) <br>
2. The live Expertiza website (http://expertiza.ncsu.edu/) <br>
3. Pluggable reputation systems for peer review: A web-service approach (https://doi.org/10.1109/FIE.2015.7344292)

CSC/ECE 517 Spring 2025

2025-04-08T01:16:08Z

Pgandhi4: /* Final Projects */

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2528 Testing for Survey Deployment]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2535 Reimplement User Profile Management (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]
* [[CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza]]

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T21:40:54Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

===Proposed System===
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Files Involved==

*app/controllers/submission_records_controller.rb
*app/models/submission_record.rb
*app/views/student_task/list.html.erb
*app/views/submission_records/index.html.erb

==Database Tables Involved==

*submission_records

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.

Role-based conditions were implemented to prevent unauthorized access.

[[File:submission-records-controller.png|400px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.

The UI was updated to ensure that students could only access records linked to their own submissions.

[[File:submission-records-views.png|400px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.

This view mirrors the instructor’s interface but with restricted data access.
<pre><code>
<h1>Submission History</h1>

<% if @submission_records.any? %>
<table class="table table-striped">
<thead>
<tr>
<th>Submission ID</th>
<th>Submitted By</th>
<th>Submission Time</th>
<th>File</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<% @submission_records.each do |record| %>
<tr>
<td><%= record.id %></td>
<td><%= record.submitter.try(:name) || "Unknown" %></td>
<td><%= record.created_at.strftime("%Y-%m-%d %H:%M:%S") %></td>
<td>
<% if record.file_url.present? %>
<%= link_to "View File", record.file_url, target: "_blank" %>
<% else %>
No file uploaded
<% end %>
</td>
<td><%= record.comments.presence || "No comments" %></td>
</tr>
<% end %>
</tbody>
</table>
<% else %>
<p>No submission records found for this team.</p>
<% end %>

<%= link_to "Back to Assignments", assignments_path, class: "btn btn-primary" %>
</code></pre>

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students. The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected. These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/delaneydow/reimplementation-back-end GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

[https://github.com/expertiza/reimplementation-back-end Reimplementation Backend Repository]

[https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E1797_Timestamps_for_students_submission Referred Wiki Page]

Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragada, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T21:40:32Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

===Proposed System===
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Files Involved==

*app/controllers/submission_records_controller.rb
*app/models/submission_record.rb
*app/views/student_task/list.html.erb
*app/views/submission_records/index.html.erb

==Database Tables Involved==

*submission_records

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.

Role-based conditions were implemented to prevent unauthorized access.

[[File:submission-records-controller.png|400px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.

The UI was updated to ensure that students could only access records linked to their own submissions.

[[File:submission-records-views.png|400px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.

This view mirrors the instructor’s interface but with restricted data access.
<pre><code>
<h1>Submission History</h1>

<% if @submission_records.any? %>
<table class="table table-striped">
<thead>
<tr>
<th>Submission ID</th>
<th>Submitted By</th>
<th>Submission Time</th>
<th>File</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<% @submission_records.each do |record| %>
<tr>
<td><%= record.id %></td>
<td><%= record.submitter.try(:name) || "Unknown" %></td>
<td><%= record.created_at.strftime("%Y-%m-%d %H:%M:%S") %></td>
<td>
<% if record.file_url.present? %>
<%= link_to "View File", record.file_url, target: "_blank" %>
<% else %>
No file uploaded
<% end %>
</td>
<td><%= record.comments.presence || "No comments" %></td>
</tr>
<% end %>
</tbody>
</table>
<% else %>
<p>No submission records found for this team.</p>
<% end %>

<%= link_to "Back to Assignments", assignments_path, class: "btn btn-primary" %>
</code></pre>

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students. The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected. These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/delaneydow/reimplementation-back-end GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

[https://github.com/expertiza/reimplementation-back-end Reimplementation Backend Repository]

[https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E1797_Timestamps_for_students_submission Referred Wiki Page]
Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragada, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T21:20:50Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

===Proposed System===
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Files Involved==

*app/controllers/submission_records_controller.rb
*app/models/submission_record.rb
*app/views/student_task/list.html.erb
*app/views/submission_records/index.html.erb

==Database Tables Involved==

*submission_records

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.

Role-based conditions were implemented to prevent unauthorized access.

[[File:submission-records-controller.png|400px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.

The UI was updated to ensure that students could only access records linked to their own submissions.

[[File:submission-records-views.png|400px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.

This view mirrors the instructor’s interface but with restricted data access.
<pre><code>
<h1>Submission History</h1>

<% if @submission_records.any? %>
<table class="table table-striped">
<thead>
<tr>
<th>Submission ID</th>
<th>Submitted By</th>
<th>Submission Time</th>
<th>File</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<% @submission_records.each do |record| %>
<tr>
<td><%= record.id %></td>
<td><%= record.submitter.try(:name) || "Unknown" %></td>
<td><%= record.created_at.strftime("%Y-%m-%d %H:%M:%S") %></td>
<td>
<% if record.file_url.present? %>
<%= link_to "View File", record.file_url, target: "_blank" %>
<% else %>
No file uploaded
<% end %>
</td>
<td><%= record.comments.presence || "No comments" %></td>
</tr>
<% end %>
</tbody>
</table>
<% else %>
<p>No submission records found for this team.</p>
<% end %>

<%= link_to "Back to Assignments", assignments_path, class: "btn btn-primary" %>
</code></pre>

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students. The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected. These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/delaneydow/reimplementation-back-end GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

[https://github.com/expertiza/reimplementation-back-end Reimplementation Backend Repository]

Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragada, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T21:08:23Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

===Proposed System===
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==

==Files Involved==

*app/controllers/submission_records_controller.rb
*app/models/submission_record.rb
*app/views/student_task/list.html.erb
*app/views/submission_records/index.html.erb

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.

Role-based conditions were implemented to prevent unauthorized access.

[[File:submission-records-controller.png|400px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.

The UI was updated to ensure that students could only access records linked to their own submissions.

[[File:submission-records-views.png|400px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.

This view mirrors the instructor’s interface but with restricted data access.

[[File:submission-records-students-views.png|400px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students. The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected. These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/WintersLt/expertiza GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragada, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T21:08:01Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Proposed System==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==

==Files Involved==

*app/controllers/submission_records_controller.rb
*app/models/submission_record.rb
*app/views/student_task/list.html.erb
*app/views/submission_records/index.html.erb

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.

Role-based conditions were implemented to prevent unauthorized access.

[[File:submission-records-controller.png|400px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.

The UI was updated to ensure that students could only access records linked to their own submissions.

[[File:submission-records-views.png|400px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.

This view mirrors the instructor’s interface but with restricted data access.

[[File:submission-records-students-views.png|400px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students. The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected. These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/WintersLt/expertiza GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragada, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:44:16Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
=== Ruby on Rails ===
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Scope==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==
Design patterns are not applicable as our task involved just implementing a method. However, the [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records#Implementation|Implementation]] section below provides details of the steps as why it was implemented, the way it was implemented.

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.
Role-based conditions were implemented to prevent unauthorized access.
[[File:submission-records-controller.png|600px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.
The UI was updated to ensure that students could only access records linked to their own submissions.
[[File:submission-records-views.png|700px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.
This view mirrors the instructor’s interface but with restricted data access.
[[File:submission-records-students-views.png|700px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students.
The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected.
These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.
==References==

[https://github.com/expertiza/expertiza Expertiza on GitHub]

[https://github.com/WintersLt/expertiza GitHub Project Repository Fork]

[http://expertiza.ncsu.edu/ The Live Expertiza Website]

[http://bit.ly/myexpertiza Demo Link]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Project Documentation]

[https://relishapp.com/rspec RSpec Documentation]

Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

==Team Members==
Priya Gandhi, Saisumanth Tallapragda, Delaney Dow

===Mentors===
Anirudha Rajenkar, Ed Grehringer

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:41:23Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
=== Ruby on Rails ===
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Scope==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==
Design patterns are not applicable as our task involved just implementing a method. However, the [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records#Implementation|Implementation]] section below provides details of the steps as why it was implemented, the way it was implemented.

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.
Role-based conditions were implemented to prevent unauthorized access.
[[File:submission-records-controller.png|600px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.
The UI was updated to ensure that students could only access records linked to their own submissions.
[[File:submission-records-views.png|700px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.
This view mirrors the instructor’s interface but with restricted data access.
[[File:submission-records-students-views.png|700px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students.
The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected.
These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.

==References==
<references/>

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:40:44Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
=== Ruby on Rails ===
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Scope==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==
Design patterns are not applicable as our task involved just implementing a method. However, the [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records#Implementation|Implementation]] section below provides details of the steps as why it was implemented, the way it was implemented.

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.
Role-based conditions were implemented to prevent unauthorized access.
[[File:submission-records-controller.png|600px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.
The UI was updated to ensure that students could only access records linked to their own submissions.
[[File:submission-records-views.png|600px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.
This view mirrors the instructor’s interface but with restricted data access.
[[File:submission-records-students-views.png|600px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students.
The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected.
These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.

==References==
<references/>

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:39:44Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
=== Ruby on Rails ===
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Scope==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

1. Updating the access control logic to grant students permission to view their own submission records.

2. Ensuring students cannot access other teams’ submission records.

3. Modifying the UI to present submission history in an intuitive manner.

4. Updating API routes and database queries to fetch the relevant submission data.

5. Writing and executing test cases to validate the changes.

==Design Pattern==
Design patterns are not applicable as our task involved just implementing a method. However, the [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records#Implementation|Implementation]] section below provides details of the steps as why it was implemented, the way it was implemented.

==Implementation==
1. Identify the Existing Access Control Mechanism:
We examined the existing authorization logic that restricted students from viewing their own submission records.
Access permissions were defined at the controller level, requiring updates to include student roles.

2.Modify the Submission Record Controller:
We modified the controller to allow students to retrieve their own submission records while ensuring security constraints.
Role-based conditions were implemented to prevent unauthorized access.
[[File:submission-records-controller.png|600px]]

3.Update Submission-Records View for Students:
A new student-friendly interface was added to display submission history.
The UI was updated to ensure that students could only access records linked to their own submissions.
[[File:submission-records-views.png|500px]]

4.Create a New View for Submission Records:
A separate view was introduced to present submission records in a structured format.
This view mirrors the instructor’s interface but with restricted data access.
[[File:submission-records-students-views.png|500px]]

5.Update API Routes in config/routes.rb:
New API endpoints were configured to fetch relevant submission data for students.
The changes ensured compatibility with the existing API architecture.

6.Perform Testing Using RSpec:
We wrote unit and integration tests to verify that the new functionality worked as expected.
These tests ensured that students could only access their own submission records.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.

==References==
<references/>

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:33:57Z

Pgandhi4:

<font size="5">E2507. Reimplement back end for submission records</font><br>
Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students.

==Introduction==
=== Ruby on Rails ===
Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over configuration, making web development faster and more efficient by providing built-in tools for common tasks like database management, routing, and authentication.

=== Expertiza's Existing Submission Records Feature ===
In the existing Expertiza system, instructors are provided with detailed submission history for each assignment. This allows instructors to track the progress of students, view their submissions, and monitor whether students have completed their assignments on time. However, this feature was restricted to instructors only, leaving students without visibility into their own submission records. This limitation often made it challenging for students to track their progress or verify that their submissions were properly recorded, especially in case of discrepancies or issues with the submission system.

With this project, the goal is to extend this feature, allowing students to view their own submission history, which will improve transparency and provide them with better control over their assignments.

==Scope==
The primary objective of this project is to modify the Submission Record Controller so that submission records become visible to students. Previously, only instructors had access to these records. The key deliverables include:

Updating the access control logic to grant students permission to view their own submission records.

Ensuring students cannot access other teams’ submission records.

Modifying the UI to present submission history in an intuitive manner.

Updating API routes and database queries to fetch the relevant submission data.

Writing and executing test cases to validate the changes.

==Design Pattern==
Design patterns are not applicable as our task involved just implementing a method. However, the [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records#Implementation|Implementation]] section below provides details of the steps as why it was implemented, the way it was implemented.

==Implementation==
Identify the existing access control mechanism that restricts students from viewing their submission records.

Modified the Submission Record Controller to allow students to view their own submission records while maintaining appropriate permissions.
[[File:submission-records-controller.png|500px]]

Updated Submission-records view for students to see history of their submission for each assignment.
[[File:submission-records-views.png|500px]]

Created a new view to display submission records for students.
[[File:submission-records-students-views.png|500px]]

Updated paths in config/routes.rb for API responses to fetch the relevant submission data.

Performed testing using Rspec.

== Testing ==

===Automated Testing using RSPEC===
The current version of expertiza backend reimplementation did not have a testing suite for the Submission Records controller, or the submission record model that tested the extended student functionality that we added. Using a combination of the test driven development(TDD) and behavior driven design (BDD) approach, we added in RSpec testing for the SubmissionRecordsController and Submission model files that tested our modifications. The student functionality was only added and tested exhaustively since the instructor and admin functionality has already been developed. Since the controller was designed for APIs and returning all HTTP calls when appropriate, this was integrated into the testing framework to check as well. The testing suite is compatible with APIs and swagger framework according the the project document specifications.

====Example review of test cases====
The below code is an example of some of the testing structure for the RSpec testing.

<pre>
# GET /api/v1/student_task (Get student tasks)

describe 'GET /submission_records/:id' do
context 'when the student is part of the team' do
it 'allows access and returns a 200 status' do
get "/submission_records/#{submission_record.id}", headers: valid_headers
expect(response).to have_http_status(:ok)
end
end

context 'when the student is NOT part of the team' do
it 'denies access and returns a 403 status' do
get "/submission_records/#{submission_record.id}", headers: unauthorized_headers
expect(response).to have_http_status(:forbidden)
end
end

context 'when an invalid token is provided' do
it 'returns a 401 status' do
get "/submission_records/#{submission_record.id}", headers: invalid_headers
expect(response).to have_http_status(:unauthorized)
end
end
end
</pre>

====Executing test cases====
The tests can be executed "rpec spec" command as shown below, and works best when set up locally or via Docker.

<pre>
bundle install
rake db:create:all
rake db:migrate
rails s
.
user-expertiza/backend-reimplementation $rspec spec
.
.
.
Finished in 5.39 seconds (files took 25.33 seconds to load)

</pre>

===Testing from UI===
The only UI changes that were made included added a student view that mimics the instructor view. The view path 'app/view/submission_records' represents this. The added functionality ensures that, when logged in as a student, only those students who are associated with the team of that specific assignment that has been submitted can view the record.

1. When logged in as Student A, navigate to the student task list, where there will be a column that links to the submission record view.

2. By clicking on the submission record column, student A will then be able to see the submission record history, if applicable.

3. When logging in as student B who is not associated with the team that the assignment/submission record is linked to, they will not be able to see any submission records.

==Pull Request==
Here is our [https://github.com/expertiza/reimplementation-back-end/pull/175 pull request]. In the link you can see all code snippets changed due to implementing the above steps, as well as integration test progression information.

==References==
<references/>

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:32:11Z

Pgandhi4:

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:06:12Z

Pgandhi4:

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T20:04:22Z

Pgandhi4:

File:Submission-records-students-views.png

2025-03-24T19:53:23Z

Pgandhi4:

File:Submission-records-views.png

2025-03-24T19:52:47Z

Pgandhi4:

File:Submission-records-controller.png

2025-03-24T19:51:53Z

Pgandhi4:

CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records

2025-03-24T19:43:25Z

Pgandhi4: Created page with "<font size="5">E2507. Reimplement back end for submission records</font><br> Currently only instructors can see the submission history of the participants of particular assignment currently. The goal of this project is to extend submission records to students. ==Introduction== === Ruby on Rails === Ruby on Rails (Rails) is a server-side web application framework written in Ruby that follows the MVC (Model-View-Controller) architecture. It emphasizes convention over conf..."

CSC/ECE 517 Spring 2025

2025-03-23T17:55:29Z

Pgandhi4:

* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Fall 2024 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]