Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:45:02Z

Psangan: /* Test Execution */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here is a code sample of a function that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

def test_end_cursor_gists(mocker):
contribution_type = 'gists'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

def test_end_cursor_issues(mocker):
contribution_type = 'issues'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

In the above code,

test_end_cursor_gists: This is a test case that is testing a function called user_contribution_type_history_page with the contribution type set to 'gists'. It uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

test_end_cursor_issues: This is another test case that is similar to the previous one, but it tests the user_contribution_type_history_page function with the contribution type set to 'issues'. It also uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

* Generating a coverage report: The pytest-cov package has been used to generate a coverage report, which provides information about the percentage of code that is covered by the current test cases. This report can help identify sections of the code that are not being exercised during testing, indicating potential gaps in test coverage.

* Identifying uncovered code sections: The coverage report generated by pytest-cov has been used to pinpoint sections of the code that are not being covered by the existing test cases. These uncovered code sections are areas of the codebase that are not executed during the current test suite, and may represent potential vulnerabilities or untested functionality.

* Introducing more test cases: In order to improve the overall test coverage and include these uncovered code sections, additional test cases have been introduced. These new test cases are designed to specifically target the areas of the code that were identified as lacking coverage in the coverage report. By adding more test cases, the goal is to thoroughly exercise the codebase and ensure that all sections of the code are tested, thereby improving the reliability and quality of the testing process.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the testing coverage. Additional test coverage is yet to be done, so the code snippets and the results will be added as the future work.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:44:33Z

Psangan: /* Test Execution */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here is a code sample of a function that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

def test_end_cursor_gists(mocker):
contribution_type = 'gists'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

def test_end_cursor_issues(mocker):
contribution_type = 'issues'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

In the above code,

test_end_cursor_gists: This is a test case that is testing a function called user_contribution_type_history_page with the contribution type set to 'gists'. It uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

test_end_cursor_issues: This is another test case that is similar to the previous one, but it tests the user_contribution_type_history_page function with the contribution type set to 'issues'. It also uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

* Generating a coverage report: The pytest-cov package has been used to generate a coverage report, which provides information about the percentage of code that is covered by the current test cases. This report can help identify sections of the code that are not being exercised during testing, indicating potential gaps in test coverage.

* Identifying uncovered code sections: The coverage report generated by pytest-cov has been used to pinpoint sections of the code that are not being covered by the existing test cases. These uncovered code sections are areas of the codebase that are not executed during the current test suite, and may represent potential vulnerabilities or untested functionality.

* Introducing more test cases: In order to improve the overall test coverage and include these uncovered code sections, additional test cases have been introduced. These new test cases are designed to specifically target the areas of the code that were identified as lacking coverage in the coverage report. By adding more test cases, the goal is to thoroughly exercise the codebase and ensure that all sections of the code are tested, thereby improving the reliability and quality of the testing process.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. Additional test coverage is yet to be done, so the code snippets and the results will be added as the future work.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:39:25Z

Psangan: /* Work Strategy */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here is a code sample of a function that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

def test_end_cursor_gists(mocker):
contribution_type = 'gists'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

def test_end_cursor_issues(mocker):
contribution_type = 'issues'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

In the above code,

test_end_cursor_gists: This is a test case that is testing a function called user_contribution_type_history_page with the contribution type set to 'gists'. It uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

test_end_cursor_issues: This is another test case that is similar to the previous one, but it tests the user_contribution_type_history_page function with the contribution type set to 'issues'. It also uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

* Generating a coverage report: The pytest-cov package has been used to generate a coverage report, which provides information about the percentage of code that is covered by the current test cases. This report can help identify sections of the code that are not being exercised during testing, indicating potential gaps in test coverage.

* Identifying uncovered code sections: The coverage report generated by pytest-cov has been used to pinpoint sections of the code that are not being covered by the existing test cases. These uncovered code sections are areas of the codebase that are not executed during the current test suite, and may represent potential vulnerabilities or untested functionality.

* Introducing more test cases: In order to improve the overall test coverage and include these uncovered code sections, additional test cases have been introduced. These new test cases are designed to specifically target the areas of the code that were identified as lacking coverage in the coverage report. By adding more test cases, the goal is to thoroughly exercise the codebase and ensure that all sections of the code are tested, thereby improving the reliability and quality of the testing process.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project.

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:39:02Z

Psangan: /* Work Strategy */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here is a code sample of a function that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

def test_end_cursor_gists(mocker):
contribution_type = 'gists'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

def test_end_cursor_issues(mocker):
contribution_type = 'issues'
init_query = {'user': {contribution_type: {'pageInfo': {'endCursor': 'mock_end_cursor'}}}}
mocker.patch('my_package.gist_issue_project_pr.get_data', return_value=init_query)
dic = gist_issue_project_pr.user_contribution_type_history_page('JialinC', contribution_type, 'mock_end_cursor')
assert list(dic['user'].keys())[1] == contribution_type

In the above code,

test_end_cursor_gists: This is a test case that is testing a function called user_contribution_type_history_page with the contribution type set to 'gists'. It uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

test_end_cursor_issues: This is another test case that is similar to the previous one, but it tests the user_contribution_type_history_page function with the contribution type set to 'issues'. It also uses the mocker fixture to mock the my_package.gist_issue_project_pr.get_data function and return a specific query result (init_query). Then, it calls the user_contribution_type_history_page function with mocked data and asserts that the contribution type in the returned dictionary (dic) matches the expected value.

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

* Generating a coverage report: The pytest-cov package has been used to generate a coverage report, which provides information about the percentage of code that is covered by the current test cases. This report can help identify sections of the code that are not being exercised during testing, indicating potential gaps in test coverage.

* Identifying uncovered code sections: The coverage report generated by pytest-cov has been used to pinpoint sections of the code that are not being covered by the existing test cases. These uncovered code sections are areas of the codebase that are not executed during the current test suite, and may represent potential vulnerabilities or untested functionality.

* Introducing more test cases: In order to improve the overall test coverage and include these uncovered code sections, additional test cases have been introduced. These new test cases are designed to specifically target the areas of the code that were identified as lacking coverage in the coverage report. By adding more test cases, the goal is to thoroughly exercise the codebase and ensure that all sections of the code are tested, thereby improving the reliability and quality of the testing process.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project.

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:35:45Z

Psangan: /* Test Plan */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here are some code samples of the functions that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

* Generating a coverage report: The pytest-cov package has been used to generate a coverage report, which provides information about the percentage of code that is covered by the current test cases. This report can help identify sections of the code that are not being exercised during testing, indicating potential gaps in test coverage.

* Identifying uncovered code sections: The coverage report generated by pytest-cov has been used to pinpoint sections of the code that are not being covered by the existing test cases. These uncovered code sections are areas of the codebase that are not executed during the current test suite, and may represent potential vulnerabilities or untested functionality.

* Introducing more test cases: In order to improve the overall test coverage and include these uncovered code sections, additional test cases have been introduced. These new test cases are designed to specifically target the areas of the code that were identified as lacking coverage in the coverage report. By adding more test cases, the goal is to thoroughly exercise the codebase and ensure that all sections of the code are tested, thereby improving the reliability and quality of the testing process.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project.

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:34:06Z

Psangan: /* Test Execution */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

The current Python project makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

== Project Description ==

=== Feature explanation - GitHub GraphQL API queries ===

GraphQL is a modern and flexible API query language that provides a more efficient and developer-friendly way to request and manipulate data from APIs compared to traditional REST APIs. This project makes use of the requests library to send requests to the GitHub GraphQL API to access user public data. We have used the pytest testing framework and the pytest-mock plugin to create tests for methods that submit requests to an API using the requests library.

=== Tasks and Goals to be accomplished : ===

We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls. The major goal is to implement the refactored existing code in the files already available in a newly cloned repository.

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Update the env file for the github token.
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

=== UML Diagram ===
This image illustrates the concept of mocking GitHub's GraphQL API using a GraphQL API mocking tool. (Please click on the image for a bigger view)

[[File:FinalProjectUmlG2334.png|1200px]]

== Work Strategy ==

To achieve the objectives, we conducted the following steps :

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

And made the following changes in the requirements.txt file to incorporate the required modules for the project :

pip install pytest-cov pytest-mock
pip freeze > requirements.txt
pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response. Please refer the below code snippet for a better understanding of the statment.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

We have implemented API mocking in a large number of methods and functions. Here are some code samples of the functions that used direct API calls and were adjusted by employing API mocking, as it is very difficult for us to list all the methods we have implemented:

Code snippet :

3. Changes in the env file :

Updating the env file is essential for providing the required environment variables and configurations for successful test execution. This includes sensitive information like API keys, access tokens, or other values that need to be set as environment variables in the env file. Additionally, the env file may contain other necessary configuration settings, such as base URLs or timeouts, specific to the testing environment. By updating the env file, you ensure that the tests can access the necessary configurations during runtime, resulting in accurate test results.

In our project, we have configured the GitHub access token. Including the GitHub token in the env file involves adding a configuration entry that specifies the token value as the corresponding environment variable. This entry typically follows a key-value format, where the key represents the name of the environment variable and the value represents the GitHub token.

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project.

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

* Refactoring of code: The code in the test_suit.py file has been refactored, which means it has been modified to improve its structure, readability, or performance. This could involve changes such as reorganizing code blocks, simplifying complex logic, removing redundant or obsolete code, or improving variable names.

* Mocking API calls: In order to obtain the desired output from methods that were originally making API calls, the real API method calls have been replaced with mocked versions. Mocking is a technique used in testing to replace actual dependencies (such as external APIs) with simulated versions that allow controlled and predictable behavior during testing. This allows the tests to be executed in isolation without relying on external services, improving test reliability and performance.

* Modification of test method names: The names of the test methods in the test_suit.py file have been modified to reflect the functionality being tested by those methods. This could involve updating the method names to accurately describe the purpose or behavior being tested, making it easier to understand the purpose of each test case. Descriptive test method names can also serve as documentation, providing insights into the expected behavior of the code being tested.

Overall, these changes indicate that the test_suit.py file has been updated to improve the structure and reliability of the tests, by mocking API calls and using descriptive test method names to clearly indicate the functionality being tested.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T03:25:49Z

2023-04-13T01:56:34Z

Psangan: Psangan uploaded a new version of File:FinalProjUml.png

uml for final project design document.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T01:56:04Z

Psangan: /* UML Diagram */

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-13T01:55:41Z

Psangan: /* UML Diagram */

File:FinalProjUml.png

2023-04-13T01:54:47Z

2023-04-12T20:05:40Z

Psangan: /* Description and Testing */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Problem Statement ==

According to the instructions, we are expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This is a Python project one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-12T02:34:39Z

Psangan: /* Project Description */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we are expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This is a Python project one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-12T02:34:06Z

Psangan: /* Description and Testing */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we are expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-11T19:37:30Z

Psangan: /* Description and Testing */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we appear to be expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Need of API Mocking :

API mocking empowers developers to exercise complete control over the behavior of the mocked API, encompassing responses, errors, and delays. This level of control facilitates precise testing scenarios, such as evaluating error handling, edge cases, or desired responses from the API. Furthermore, it enables the replication of specific scenarios during testing, simplifying the identification and resolution of issues.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-08T03:39:44Z

Psangan: /* Test Execution */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we appear to be expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

This will execute each test case and produce a report on the project's overall coverage. This report helped us identify parts of the code that the current test cases don't cover. We have developed new test cases to cover these regions once you have pointed them out. To imitate the intended behavior of external API calls and to account for both positive and negative eventualities, we used mocking.

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-08T01:40:35Z

Psangan: /* Project Description */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we appear to be expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:

1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-08T01:37:22Z

Psangan: /* Test Execution */

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we appear to be expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:
1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :

Code Snippet :
pytest --cov

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-08T01:15:25Z

Psangan:

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo (awaoo)
* Girish Wangikar (gwangik)
* Pranavi Sharma Sanganabhatla (psangan)

== Description and Testing ==

According to the instructions, we appear to be expected to work on a Python project that makes API calls to the GitHub GraphQL API using the requests package. We must rewrite the current test cases such that mocking libraries are used in place of actual API calls, and we must also add new test cases to boost the test coverage.

Tasks to be accomplished :

* Test functions should have names that are both descriptive and explicit so that it is evident what part of the system they are testing.
* Several tests in the current codebase make actual API calls as opposed to using mock calls. Make mock test calls from these tests.
* Change the requirements.txt file to reflect the newly installed packages (pytest-cov and pytest-mock).
* Get the code fully tested.

=== Files Involved ===

* test_suit.py
* requirements.txt
* env file

== Project Description ==

This project appears to be a Python one that uses the requests library to perform API calls to the GitHub GraphQL API, based on the instructions that were supplied. We are tasked with increasing the test coverage by introducing new test cases, as well as restructuring the current test cases to use mocking libraries rather than actual API calls.

The task is to refactor the existing code present in the test_suit.py and implement them in a newly forked repository.

We took the next actions to accomplish this:
1. Use the command below to install the packages pytest-cov and pytest-mock:

Code Snippet :

pip install pytest-cov pytest-mock

This will set up the packages your project needs for code coverage and mocking.

2. All test cases that use function B, which makes a genuine API call, have been refactored so that mocking is used in place of calling. Create a mock version of function B using the mocker.patch function offered by pytest-mock, and set the mock function's return value to the expected API response.

Code Snippet :

def function_b():
response = requests.get('https://api.example.com/data')
return response.json()
def function_a():
data = function_b()
# do something with the data
return data
def test_function_a(mocker):
mock_function_b = mocker.patch('_main_.function_b')
mock_function_b.return_value = {'foo': 'bar'}
result = function_a()
assert result == {'foo': 'bar'}
mock_function_b.assert_called_once()

== Test Plan ==

The pytest-cov package has been used to generate a coverage report and to pinpoint sections of the code that are not being covered by the current test cases. Next, in order to better the overall test coverage and include these areas, we introduced more test cases.

=== Test Execution ===

We divided the work among the teammates and started working on different parts of the project. To generate a coverage report, run the following command :
pytest --cov

== Conclusion ==

The code in the test suit.py file has been refactored. In order to get the desired output from the methods that were using API calls, we mocked the real API method calls that were made internally. We also modified the names of all the test methods to match the functionality carried out by the methods.

CSC/ECE 517 Spring 2023 - G2334 Develop and refactor test suite for GraphQL Query

2023-04-08T01:13:26Z

CSC/ECE 517 Spring 2023 - E2333. Generalize review versioning

2023-04-07T23:41:35Z

Psangan:

CSC/ECE 517 Spring 2023 - E2333. Generalize review versioning

2023-04-07T23:28:17Z

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo
* Girish Wangikar
* Pranavi Sharma Sanganabhatla

== Description and Testing ==
Our project deals with refactoring the answer.rb file. The code is responsible for doing the following tasks:
* To design and implement an answsers_by_response method that returns answers in each response.
* Get the answer model fully tested.

=== Files Involved ===

* answer.rb
* answer_spec.rb

=== Running Tests ===
To successfully run answer_spec on the local machine, please run the below rspec command.
<pre>
rspec spec/answer_spec.rb
</pre>

== Project Description ==

The objective of the project is to refactor the following Ruby on Rails model classes in the existing project:- Answer Model on Expertiza.The model is designed to represent answers to questions in Expertiza. So, whenever anyone fills out a rubric, each “question” that is answered creates a new Answer object.

The task is to refactor the existing code present in the model file and implement them in a new repository. Since the project is implemented from scratch, there are various aspects of the project that have to be implemented and therefore unit test cases are implemented to test the implementation.

* answers_by_question_for_reviewee_in_round:
1. This method joins the responses, answers, response_maps, and questions table.
2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id, q_id, and round parameters.
3. It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question_for_reviewee_in_round, -> (assignment_id, reviewee_id, q_id, round) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
review_maps.reviewee_id = ? AND
answers.question_id = ? AND
responses.round = ?", assignment_id, reviewee_id, q_id, round)
.select(:answer, :comments)
end

* answers_by_question:
1. This method joins the questions, answers, responses, and response_maps table.
2. Then it applies a where clause to filter the results based on the given q_id and assignment_id.
3. It retrieves the distinct answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

* answers_by_question:
1. This method joins the responses, answers, response_maps, and questions table.
2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id and q_id.
3. It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

== Test Plan ==

We have implemented test cases using RSpec for different validation checks for answer.rb.

Code Snippet:

require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/rails_helper.rb'
require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/spec_helper.rb'

RSpec.describe Answer, type: :model do
describe ".by_question_for_reviewee_in_round" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:round) { 1 }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map, round: round) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question, reviewee, assignment, and round" do
expect(Answer.by_question_for_reviewee_in_round(assignment.id, reviewee.id, question.id, round))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_question" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question and assignment" do
expect(Answer.by_question(assignment.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_question_for_reviewee" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question, reviewee, and assignment" do
expect(Answer.by_question_for_reviewee(assignment.id, reviewee.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_response" do
let(:response) { create(:response) }
let!(:answer) { create(:answer, response: response) }
it "returns the answer for the specified response" do
expect(Answer.by_response(response.id)).to eq([answer.answer])
end
end
end

=== Test Execution ===
We divided the work among the teammates and started tackling the problems. We stubbed the data using the factory and mocked the method calls which were being done internally to get the desired output from the methods that were calling other methods internally.

=== Conclusion ===
We have refactored the code in the answer.rb file to return answers in each response. We have tested the model fully and attaching the video of the passed test cases in the submission.

CSC/ECE 517 Spring 2023 E2310

2023-03-23T03:10:42Z

Psangan:

== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an assignment/project management portal that can be used by both instructors and students for collaborative learning and feedback. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo
* Girish Wangikar
* Pranavi Sharma Sanganabhatla

== Description and Testing ==
Our project deals with refactoring the answer.rb file. The code is responsible for doing the following tasks:
* To design and implement an answsers_by_response method that returns answers in each response.
* Get the answer model fully tested.

=== Files Involved ===

* answer.rb
* answer_spec.rb

=== Running Tests ===
To successfully run answer_spec on the local machine, please run the below rspec command.
<pre>
rspec spec/answer_spec.rb
</pre>

== Project Description ==

The objective of the project is to refactor the following Ruby on Rails model classes in the existing project:- Answer Model on Expertiza.The model is designed to represent answers to questions in Expertiza. So, whenever anyone fills out a rubric, each “question” that is answered creates a new Answer object.

The task is to refactor the existing code present in the model file and implement them in a new repository. Since the project is implemented from scratch, there are various aspects of the project that have to be implemented and therefore unit test cases are implemented to test the implementation.

* answers_by_question_for_reviewee_in_round:
1. This method joins the responses, answers, response_maps, and questions table.
2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id, q_id, and round parameters.
3. It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question_for_reviewee_in_round, -> (assignment_id, reviewee_id, q_id, round) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
review_maps.reviewee_id = ? AND
answers.question_id = ? AND
responses.round = ?", assignment_id, reviewee_id, q_id, round)
.select(:answer, :comments)
end

* answers_by_question:
1. This method joins the questions, answers, responses, and response_maps table.
2. Then it applies a where clause to filter the results based on the given q_id and assignment_id.
3. It retrieves the distinct answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

* answers_by_question:
1. This method joins the responses, answers, response_maps, and questions table.
2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id and q_id.
3. It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

== Test Plan ==

We have implemented test cases using RSpec for different validation checks for answer.rb.

Code Snippet:

require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/rails_helper.rb'
require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/spec_helper.rb'

RSpec.describe Answer, type: :model do
describe ".by_question_for_reviewee_in_round" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:round) { 1 }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map, round: round) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question, reviewee, assignment, and round" do
expect(Answer.by_question_for_reviewee_in_round(assignment.id, reviewee.id, question.id, round))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_question" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question and assignment" do
expect(Answer.by_question(assignment.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_question_for_reviewee" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }
it "returns the answer and comments for the specified question, reviewee, and assignment" do
expect(Answer.by_question_for_reviewee(assignment.id, reviewee.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_response" do
let(:response) { create(:response) }
let!(:answer) { create(:answer, response: response) }
it "returns the answer for the specified response" do
expect(Answer.by_response(response.id)).to eq([answer.answer])
end
end
end

=== Test Execution ===
We divided the work among the teammates and started tackling the problems. We stubbed the data using the factory and mocked the method calls which were being done internally to get the desired output from the methods that were calling other methods internally.

=== Conclusion ===
We have refactored the code in the answer.rb file to return answers in each response. We have tested the model fully and attaching the video of the passed test cases in the submission.

2023-03-23T02:10:29Z

Psangan:

== About Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is an assignment/project management portal that can be used by both instructors and students for collaborative learning and feedback. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Team==
=== Mentor ===

* Jialin Cui

=== Team Members ===

* Aman Waoo
* Girish Wangikar
* Pranavi Sharma Sanganabhatla

== Description and Testing ==
Our project deals with refactoring the answer.rb file. The code is responsible for doing the following tasks:
* To design and implement an answsers_by_response method that returns answers in each response.
* Get the answer model fully tested.

=== Files Involved ===

* answer.rb
* answer_spec

=== Running Tests ===
To successfully run answer_spec on the local machine, please run the below rspec command.
<pre>
rspec spec/answer_spec.rb
</pre>

== Project Description ==

The objective of the project is to refactor the following Ruby on Rails model classes in the existing project:- Answer Model on Expertiza.The model is designed to represent answers to questions in Expertiza. So, whenever anyone fills out a rubric, each “question” that is answered creates a new Answer object.

The task is to refactor the existing code present in the model file and implement them in a new repository. Since the project is implemented from scratch, there are various aspects of the project that have to be implemented and therefore unit test cases are implemented to test the implementation.

* answers_by_question_for_reviewee_in_round:
1. This method joins the responses, answers, response_maps, and questions table.
2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id, q_id, and round parameters.
3. It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question_for_reviewee_in_round, -> (assignment_id, reviewee_id, q_id, round) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
review_maps.reviewee_id = ? AND
answers.question_id = ? AND
responses.round = ?", assignment_id, reviewee_id, q_id, round)
.select(:answer, :comments)
end

* answers_by_question:
This method joins the questions, answers, responses, and response_maps table.
Then it applies a where clause to filter the results based on the given q_id and assignment_id.
It retrieves the distinct answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

* answers_by_question:
This method joins the responses, answers, response_maps, and questions table.
Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id and q_id.
It retrieves answers and comments columns from the combined table.

Code Snippet:

scope :by_question, -> (assignment_id, q_id) do
joins(response: {map: :reviewer})
.joins(:question)
.where("review_maps.reviewed_object_id = ? AND
answers.question_id = ?", assignment_id, q_id)
.select(:answer, :comments)
.distinct
end

== Test Plan ==

We have implemented test cases using RSpec for different validation checks for answer.rb.

Code Snippet:

require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/rails_helper.rb'
require '/Users/aw/Documents/Course Study Material/OODD/Program 3/spec/spec_helper.rb'

RSpec.describe Answer, type: :model do
describe ".by_question_for_reviewee_in_round" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:round) { 1 }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map, round: round) }
let!(:answer) { create(:answer, question: question, response: response) }

it "returns the answer and comments for the specified question, reviewee, assignment, and round" do
expect(Answer.by_question_for_reviewee_in_round(assignment.id, reviewee.id, question.id, round))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

describe ".by_question" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }

it "returns the answer and comments for the specified question and assignment" do
expect(Answer.by_question(assignment.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

Code Snippet:

describe ".by_question_for_reviewee" do
let(:assignment) { create(:assignment) }
let(:reviewer) { create(:user) }
let(:reviewee) { create(:user) }
let(:question) { create(:question, assignment: assignment) }
let(:response_map) { create(:review_map, reviewed_object: assignment, reviewer: reviewer, reviewee: reviewee) }
let(:response) { create(:response, map: response_map) }
let!(:answer) { create(:answer, question: question, response: response) }

it "returns the answer and comments for the specified question, reviewee, and assignment" do
expect(Answer.by_question_for_reviewee(assignment.id, reviewee.id, question.id))
.to match_array([{answer: answer.answer, comments: answer.comments}])
end
end

Code Snippet:

describe ".by_response" do
let(:response) { create(:response) }
let!(:answer) { create(:answer, response: response) }

it "returns the answer for the specified response" do
expect(Answer.by_response(response.id)).to eq([answer.answer])
end
end
end

=== Test Execution ===
We divided the work among the teammates and started tackling the problems. We stubbed the data using the factory and mocked the method calls which were being done internally to get the desired output from the methods that were calling other methods internally.

***Not Sure***

=== Test Coverage ===
The summary helper spec file is newly created. This project increased testing coverage by 72.86% according to simplecov test.
[[File:test_coverage.png]]

***Not Sure***

***Not Sure***
== Future Plan ==

The future scope of this project is to implement waitlist.rb model class that handles the functions related to adding/removing sign up teams to the waitlist for each topic. There are other instance methods in both sign_up_team.rb and sign_up_topic.rb that requires implementation. But, since they are dependent on other model classes, we have added them to our TODO list to implement them in the future.

***Not Sure***

=== Conclusion ===
We have refactored the code in the answer.rb file to return answers in each response. We have tested the model fully and attaching the video of the test cases in the submission.