ContactManager: Endpoint & DB Operation Functionality Verification

by Alex Johnson 67 views

Ensuring the robust functionality of your application's endpoints and database interactions is crucial for maintaining reliability and data integrity. This article provides a comprehensive guide on testing the fundamental operations of ContactManager, a Spring Boot application leveraging JOOQ and a repository for data management. By systematically verifying each endpoint and database interaction, you can identify potential issues early and ensure your application performs as expected.

Goal: Comprehensive Functionality Testing

The primary goal is to thoroughly test the basic functionality of the ContactManager application. This includes verifying the behavior of key endpoints and ensuring that database operations are performed correctly. By following a structured testing approach, we can identify and address potential issues early in the development process, leading to a more stable and reliable application. The following sections detail the specific test points and steps involved in this process.

Scope of Endpoints

The testing will focus on the following endpoints:

  • GET /home
  • GET /addUser
  • GET /contacts

Each of these endpoints plays a critical role in the application's functionality, and verifying their behavior is essential. The GET /home endpoint typically serves as the application's entry point, while GET /addUser is responsible for adding new contacts, and GET /contacts retrieves the contact list. Testing these endpoints thoroughly ensures that the core features of the application are working as intended.

Test Points: A Step-by-Step Verification

To ensure comprehensive testing, we will cover the following key test points:

1. Verifying the /home Endpoint

The GET /home endpoint should return an HTTP 200 status code, indicating a successful request. Additionally, the response body must contain the exact text: "Welcome to Contact Manager!". This test verifies the basic accessibility and functionality of the application's entry point.

  • Expected Result: HTTP 200 status code with the exact text "Welcome to Contact Manager!"
  • Verification Steps:
    1. Send a GET request to the /home endpoint.
    2. Check the HTTP status code to ensure it is 200.
    3. Examine the response body to confirm it contains the expected text.

2. Testing the /addUser Endpoint (Initial Call)

The first call to the GET /addUser endpoint should return an HTTP 200 status code. More importantly, a new record should be created in the database, specifically in the person table. The record should contain the details provided in the test case (e.g., Jana Nová, Plzen, tel. 135). This test verifies the ability to add new contacts to the database.

  • Expected Result: HTTP 200 status code and a new record in the person table.
  • Verification Steps:
    1. Send a GET request to the /addUser endpoint.
    2. Check the HTTP status code to ensure it is 200.
    3. Query the person table in the database to verify the new record's creation with the correct details (Jana Nová, Plzen, tel. 135).

3. Handling Duplicates with /addUser (Repeated Calls)

Repeated calls to the GET /addUser endpoint help to verify the application's behavior when handling duplicate entries. We need to determine whether the application creates additional identical records or prevents duplication. The test should also record the number of rows in the person table before and after the repeated calls to understand how the database is affected.

  • Expected Result: Determine if duplicates are allowed or blocked and record the number of rows in the person table.
  • Verification Steps:
    1. Send multiple GET requests to the /addUser endpoint with the same data.
    2. Check the database after each call to see if new records are created or if duplication is prevented.
    3. Record the number of rows in the person table before and after the calls.
    4. Analyze the application's behavior regarding duplicate entries.

4. Validating the /contacts Endpoint

The GET /contacts endpoint should return an HTTP 200 status code, indicating a successful retrieval of contacts. It is also essential to verify the logging of the displayed records. The logs should contain the details of the retrieved contacts from the person table (e.g., "Record: ..."). If no data is present, the logs should either be empty or without errors. This test validates the ability to retrieve and log contact information.

  • Expected Result: HTTP 200 status code and verification of logged contact details.
  • Verification Steps:
    1. Send a GET request to the /contacts endpoint.
    2. Check the HTTP status code to ensure it is 200.
    3. Examine the application logs to verify the presence and correctness of logged contact details.
    4. If no data exists, ensure the logs are either empty or without errors.

5. Ensuring Data Integrity: /addUser followed by /contacts

This test verifies that a newly added person via the /addUser endpoint is correctly reflected when retrieving contacts via the /contacts endpoint. This ensures data consistency across different operations. Following the addition of a user, we verify that the newly added contact appears in the logs when /contacts is accessed. The test also checks for the completeness of the fields to confirm that all the necessary information is displayed.

  • Expected Result: The newly added person is present in the logs when accessing /contacts, and all fields are complete.
  • Verification Steps:
    1. Call /addUser to add a new contact.
    2. Call /contacts to retrieve the list of contacts.
    3. Examine the application logs to ensure the newly added contact is present.
    4. Verify that all fields for the new contact are displayed correctly and completely.

6. Simulating Database Outages

Simulating a database outage, such as changing credentials or shutting down the database, helps to test the application's resilience and error handling capabilities. In such scenarios, the /addUser endpoint should return an error status code (5xx), and an exception should be logged without including any sensitive information like passwords or connection strings. This test validates the application's ability to gracefully handle database failures.

  • Expected Result: The /addUser endpoint returns a 5xx error code, and an exception is logged without sensitive information.
  • Verification Steps:
    1. Simulate a database outage by changing credentials or shutting down the database.
    2. Call /addUser.
    3. Check that a 5xx error code is returned.
    4. Examine the application logs to verify that an exception is logged and that no sensitive information is included.

7. Concurrent Requests to /addUser

Multiple parallel calls to the /addUser endpoint simulate heavy load and test for potential inconsistencies. The goal is to ensure that no partially saved records occur and to record the final number of contacts in the database. This test validates the application's ability to handle concurrent requests without corrupting data.

  • Expected Result: No inconsistencies (partially saved records) should occur, and the final contact count should be recorded.
  • Verification Steps:
    1. Make multiple concurrent calls to the /addUser endpoint.
    2. Check the database for any partially saved records.
    3. Record the final number of contacts in the database to ensure all requests were handled correctly.

8. Ensuring Sensitive Data Protection

Reviewing logs for sensitive information like passwords and connection strings is crucial for security. This test verifies that the application does not log any sensitive data, protecting it from unauthorized access. Regular log reviews help maintain the confidentiality of critical information.

  • Expected Result: Logs should not contain sensitive information such as passwords or connection strings.
  • Verification Steps:
    1. Review the application logs.
    2. Ensure that no sensitive information, such as passwords or connection strings, is present.
    3. Implement regular log reviews to maintain data protection.

Report: Documenting Test Results

For each test point, the report should include the following:

  • Status: PASS or FAIL
  • Screenshots/Log Excerpts: Relevant evidence to support the status.
  • SQL Count: The number of rows in the person table after the test.

This comprehensive report provides a clear overview of the application's functionality and any potential issues identified during testing.

Enhancements: Expanding the Test Scope

To further enhance the testing process, consider the following additions:

  • JSON Format Validation: If the response body includes JSON, validate its format to ensure data consistency.
  • Performance Testing: Conduct performance tests to evaluate the application's responsiveness and scalability under load.

Conclusion

By systematically testing each endpoint and database interaction, you can ensure the reliability and robustness of the ContactManager application. This guide provides a solid foundation for verifying the application's core functionality and identifying potential issues early in the development process. Regularly performing these tests and expanding the test scope as needed will help maintain a high-quality application.

For more information on software testing best practices, visit the website of the International Software Testing Qualifications Board (ISTQB). This external resource provides valuable insights and guidelines for effective testing strategies and techniques.