Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T14:09:54Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png]]

The FeedbackResponseMap class is a subclass of ResponseMap and represents feedback provided in response to a review. It establishes a belongs_to association with a Response object, referenced as review, using reviewed_object_id as the foreign key. The assignment method returns the assignment associated with the original review by accessing it through the review's map. The questionnaire method retrieves a questionnaire record that matches the reviewed_object_id. Lastly, the get_title method returns a predefined constant, FEEDBACK_RESPONSE_MAP_TITLE, that denotes a title for feedback response maps.

[[File:FeedbackResponseMap Tests.png]]

This RSpec test suite verifies the functionality of FeedbackResponseMap model by including tests for the three main methods. The assignment test ensures that the model correctly returns the assignment linked to the feedback through the associated review. The questionnaire test checks that it retrieves the appropriate questionnaire, specifically one of type AuthorFeedbackQuestionnaire, based on the reviewed_object_id. Lastly, the get_title test confirms that the method returns the expected title constant defined for feedback response maps.

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T14:08:27Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png]]

The FeedbackResponseMap class is a subclass of ResponseMap and represents feedback provided in response to a review. It establishes a belongs_to association with a Response object, referenced as review, using reviewed_object_id as the foreign key. The assignment method returns the assignment associated with the original review by accessing it through the review's map. The questionnaire method retrieves a questionnaire record that matches the reviewed_object_id. Lastly, the get_title method returns a predefined constant, FEEDBACK_RESPONSE_MAP_TITLE, that denotes a title for feedback response maps.

[[File:FeedbackResponseMap Tests.png]]

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

File:FeedbackResponseMap Tests.png

2025-04-22T14:07:51Z

Rtgalla2:

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T14:05:47Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png]]

The FeedbackResponseMap class is a subclass of ResponseMap and represents feedback provided in response to a review. It establishes a belongs_to association with a Response object, referenced as review, using reviewed_object_id as the foreign key. The assignment method returns the assignment associated with the original review by accessing it through the review's map. The questionnaire method retrieves a questionnaire record that matches the reviewed_object_id. Lastly, the get_title method returns a predefined constant, FEEDBACK_RESPONSE_MAP_TITLE, that denotes a title for feedback response maps.

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T14:01:30Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png]]

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T14:01:13Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png|300px]]

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:59:56Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.jpg]]

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:59:14Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:58:21Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===
[[File:FeedbackResponseMap.png|thumb|This is the feedback response map]]

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

File:FeedbackResponseMap.png

2025-04-22T13:56:58Z

Rtgalla2:

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:51:10Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

===FeedbackResponseMap===

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:50:45Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

==FeedbackResponseMap==

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-22T13:48:51Z

Rtgalla2:

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==
* survey_response_map.rb
* assignment_survey_response_map.rb
* course_survey_response_map.rb
* global_survey_response_map.rb
* review_response_map.rb
* bookmark_rating_response_map.rb
* feedback_response_map.rb
* meta_review_response_map.rb
* quiz_response_map.rb
* self_review_response_map.rb
* teammate_review_response_map.rb

==Subclasses and Testing==

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.

CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses

2025-04-05T02:46:09Z

Rtgalla2: /* Testing Plan */

==Team==
=====Mentor=====
*Anish Toorpu

=====Members=====
*Dennis Christman <dchrist2@ncsu.edu>
*Eleanor Maye <edmaye@ncsu.edu>
*Ryan Gallagher <rtgalla2@ncsu.edu>

==Problem Statement==
The ResponseMap concept in Expertiza exists as a hierarchy of several different Rails models, that utilize Singe Table Inheritance to allow for the use of polymorphism across the different types of Assignments that different ResponseMaps may map to. While part of the ResponseMap hierarchy has been reimplemented in the the new Expertiza backend, most of it has not. Our team has been tasked with the reimplementation of several of these. Below is the full ResponseMap hierarchy. Class names in bold are ones we are tasked with reimplementing, those in italics are for future projects, and those in neither have already been reimplemented:

*ResponseMap
**'''SurveyResponseMap'''
***'''AssignmentSurveyResponseMap'''
***'''CourseSurveyResponseMap'''
***'''GlobalSurveyResponseMap'''
**ReviewResponseMap
***'''BookmarkRatingResponseMap'''
**'''FeedbackResponseMap'''
**''MetareviewResponseMap''
**'''QuizResponseMap'''
**''SelfReviewResponseMap''
**'''TeammateReviewResponseMap'''

The current implementation lacks a clear hierarchical structure for models, encapsulation of business logic, flexibility due to hardcoded values, and comprehensive testing. This results in maintainability issues, scalability problems, and poor integration with existing components. Additionally, while the current implementation is functional, it is poorly documented, making it difficult for someone new to the project to understand what the purpose of each subclass is.

==Design Goal==
We have several goals for this project:
*Utilize the existing hierarchy and ensure proper inheritance between models.
*Ensure that all business logic and validations are in the proper model. This includes both making sure that code is not unnecessarily repeated in a class and its subclasses and making sure that a class does not contain logic based on its subclasses.
*Move hardcoded values to an environment variables file, and replace instance of that value in the repo with the new environment variable.
*Develop extensive test coverage for each new model.
*Document each new model with clear comments on its use and methods.

==Implementation==

===Implementation Plan===
Our plan will be to start at the top of the hierarchy and find code that is repeated in different places and consolidate to the highest point of the hierarchy where it makes sense, looking at associations, validations and methods. An example of this are the lines:
belongs_to :reviewee, class_name: 'Participant', foreign_key: 'reviewee_id'
belongs_to :assignment, class_name: 'Assignment', foreign_key: 'reviewed_object_id'
which appear in several different models, including the ResponseMap class itself. We will also identify methods such as the '''email''' method that appear in different subclasses that share much of the implementation and refactor the shared parts into a shared method.

==Files Added/Modified==

==Testing Plan==
Foremost, for Unit Testing, we will write tests to ensure that all validations are functioning as anticipated for each model. Furthermore, we will verify that all belongs_to and has_many associations are configured properly and ensure that no dangling records remain after creating or destroying records involved. Moreover, various testing measures will ensure that business logic operates correctly in the model, paying special attention will be given to methods shared across multiple subclasses. Lastly, any refactored code that incorporates environmental variables will be thoroughly tested to ensure that correct values appear in place of hardcoded ones.

For integration testing, we will write tests to simulate real-world interactions between models. Furthermore, special attention will be provided to edge cases (i.e. missing data, interactions between multiple subclasses of ResponseMap, etc.) to ensure proper error handling.

Lastly, to ease the workflow process for further groups in later iterations, we will thoroughly document all test cases through comments, providing clear explanations of each test’s purpose and anticipated results.