Expertiza_Wiki - User contributions [en]

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-11T01:51:16Z

Rdmarshb: /* Proposed Import Changes */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. However, these functions might be deprecated, as it appears that Question importing is now routed through the ImportFileController unsuccessfully. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper (Appears to be deprecated/unused)

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper''' (Appears to be deprecated/unused)
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.
* Add ability for ImportFileController to import Question objects for Questionnaires. (Add question view to views/import_file, introduce Question logic into the controller.)
** Note: Why does QuizQuestionnaire have a different view?

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

*Username: instructor6
*Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T17:01:55Z

Rdmarshb: /* Existing Import Functionality */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. However, these functions might be deprecated, as it appears that Question importing is now routed through the ImportFileController unsuccessfully. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper (Appears to be deprecated/unused)

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper''' (Appears to be deprecated/unused)
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.
* Add ability for ImportFileController to import Question objects for Questionnaires. (Add question view to views/import_file, introduce Question logic into the controller.)

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

*Username: instructor6
*Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T16:54:00Z

Rdmarshb: /* Proposed Import Changes */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. However, these functions might be deprecated, as it appears that Question importing is now routed through the ImportFileController unsuccessfully. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.
* Add ability for ImportFileController to import Question objects for Questionnaires. (Add question view to views/import_file, introduce Question logic into the controller.)

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

*Username: instructor6
*Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T16:52:52Z

Rdmarshb: /* Existing Import Functionality */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. However, these functions might be deprecated, as it appears that Question importing is now routed through the ImportFileController unsuccessfully. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

*Username: instructor6
*Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T16:24:57Z

Rdmarshb: /* Deployment */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

*Username: instructor6
*Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T16:24:35Z

Rdmarshb: /* Deployment */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:

Username: instructor6

Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T16:23:30Z

Rdmarshb:

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

== Deployment ==

The project is deployed on an NCSU VCL server. It can be accessed at http://152.46.16.252:8080/.

A sample instructor login is:
Username: instructor6
Password: password

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:36:20Z

Rdmarshb:

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Description of Project ==

What it does: The export/import feature is the most helpful feature for instructors to set up assignments. The instructors usually have a list of students, teams, etc from their learning management system. Being able to export/import these into expertiza saves a lot of time when setting up an assignment.

What should be done: Expertiza provides multiple export and import features for eg. export students, teams etc. Essentially what it does is it fetches some data from database and save it as a file in desired format. However, same functionality is implemented multiple times for exporting and importing different things. The aim of this project is to design a generic export/import feature. What you need to do is implement a framework which supports exporting and importing functionality based on input. There are substantial degrees of freedom in this project. You need to design the module which will take the database table names, column names from which data needs to be exported or the imported into. So that this module can be used for every export/import feature that expertiza provides.
Most imports and exports just import or export a single table. But sometimes exports involve “details.” For example, when questionnaires are imported or exported, the “advice” (guidelines on what characteristics of work merit each score) may be imported or exported along with the questionnaire. I suspect that all instances of import/export of multiple tables are called “details” in the current code. Provide a mechanism so that “details” can be imported or exported along with the main table involved.

== Existing Import Functionality ==

Existing import functionality is primarily routed through the import_file_controller and an import class method for various models. Two models, SignUpTopic and User, rely on helper classes that extract attributes from a hash and create an ActiveRecord object. Additionally, Questionnaire relies on a helper that can import Question objects from a CSV and adjust the size of the associated QuestionAdvice. More detail about specific functions is provided below.

=== Controllers ===
*'''import_file_controller'''
** File processing methods:
*** #get_delimiter - Sets proper delimiter for filetype
*** #parse_line - Processes line (row) of the file
*** #parse_to_grid - Turns file into 2D array
*** #parse_to_hash - Turns file into hash where 'header' stores header row and 'body' stores all contents.
*** #hash_rows_with_headers - Creates hash for each row of file. Keys are headers, values are row values.
** Import methods:
*** #import_from_hash - Primary import functionality. Creates objects for hashed rows (from #hash_rows_with_headers).
*** #import - Larger controller of import, sets error messages and displays.

*'''questionnaires_controller'''
** ::import - Allows import from CSV using QuestionnaireHelper

=== Helpers ===
*'''import_file_helper'''
** ::define_attributes - Sets and returns attributes for User object from hash.
** ::create_new_user - Makes a user object in the database.

*'''import_topics_helper'''
** ::define_attributes - Sets and returns attributes for a SignUpTopic from hash.
** ::create_new_sign_up_topic - Makes SignUpTopic objects in the database.

*'''questionnaire_helper'''
** ::get_questions_from_csv - Allows Question and QuestionAdvice import/creation with CSV file.

=== Models ===

All models have an ::import method called by the ImportFileController. In addition, SignUpTopic and User objects rely on their helpers, which are mentioned above.

*'''assignment_participant'''
*'''assignment_team'''
*'''course_participant'''
*'''course_team'''
*'''team'''
*'''metareview_response_map'''
*'''question'''
*'''review_response_map'''
*'''sign_up_sheet'''
*'''sign_up_topic'''
*'''user'''

== Proposed Import Changes ==

Most import functionality is routed through the ImportFileController and import class methods on models that are being imported. We intend to remove other helpers and files, such as the ImportFileHelper, the ImportTopicHelper, and the QuestionnaireHelper to keep import routing consistent. We will also remove the QuestionnaireController and route that import through the ImportFileController. In addition, we will update ImportFileController methods (in particular, #hash_rows_with_headers and #import_from_hash) to make better use of polymorphism and eliminate large and unnecessary if/else blocks.

We will also insert more specific object creation specifications. Consider if a user's import contains objects that do not exist in the database. We will provide an option for the user to specify whether or not new/dependent objects should be created and account for this boolean in relevant ::import functions for the models.

To summarize our changes:

* Route all import traffic through ImportFileController and ::import calls on models.
* Refactor ImportFileController.
* Insert object creation conditions into all relevant ::import functions and into the ImportFileController form.

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:18:40Z

Rdmarshb: /* Existing Import Functionality */

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:18:09Z

Rdmarshb: /* Existing Import Functionality */

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:16:06Z

Rdmarshb: /* Existing Import Functionality */

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:12:43Z

Rdmarshb: /* Existing Import Functionality */

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T14:05:45Z

Rdmarshb: /* Existing Import Functionality */

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-07T13:47:27Z

Rdmarshb:

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-05T14:32:31Z

Rdmarshb: /* Team */

== Project Introduction ==
=== Team ===
*Veeha Khanna, vkhanna
*Randy Paluszkiewicz, rpalusz
*Drew Marshburn, rdmarshb
*Andrew Miller, asmille5

== Proposed Design ==

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-05T14:30:56Z

Rdmarshb: /* Team */

== Project Introduction ==
=== Team ===
Veeha Khanna, vkhanna

Rpalusz rpalusz

Drew Marshburn, rdmarshb

Andrew Miller, asmille5

== Proposed Design ==

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-05T14:30:46Z

Rdmarshb: /* Team */

== Project Introduction ==
=== Team ===
Veeha Khanna, vkhanna
Rpalusz rpalusz
Drew Marshburn, rdmarshb
Andrew Miller, asmille5

== Proposed Design ==

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-05T14:27:43Z

Rdmarshb:

== Project Introduction ==
=== Team ===

== Proposed Design ==

CSC517 Spring 2019/E1923 New Framework For Import/Export

2019-04-05T14:27:04Z

Rdmarshb: Created page with " === Team === === Proposed Design ==="

=== Team ===

=== Proposed Design ===

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T14:53:00Z

Rdmarshb: /* Results */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

We made one change to the factory.rb file to build an instance of Team. We assume that the Team class may be used in other tests globally, so this should be added to the factory file and thus can be built more easily in future tests. Our addition to the factory.rb file is:

<pre>
factory :team, class: Team do
id 1
parent_id 1
end
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following section shows the Rspec outline of the tests we created. The full test code can be found [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Check action permission with four different roles.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Get feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
get the result
</pre>

Get response stats when the response map exists, otherwise only find the team and users.

<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Calculate scores depending on the existence of the response. If a review questionnaire is present, calculate scores with a max.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

All tone analysis tests are run together. Both popup_* methods set instance variables before calling a build_* method. build_* methods are responsible for actually creating tone analysis tests and returning JSON information/graphics.

<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#view_review_scores_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
answer is provided
build tone analysis report
answer is not provided
build tone analysis report
#build_tone_analysis_heatmap
sentiment is empty
build tone analysis heatmap

</pre>

Test showing details about the reviewer.

<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get reviews done by self.

<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41%, meeting our coverage requirement.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested in each 'describe'. In addition, we used the Byebug gem to debug our test code.
The key to building successful tests is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T14:47:31Z

Rdmarshb: /* Test Outline */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

We made one change to the factory.rb file to build an instance of Team. We assume that the Team class may be used in other tests globally, so this should be added to the factory file and thus can be built more easily in future tests. Our addition to the factory.rb file is:

<pre>
factory :team, class: Team do
id 1
parent_id 1
end
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following section shows the Rspec outline of the tests we created. The full test code can be found [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Check action permission with four different roles.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Get feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
get the result
</pre>

Get response stats when the response map exists, otherwise only find the team and users.

<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Calculate scores depending on the existence of the response. If a review questionnaire is present, calculate scores with a max.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

All tone analysis tests are run together. Both popup_* methods set instance variables before calling a build_* method. build_* methods are responsible for actually creating tone analysis tests and returning JSON information/graphics.

<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#view_review_scores_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
answer is provided
build tone analysis report
answer is not provided
build tone analysis report
#build_tone_analysis_heatmap
sentiment is empty
build tone analysis heatmap

</pre>

Test showing details about the reviewer.

<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get reviews done by self.

<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T14:46:47Z

Rdmarshb: /* Test Outline */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

We made one change to the factory.rb file to build an instance of Team. We assume that the Team class may be used in other tests globally, so this should be added to the factory file and thus can be built more easily in future tests. Our addition to the factory.rb file is:

<pre>
factory :team, class: Team do
id 1
parent_id 1
end
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following section shows the Rspec outline of the tests we created. The full test code can be found [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Check action permission with four different roles.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
get the result
</pre>

Get response stats when the response map exists, otherwise only find the team and users.

<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Calculate scores depending on the existence of the response. If a review questionnaire is present, calculate scores with a max.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

All tone analysis tests are run together. Both popup_* methods set instance variables before calling a build_* method. build_* methods are responsible for actually creating tone analysis tests and returning JSON information/graphics.

<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#view_review_scores_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
answer is provided
build tone analysis report
answer is not provided
build tone analysis report
#build_tone_analysis_heatmap
sentiment is empty
build tone analysis heatmap

</pre>

Test showing details about the reviewer.

<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get reviews done by self.

<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T14:46:34Z

Rdmarshb: /* Test Outline */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

We made one change to the factory.rb file to build an instance of Team. We assume that the Team class may be used in other tests globally, so this should be added to the factory file and thus can be built more easily in future tests. Our addition to the factory.rb file is:

<pre>
factory :team, class: Team do
id 1
parent_id 1
end
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following section shows the Rspec outline of the tests we created. The full test code can be found in [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Check action permission with four different roles.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
get the result
</pre>

Get response stats when the response map exists, otherwise only find the team and users.

<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Calculate scores depending on the existence of the response. If a review questionnaire is present, calculate scores with a max.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

All tone analysis tests are run together. Both popup_* methods set instance variables before calling a build_* method. build_* methods are responsible for actually creating tone analysis tests and returning JSON information/graphics.

<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#view_review_scores_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
answer is provided
build tone analysis report
answer is not provided
build tone analysis report
#build_tone_analysis_heatmap
sentiment is empty
build tone analysis heatmap

</pre>

Test showing details about the reviewer.

<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get reviews done by self.

<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T13:27:15Z

Rdmarshb: /* Test Plan */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

We made one change to the factory.rb file to build an instance of Team. We assume that the Team class may be used in other tests globally, so this should be added to the factory file and thus can be built more easily in future tests. Our addition to the factory.rb file is:

<pre>
factory :team, class: Team do
id 1
parent_id 1
end
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following sections show the Rspec outline of the tests we created. The whole test code can be found in [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Use four different roles to go into the method.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
</pre>

Get response when the response map exists.
<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Show different score when the reponse exists or not.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

Test all tone analysis related test together.
<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
upon selecting summery, the tone analysis for review comments is calculated and applied to the page
builds a tone analysis report and returns the heat map URLs
#view_review_scores_popup
prepares tone analysis report for building
#build_tone_analysis_report
when answer not exists
return answer is none
when answer exists
return answer
#build_tone_analysis_heatmap
test some constant value
</pre>

Test the review details.
<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get sef review.
<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T13:22:50Z

Rdmarshb: /* Test Plan */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====Popup Controller Methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====Mock Models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models. This factory can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here]. As you can see from our setup below, most of the objects we created relied on the factory with the exception of the final_versions array, which is not used in enough tests to warrant its own factory statement. Other objects are just built with additional/overwritten attributes, such as the student object.
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

====Test Frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following sections show the Rspec outline of the tests we created. The whole test code can be found in [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Use four different roles to go into the method.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
</pre>

Get response when the response map exists.
<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Show different score when the reponse exists or not.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

Test all tone analysis related test together.
<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
upon selecting summery, the tone analysis for review comments is calculated and applied to the page
builds a tone analysis report and returns the heat map URLs
#view_review_scores_popup
prepares tone analysis report for building
#build_tone_analysis_report
when answer not exists
return answer is none
when answer exists
return answer
#build_tone_analysis_heatmap
test some constant value
</pre>

Test the review details.
<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get sef review.
<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T13:19:37Z

Rdmarshb: /* Test Plan */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we wrote tests to cover all 10 methods in the popup controller. We mocked many different objects involved in the controller.

====popup controller methods====

The code of the controller can be found [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]. The methods are:

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====mock models====
Based on the controller, we mocked models to test different conditions. Models have complex and interdependent relationships, but the Expertiza project already includes a factory to build many of the models that can be seen [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here]. Additional database information can be accessed [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here].
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

====test frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following sections show the Rspec outline of the tests we created. The whole test code can be found in [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Use four different roles to go into the method.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
</pre>

Get response when the response map exists.
<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Show different score when the reponse exists or not.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

Test all tone analysis related test together.
<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
upon selecting summery, the tone analysis for review comments is calculated and applied to the page
builds a tone analysis report and returns the heat map URLs
#view_review_scores_popup
prepares tone analysis report for building
#build_tone_analysis_report
when answer not exists
return answer is none
when answer exists
return answer
#build_tone_analysis_heatmap
test some constant value
</pre>

Test the review details.
<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get sef review.
<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-31T13:15:51Z

Rdmarshb: /* What needs to be done */

The goal of this project was to add testing for the PopupController to raise statement coverage above 90%. See the Test Outline section for specifics of our work.

== Project Introduction ==
The PopupController is responsible for preparing data that will be displayed in popup views. To render the data, which mostly concerns assignments, the controller makes many accesses to database tables such as Response, ResponseMap, Question, Questionnaire, Answer, and Participant. Before our project, there were only two tests implemented that together only achieved a statement coverage of 7%. Our changes have brought the statement coverage to 96%.

=== Team ===
Zhewei Hu, zhu6 (mentor)

*Yuhan Chen, ychen239

*Hao Lu, hlu6

*Drew Marshburn, rdmarshb

=== Files Involved ===

popup_controller.rb

popup_controller_spec.rb

=== Running Tests ===
What we need to do is to set up the environment and complete the 'popup_controller_spec.rb' to finish the integration tests for popup controller. This rspec test file can be run by calling the following code:
<pre>
rspec spec/controllers/popup_controller_spec.rb
</pre>

===What needs to be done===
1.Write RSpec integration tests to make the statement coverage above 90%.

2.Cover as many edge cases as you can.

3.Achieve as high branch coverage as you can. Teaching staff will use the mutant-rspec gem to measure test thoroughness and fault-finding capability of tests.

== Test Plan ==
In total, we write tests to cover all 10 methods in popup controller. We mock several different roles involved in the controller.

====popup controller methods====

The code of the controller can be found in [https://github.com/YChen239/expertiza/blob/master/app/controllers/popup_controller.rb here]

*action_allowed?
*author_feedback_popup
*team_users_popup
*participants_popup
*tone_analysis_chart_popup
*view_review_scores_popup
*build_tone_analysis_report
*build_tone_analysis_heatmap
*reviewer_details_popup
*self_review_popup

====mock models====
Base on the controller, we mock several models to test different conditions. Each model has different relationship with each other and we can see the factory in [https://github.com/expertiza/expertiza/blob/master/spec/factories/factories.rb here] and DB [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables here].
<pre>
let(:assignment_team) { build(:assignment_team, id: 1, name: "team1", assignment: assignment) }
let(:team) {build(:team)}
let(:team_user) {build(:team_user)}
let(:student) { build(:student, id: 1, name: "student") }
let(:student2) { build(:student, id: 2, name: "student2") }
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor) }
let(:ta) { build(:teaching_assistant) }
let(:participant) { build(:participant, id: 1, user_id: 1, user: student, assignment: assignment) }
let(:participant2) { build(:participant, id: 2, user: student2, assignment: assignment) }

let(:response) { build(:response, id: 1) }
let(:questionnaire) { build(:questionnaire, id: 1, max_question_score: 15)}
let(:question) { build(:question, id: 1, questionnaire_id: questionnaire.id)}
let(:answer) { build(:answer, id: 1, question_id: question.id, response_id: response.id, answer: 10) }

let(:assignment) { build(:assignment, id: 1) }
let(:response_map) { build(:review_response_map, id: 1, reviewee_id: assignment_team.id, reviewer_id: participant2.id, response: [response], assignment: assignment) }
let(:final_versions) {{
review_round_one: {questionnaire_id: 1, response_ids: [1]},
review_round_two: {questionnaire_id: 2, response_ids: [2]},
review_round_three: {questionnaire_id: 3, response_ids: [3], }
}}

test_url = "http://peerlogic.csc.ncsu.edu/reviewsentiment/viz/478-5hf542"
mocked_comments_one = OpenStruct.new(comments: "test comment")
</pre>

====test frame====
Since it's integration test, we need to test basic logic and return value in both methods in the controller and related methods in the controller. However, some of the methods have been tested in other rspec, all we need to do is to test the methods that haven't been tested. For 'action_allowed?', 'author_feedback_popup', 'team_users_popup', 'participants_popup', 'reviewer_details_popup', 'self_review_popup' methods, we test it separately. With 'tone_analysis_chart_popup', 'view_review_scores_popup', 'build_tone_analysis_report', 'build_tone_analysis_heatmap', we test them together since they both need to get each assignment'answer. Also 'tone_analysis_chart_popup' and 'view_review_scores_popup' all get 'build_tone_analysis_report' and 'build_tone_analysis_heatmap' in their method.

== Test Outline ==

The following sections show the Rspec outline of the tests we created. The whole test code can be found in [https://github.com/YChen239/expertiza/blob/master/spec/controllers/popup_controller_spec.rb here]

'''PopupController'''

Use four different roles to go into the method.

<pre>
#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action
</pre>

Ger feedback when feedback exists.

<pre>
#author_feedback_popup
when response_id exists
</pre>

Get response when the response map exists.
<pre>
#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users
</pre>

Show different score when the reponse exists or not.

<pre>
#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max
</pre>

Test all tone analysis related test together.
<pre>
tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
upon selecting summery, the tone analysis for review comments is calculated and applied to the page
builds a tone analysis report and returns the heat map URLs
#view_review_scores_popup
prepares tone analysis report for building
#build_tone_analysis_report
when answer not exists
return answer is none
when answer exists
return answer
#build_tone_analysis_heatmap
test some constant value
</pre>

Test the review details.
<pre>
#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details
</pre>

Get sef review.
<pre>
#self_review_popup
when response_id exists
get the result
</pre>

== Results ==
The total coverage of the test is 96.41% which meets the requirment.

=== Related Links===

A video of all tests running can be seen [https://www.youtube.com/watch?v=G-e0onrIy3M&feature=youtu.be here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/YChen239/expertiza here]

===Conclusion===

The testing framework in the assignment_team_spec.rb used integration tests to test the methods in the controller. The mock instances are created at the beginning and the method logic is tested the each 'require'. For 'context', it gives the conditions for each test and for 'it'. For it, it excutes the code. For 'get', it goes through the whole method. Besides, we use gem 'byebug' to debug our test code.
In building the test framework, the key is to understand the logic in the method and understand the input and output value for the method.

CSC/ECE 517 Spring 2019 - Project E1921. Write tests for popup controller.rb

2019-03-26T00:55:24Z

Rdmarshb: /* Project Introduction */

E1921 Write tests for popup controller.rb

2019-03-25T20:32:13Z

Rdmarshb: /* Team */

E1921 Write tests for popup controller.rb

2019-03-25T20:32:01Z

Rdmarshb: /* Team */

E1921 Write tests for popup controller.rb

2019-03-24T22:47:14Z

Rdmarshb: Added introduction

E1921 Write tests for popup controller.rb

2019-03-24T22:34:45Z

Rdmarshb: Added outline and test outline

== Project Introduction ==

=== Team ===

=== File and Running Tests ===

== Design ==

== Test Outline ==

The following sections show the Rspec outline of the tests we created.

'''PopupController'''

#action_allowed?
when the role current user is student
does not allow certain action
when the role current user is ta
allows certain action
when the role name of current user is super admin or admin
allows certain action
when the role current user is super instructor
allows certain action

#author_feedback_popup
when response_id exists

#team_users_popup
when a response map exists
calculates response stats for one response
when a response map does not exist
finds team and users

#participants_popup
called with no response
does not calculate scores
called with a response
assignment has a review questionnaire
calculates the scores with a max
assignment has no review questionnaire
calculates the scores without a max

tone analysis tests
#tone_analysis_chart_popup
review tone analysis is calculated
prepares tone analysis report for building
#build_tone_analysis_report
upon selecting summery, the tone analysis for review comments is calculated and applied to the page
builds a tone analysis report and returns the heat map URLs
#view_review_scores_popup
prepares tone analysis report for building

#reviewer_details_popup
it will show the reviewer details
it will show the reviewer details

#self_review_popup
when response_id exists
get the result

== Results ==