Expertiza_Wiki - User contributions [en]

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

2025-04-22T03:30:59Z

Irajput: /* 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 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test results.png|900px]] 

[[File:new_code.jpg|900px]]

== Conclusion ==
This document outlines the approach taken to improve test coverage for the questionnaire_helper.rb file in Expertiza. Test cases were developed for all key methods, including adjust_advice_size, update_questionnaire_questions, and questionnaire_factory. With these additions, the file now has full method coverage. The focus going forward will be to maintain this coverage and ensure that any future changes to the module are accompanied by corresponding tests.

==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]
* Demo Video:

== References ==

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

File:Test results.png

2025-04-22T03:30:39Z

Irajput:

File:Test suite.png

2025-04-22T03:29:02Z

Irajput: Irajput reverted File:Test suite.png to an old version

File:Test suite.png

2025-04-22T03:28:41Z

Irajput: Irajput reverted File:Test suite.png to an old version

File:Test suite.png

2025-04-22T03:26:46Z

Irajput: Irajput uploaded a new version of File:Test suite.png

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

2025-04-22T02:50:49Z

Irajput: /* Project Overview */

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 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|900px]] 

[[File:new_code.jpg|900px]]

== Conclusion ==
This document outlines the approach taken to improve test coverage for the questionnaire_helper.rb file in Expertiza. Test cases were developed for all key methods, including adjust_advice_size, update_questionnaire_questions, and questionnaire_factory. With these additions, the file now has full method coverage. The focus going forward will be to maintain this coverage and ensure that any future changes to the module are accompanied by corresponding tests.

==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]
* Demo Video:

== References ==

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

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

2025-04-22T02:50:14Z

Irajput: /* 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.

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|900px]] 

[[File:new_code.jpg|900px]]

== Conclusion ==
This document outlines the approach taken to improve test coverage for the questionnaire_helper.rb file in Expertiza. Test cases were developed for all key methods, including adjust_advice_size, update_questionnaire_questions, and questionnaire_factory. With these additions, the file now has full method coverage. The focus going forward will be to maintain this coverage and ensure that any future changes to the module are accompanied by corresponding tests.

==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]
* Demo Video:

== References ==

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

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

2025-04-22T02:47:57Z

Irajput: /* 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.

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|900px]] 

[[File:new_code.jpg|900px]]

== 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]
* Demo Video:

== References ==

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

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

2025-04-22T02:47:12Z

Irajput: /* Links */

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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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]
* Demo Video:

== References ==

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

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

2025-04-22T02:46:51Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:46:43Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:46:26Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

it 'updates all changed fields and saves the question' do
# Ensures all changed fields are updated and saved.
allow(@question1).to receive(:send).with("txt").and_return("old")
allow(@question1).to receive(:send).with("weight").and_return("1")

expect(@question1).to receive(:send).with("txt=", "new")
expect(@question1).to receive(:send).with("weight=", "2")
expect(@question1).to receive(:save)

allow(self).to receive(:params).and_return({
question: {
"1" => { "txt" => "new", "weight" => "2" }
}
})

update_questionnaire_questions
end
</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:44:49Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</syntaxhighlight>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:44:29Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<pre>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</pre>

=== 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).

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</syntaxhighlight>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:43:35Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<pre>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</pre>

=== 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).

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</source>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:43:27Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
'''Ruby code:'''
<pre>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</pre>

=== 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).

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</source>

=== 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.

==== Code Snippet ====
<syntaxhighlight lang="ruby" line>
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</syntaxhighlight>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:41:52Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
'''Ruby code:'''
<pre>
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</pre>

=== 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).

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</source>

=== 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.

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</source>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:38:45Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

context 'when question is a ScoredQuestion' do
it 'deletes advice entries outside valid score range' do
# Verifies advice entries outside the valid score range are deleted.
expect(QuestionAdvice).to receive(:delete).with(
['question_id = ? AND (score > ? OR score < ?)', question.id, 3, 1]
)
allow(QuestionAdvice).to receive(:where).and_return([])

QuestionnaireHelper.adjust_advice_size(questionnaire, question)
end
end
</source>

=== 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).

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</source>

=== 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.

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</source>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:37:29Z

Irajput: /* questionnaire_factory */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end
</source>

=== 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).

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper
end

it 'returns the correct questionnaire instance for a valid type' do
# Ensures the correct questionnaire instance is returned for valid types.
instance = questionnaire_factory('ReviewQuestionnaire')
expect(instance).to be_a(ReviewQuestionnaire)
end

it 'sets flash error and returns nil for an invalid type' do
# Verifies flash error is set and nil is returned for invalid types.
flash_hash = {}
allow(self).to receive(:flash).and_return(flash_hash)

result = questionnaire_factory('InvalidType')
expect(result).to be_nil
expect(flash_hash[:error]).to eq('Error: Undefined Questionnaire')
end
</source>

=== 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.

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</source>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:35:40Z

Irajput: /* update_questionnaire_questions */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end
</source>

=== 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.

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</source>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:35:15Z

Irajput: /* update_questionnaire_questions */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end
</source>

=== 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.

==== Code Snippet ====
<source lang="ruby">
before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

</source>

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:34:30Z

Irajput: /* Expectations */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end
</source>

=== 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.

before do
extend QuestionnaireHelper

@question1 = double('Question', id: 1)
@question2 = double('Question', id: 2)

allow(Question).to receive(:find).with("1").and_return(@question1)
allow(Question).to receive(:find).with("2").and_return(@question2)
end

it 'returns early if params[:question] is nil' do
# Ensures method exits early when no questions are provided.
allow(self).to receive(:params).and_return({})
expect(@question1).not_to receive(:save)
update_questionnaire_questions
end

== Coverage Results ==
=== Questionnaire_helper ===
* Previous coverage: 42.86%
* Current coverage: 100.00%
[[File:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:33:26Z

Irajput: /* Code Snippet */

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).

==== Code Snippet ====
<source lang="ruby">
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end
</source>

=== 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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:32:30Z

Irajput: /* Expectations */

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).

==== Code Snippet ====

let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }
before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end
context 'when question is not a ScoredQuestion' do
it 'does not perform any operations' do
# Ensures no operations are performed for non-scored questions.
non_scored_question = double('Question')
expect(non_scored_question).to receive(:is_a?).with(ScoredQuestion).and_return(false)
expect(QuestionAdvice).not_to receive(:delete)
QuestionnaireHelper.adjust_advice_size(questionnaire, non_scored_question)
end
end

=== 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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:31:56Z

Irajput: /* Test Setup */

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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:31:18Z

Irajput: /* Test Setup */

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.

* Code snippet
let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }
before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

==== 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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:30:58Z

Irajput: /* Test Setup */

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.

let(:questionnaire) { double('Questionnaire', min_question_score: 1, max_question_score: 3) }
let(:question) { double('ScoredQuestion', id: 101, question_advices: []) }

before do
allow(question).to receive(:is_a?).with(ScoredQuestion).and_return(true)
end

==== 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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:26:44Z

Irajput: /* 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.

=== 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:Test_suite.png|800px]] 

[[File:new_code.jpg|800px]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:26:32Z

Irajput: /* 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.

=== 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:Test_suite.png|750px]] 

[[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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:26:23Z

Irajput: /* 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.

=== 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:Test_suite.png|500px]] 

[[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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:26:09Z

Irajput: /* 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.

=== 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:Test_suite.png]] 

[[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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

File:Test suite.png

2025-04-22T02:25:37Z

Irajput:

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

2025-04-22T02:23:37Z

Irajput: /* 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.

=== 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: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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:23:20Z

Irajput: /* 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.

=== 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]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:23:07Z

Irajput: /* 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.

=== 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]]

== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-22T02:22:52Z

Irajput: /* 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.

=== 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-08T03:21:14Z

Irajput: /* Links */

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: 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]
* GitHub Repository: [https://github.com/ishani-rajput/expertiza]

== References ==

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

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

2025-04-08T03:20:11Z

Irajput: /* Current Code Coverage */

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: 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/)

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

2025-04-08T02:03:05Z

Irajput: /* update_questionnaire_questions */

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

2025-04-08T02:02:34Z

Irajput: /* Expectations */

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

2025-04-08T02:02:27Z

Irajput: /* Test Contexts */

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

2025-04-08T02:02:18Z

Irajput: /* Test Setup */

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 ====

==== Test Setup ====

==== Test Contexts ====

==== Expectations ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T02:02:10Z

Irajput: /* Objective */

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 ====

==== Test Setup ====

==== Test Contexts ====

==== Expectations ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T02:01:55Z

Irajput: /* Expectations */

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 ====

==== Test Setup ====

==== Test Contexts ====

==== Expectations ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T02:01:38Z

Irajput: /* Test Contexts */

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 ====

==== Test Setup ====

==== Test Contexts ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T02:01:27Z

Irajput: /* Test Setup */

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 ====

==== Test Setup ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T02:01:18Z

Irajput: /* Objective */

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 ====

==== 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]
* Github Pull Request: [https://github.com/expertiza/expertiza/pull/2950 Pull Request]

== References ==

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

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

2025-04-08T01:48:39Z

Irajput: /* Objective 1: Develop code testing scenarios for questionnaire_helper */

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 ===

* 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 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 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]]

== 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]

* 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/) 
3. Pluggable reputation systems for peer review: A web-service approach (https://doi.org/10.1109/FIE.2015.7344292)

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

2025-04-08T01:48:28Z

Irajput: /* Constants */

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 ===

* 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 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 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]]

== 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]

* 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/) 
3. Pluggable reputation systems for peer review: A web-service approach (https://doi.org/10.1109/FIE.2015.7344292)

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

2025-04-08T01:43:31Z

Irajput: /* Methods */

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 ===

* 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)
- 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 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]]

== 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]

* 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) 
2. The live Expertiza website (http://expertiza.ncsu.edu/) 
3. Pluggable reputation systems for peer review: A web-service approach (https://doi.org/10.1109/FIE.2015.7344292)