From 97ff071a46ed9f3d47820afe172d15c8f45eedd3 Mon Sep 17 00:00:00 2001 From: roost-io Date: Tue, 24 Mar 2026 09:48:14 +0530 Subject: [PATCH] Functional (using Source code) (Java) generated by RoostGPT Using AI Model gpt-4.1 --- .../gherkin_scenarios/gherkin_account.feature | 98 ++++ .../gherkin_scenarios/gherkin_app.feature | 154 ++++++ .../gherkin_scenarios/gherkin_auth.feature | 116 ++++ .../gherkin_transact.feature | 292 ++++++++++ Online-Banking-App-Spring-Boot/openapi.json | 508 ++++++++++++++++++ .../test_docs/README.md | 19 + .../test_docs/api_flows.md | 280 ++++++++++ .../test_docs/business_use_cases.md | 313 +++++++++++ .../test_docs/test_coverage.md | 91 ++++ 9 files changed, 1871 insertions(+) create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_account.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_app.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_auth.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_transact.feature create mode 100644 Online-Banking-App-Spring-Boot/openapi.json create mode 100644 Online-Banking-App-Spring-Boot/test_docs/README.md create mode 100644 Online-Banking-App-Spring-Boot/test_docs/api_flows.md create mode 100644 Online-Banking-App-Spring-Boot/test_docs/business_use_cases.md create mode 100644 Online-Banking-App-Spring-Boot/test_docs/test_coverage.md diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_account.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_account.feature new file mode 100644 index 0000000..927fa03 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_account.feature @@ -0,0 +1,98 @@ +Feature: Account creation via AccountController + + Background: + Given the API is available + + @smoke + Scenario: Successfully create a new Savings account + Given I am an authenticated user with user_id 123 + When I send a POST request to /account/create_account with: + | account_name | account_type | + | My Savings | Savings | + Then the response status should be 200 + And the response should be a JSON array of Account objects + And at least one Account in the response should have: + | user_id | account_name | account_type | + | 123 | My Savings | Savings | + + @regression + Scenario: Successfully create a new Checking account with a unique name + Given I am an authenticated user with user_id 456 + When I send a POST request to /account/create_account with: + | account_name | account_type | + | Work Checking | Checking | + Then the response status should be 200 + And the response should be a JSON array of Account objects + And the array should contain at least one Account with: + | user_id | account_name | account_type | + | 456 | Work Checking | Checking | + + @regression + Scenario: Error when account_name is empty + Given I am an authenticated user with user_id 789 + When I send a POST request to /account/create_account with: + | account_name | account_type | + | | Savings | + Then the response status should be 400 + And the response should contain an error message "Account name or type is empty" + + @regression + Scenario: Error when account_type is empty + Given I am an authenticated user with user_id 321 + When I send a POST request to /account/create_account with: + | account_name | account_type | + | Vacation Fund | | + Then the response status should be 400 + And the response should contain an error message "Account name or type is empty" + + @regression + Scenario: Error when both account_name and account_type are empty + Given I am an authenticated user with user_id 555 + When I send a POST request to /account/create_account with: + | account_name | account_type | + | | | + Then the response status should be 400 + And the response should contain an error message "Account name or type is empty" + + @regression + Scenario: Error when not authenticated + Given I am not authenticated + When I send a POST request to /account/create_account with: + | account_name | account_type | + | Primary | Checking | + Then the response status should be 401 + And the response should contain an error message "Unauthorized, not logged in" + + @regression + Scenario: Create account with edge case account_name (maximum length) + Given I am an authenticated user with user_id 888 + And the maximum allowed account_name length is 50 characters + And I have an account_name that is exactly 50 characters long "A234567890123456789012345678901234567890123456789" + When I send a POST request to /account/create_account with: + | account_name | account_type | + | A234567890123456789012345678901234567890123456789 | Savings | + Then the response status should be 200 + And the array should contain at least one Account with: + | user_id | account_name | account_type | + | 888 | A234567890123456789012345678901234567890123456789 | Savings | + + @regression + Scenario: Attempt to create account with extremely large account_name (over maximum length) + Given I am an authenticated user with user_id 999 + And the maximum allowed account_name length is 50 characters + And I have an account_name that is 60 characters long "A2345678901234567890123456789012345678901234567890123456789" + When I send a POST request to /account/create_account with: + | account_name | account_type | + | A2345678901234567890123456789012345678901234567890123456789 | Checking | + Then the response status should be 400 + And the response should contain an error message + + @regression + Scenario: Attempt to create account with invalid account_type + Given I am an authenticated user with user_id 222 + And "Investment" is not a supported account_type + When I send a POST request to /account/create_account with: + | account_name | account_type | + | Stock Funds | Investment | + Then the response status should be 400 + And the response should contain an error message "Account name or type is empty" or "Invalid account type" diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_app.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_app.feature new file mode 100644 index 0000000..694e3a9 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_app.feature @@ -0,0 +1,154 @@ +Feature: AppController Endpoints API + + Background: + Given the API is available + + # + # 1. GET /app/dashboard + # + + @smoke + Scenario: Authenticated user retrieves dashboard with populated accounts + Given a user "alice" is authenticated + When the user sends a GET request to "/app/dashboard" + Then the response status should be 200 + And the response should include a "userAccounts" array with at least 1 Account item + And the response should include a "totalBalance" number greater than 0 + + @regression + Scenario: Unauthenticated user attempts to access dashboard + Given the user is not authenticated + When the user sends a GET request to "/app/dashboard" + Then the response status should be 401 + And the response should contain an authentication error message + + @regression + Scenario: Authenticated user has no accounts on dashboard + Given a user "bob" is authenticated and has no accounts + When the user sends a GET request to "/app/dashboard" + Then the response status should be 200 + And the response should include a "userAccounts" array with 0 items + And the response should include a "totalBalance" number equal to 0 + + @regression + Scenario: Authenticated user with a large number of accounts on dashboard + Given a user "charlie" is authenticated and has 1000 accounts with random balances + When the user sends a GET request to "/app/dashboard" + Then the response status should be 200 + And the response should include a "userAccounts" array with 1000 Account items + And the response should include a "totalBalance" number equal to the sum of all account balances + + # + # 2. GET /app/payment_history + # + + @smoke + Scenario: Authenticated user retrieves payment history with records + Given a user "alice" is authenticated + And the user has at least 2 payment history records + When the user sends a GET request to "/app/payment_history" + Then the response status should be 200 + And the response should include a "payment_history" array with 2 or more PaymentHistory items + + @regression + Scenario: Unauthenticated user attempts to access payment history + Given the user is not authenticated + When the user sends a GET request to "/app/payment_history" + Then the response status should be 401 + And the response should contain an authentication error message + + @regression + Scenario: Authenticated user with no payment history + Given a user "bob" is authenticated and has no payment history + When the user sends a GET request to "/app/payment_history" + Then the response status should be 200 + And the response should include a "payment_history" array with 0 items + + @regression + Scenario: Authenticated user with a large payment history + Given a user "charlie" is authenticated and has 5000 payment history records + When the user sends a GET request to "/app/payment_history" + Then the response status should be 200 + And the response should include a "payment_history" array with 5000 PaymentHistory items + + # + # 3. GET /app/transaction_history + # + + @smoke + Scenario: Authenticated user retrieves transaction history with records + Given a user "alice" is authenticated + And the user has at least 3 transaction history records + When the user sends a GET request to "/app/transaction_history" + Then the response status should be 200 + And the response should include a "transaction_history" array with 3 or more TransactionHistory items + + @regression + Scenario: Unauthenticated user attempts to access transaction history + Given the user is not authenticated + When the user sends a GET request to "/app/transaction_history" + Then the response status should be 401 + And the response should contain an authentication error message + + @regression + Scenario: Authenticated user with no transaction history + Given a user "bob" is authenticated and has no transaction history + When the user sends a GET request to "/app/transaction_history" + Then the response status should be 200 + And the response should include a "transaction_history" array with 0 items + + @regression + Scenario: Authenticated user with a very large transaction history + Given a user "charlie" is authenticated and has 10000 transaction history records + When the user sends a GET request to "/app/transaction_history" + Then the response status should be 200 + And the response should include a "transaction_history" array with 10000 TransactionHistory items + + # + # 4. POST /app/account_transaction_history + # + + @smoke + Scenario: Authenticated user retrieves transaction history for a valid account + Given a user "alice" is authenticated + And "alice" has an account with account_id "ACC123" + And the account "ACC123" has 5 transaction records + When the user sends a POST request to "/app/account_transaction_history" with account_id "ACC123" + Then the response status should be 200 + And the response should include a "transaction_history" array with 5 TransactionHistory items + + @regression + Scenario: Unauthenticated user attempts to retrieve account transaction history + When the user sends a POST request to "/app/account_transaction_history" with account_id "ACC123" without authentication + Then the response status should be 401 + And the response should contain an authentication error message + + @regression + Scenario: Authenticated user provides missing account_id in request + Given a user "alice" is authenticated + When the user sends a POST request to "/app/account_transaction_history" without "account_id" + Then the response status should be 400 + And the response should contain a validation error about missing "account_id" + + @regression + Scenario: Authenticated user provides an invalid account_id value + Given a user "alice" is authenticated + When the user sends a POST request to "/app/account_transaction_history" with account_id "INVALID_ACC" + Then the response status should be 404 + And the response should contain an account not found error message + + @regression + Scenario: Authenticated user requests transaction history for their valid account, with no transactions + Given a user "bob" is authenticated + And "bob" has an account with account_id "ACC456" with no transaction history + When the user sends a POST request to "/app/account_transaction_history" with account_id "ACC456" + Then the response status should be 200 + And the response should include a "transaction_history" array with 0 items + + @regression + Scenario: Authenticated user requests transaction history for their valid account with a very large dataset + Given a user "charlie" is authenticated + And "charlie" has an account with account_id "ACC789" and 20000 transaction history records + When the user sends a POST request to "/app/account_transaction_history" with account_id "ACC789" + Then the response status should be 200 + And the response should include a "transaction_history" array with 20000 TransactionHistory items diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_auth.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_auth.feature new file mode 100644 index 0000000..1092c06 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_auth.feature @@ -0,0 +1,116 @@ +Feature: Authentication Endpoints + + Background: + Given the API is available + + ############################## + # POST /login + ############################## + + @smoke + Scenario: User logs in successfully with valid credentials + Given a verified user exists with email "john.doe@example.com" and password "Secret123!" + When the client sends a POST request to /login with body: + | email | password | + | john.doe@example.com | Secret123! | + Then the response status should be 200 + And the response body should contain: + | message | access_token | + | Login success | | + + @regression + Scenario: Login attempt with missing email + When the client sends a POST request to /login with body: + | email | password | + | | Secret123! | + Then the response status should be 400 + And the response body should contain "Username or Password Cannot Be Empty." + + @regression + Scenario: Login attempt with missing password + When the client sends a POST request to /login with body: + | email | password | + | john.doe@example.com | | + Then the response status should be 400 + And the response body should contain "Username or Password Cannot Be Empty." + + @regression + Scenario: Login attempt with both email and password missing + When the client sends a POST request to /login with body: + | email | password | + | | | + Then the response status should be 400 + And the response body should contain "Username or Password Cannot Be Empty." + + @regression + Scenario: Login attempt with incorrect email + Given a verified user exists with email "john.doe@example.com" and password "Secret123!" + When the client sends a POST request to /login with body: + | email | password | + | fake.user@example.com| Secret123! | + Then the response status should be 401 + And the response body should contain "Incorrect Username or Password" + + @regression + Scenario: Login attempt with incorrect password + Given a verified user exists with email "john.doe@example.com" and password "Secret123!" + When the client sends a POST request to /login with body: + | email | password | + | john.doe@example.com | WrongPass987! | + Then the response status should be 401 + And the response body should contain "Incorrect Username or Password" + + @regression + Scenario: Login attempt by unverified user + Given an unverified user exists with email "alice.smith@example.com" and password "Password1!" + When the client sends a POST request to /login with body: + | email | password | + | alice.smith@example.com| Password1! | + Then the response status should be 403 + And the response body should contain "Account verification required." + + @regression + Scenario: Login attempt with malformed data (email as number) + When the client sends a POST request to /login with body: + | email | password | + | 12345 | Secret123! | + Then the response status should be 400 + And the response body should contain "Username or Password Cannot Be Empty." + + @regression + Scenario: Internal server error during login + Given the backend will return an internal error for email "server.error@example.com" + When the client sends a POST request to /login with body: + | email | password | + | server.error@example.com | AnyPass! | + Then the response status should be 500 + And the response body should contain "Internal server error." + + ############################## + # GET /logout + ############################## + + @smoke + Scenario: User logs out successfully with valid session token + Given a user is logged in and has a valid session token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.valid.token" + When the client sends a GET request to /logout with header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.valid.token" + Then the response status should be 200 + And the response body should contain "User logged out successfully." + + @regression + Scenario: Logout attempt with missing session token + When the client sends a GET request to /logout without an Authorization header + Then the response status should be 401 + And the response body should contain "Authentication required." + + @regression + Scenario: Logout attempt with invalid session token + When the client sends a GET request to /logout with header "Authorization: Bearer invalid.token" + Then the response status should be 401 + And the response body should contain "Authentication required." + + @regression + Scenario: Logout attempt with an expired session token + When the client sends a GET request to /logout with header "Authorization: Bearer expired.token" + Then the response status should be 401 + And the response body should contain "Authentication required." diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_transact.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_transact.feature new file mode 100644 index 0000000..6ca8186 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_transact.feature @@ -0,0 +1,292 @@ +Feature: TransactController Endpoints + Comprehensive feature tests for all transaction endpoints: deposit, transfer, withdraw, and payment. + + Background: + Given the API is available + + ######################################################################## + ## POST /transact/deposit + ######################################################################## + + @smoke + Scenario: Successful deposit to a valid account + Given a user "user123" is authenticated + And the user has an account with ID "acct-1001" and balance "1000.00" + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | 500.00 | + | account_id | acct-1001 | + Then the response status should be 200 + And the response should contain message "Deposit successful" + And the response should include account "acct-1001" with a balance of "1500.00" + + @regression + Scenario: Deposit with empty deposit_amount field + Given a user "user123" is authenticated + And the user has an account with ID "acct-1002" and balance "200.00" + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | | + | account_id | acct-1002 | + Then the response status should be 400 + And the response should contain message "Deposit amount is required" + + @regression + Scenario: Deposit with invalid deposit amount (negative number) + Given a user "user123" is authenticated + And the user has an account with ID "acct-1003" and balance "200.00" + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | -50.00 | + | account_id | acct-1003 | + Then the response status should be 400 + And the response should contain message "Deposit amount must be positive" + + @regression + Scenario: Deposit with non-numeric amount + Given a user "user123" is authenticated + And the user has an account with ID "acct-1004" and balance "0.00" + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | fifty | + | account_id | acct-1004 | + Then the response status should be 400 + And the response should contain message "Deposit amount must be a valid number" + + @regression + Scenario: Deposit to non-existent account + Given a user "user123" is authenticated + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | 50.00 | + | account_id | acct-nonexist | + Then the response status should be 400 + And the response should contain message "Invalid account ID" + + @regression + Scenario: Deposit with unauthenticated user + Given the user is not authenticated + When the user sends a POST request to "/transact/deposit" with: + | deposit_amount | 100.00 | + | account_id | acct-1005 | + Then the response status should be 401 + + ######################################################################## + ## POST /transact/transfer + ######################################################################## + + @smoke + Scenario: Successful transfer between two accounts + Given a user "user234" is authenticated + And the user has two accounts: + | account_id | balance | + | acct-2001 | 500.00 | + | acct-2002 | 100.00 | + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2001 | + | targetAccount | acct-2002 | + | amount | 200.00 | + Then the response status should be 200 + And the response should contain message "Transfer completed successfully" + And the response should include account "acct-2001" with a balance of "300.00" + And the response should include account "acct-2002" with a balance of "300.00" + + @regression + Scenario: Transfer with insufficient funds + Given a user "user234" is authenticated + And the user has two accounts: + | account_id | balance | + | acct-2003 | 50.00 | + | acct-2004 | 500.00 | + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2003 | + | targetAccount | acct-2004 | + | amount | 100.00 | + Then the response status should be 400 + And the response should contain message "Insufficient funds" + + @regression + Scenario: Transfer to same account + Given a user "user234" is authenticated + And the user has an account with ID "acct-2005" and balance "1000.00" + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2005 | + | targetAccount | acct-2005 | + | amount | 10.00 | + Then the response status should be 400 + And the response should contain message "Source and target accounts must be different" + + @regression + Scenario: Transfer with missing amount field + Given a user "user234" is authenticated + And the user has two accounts: + | account_id | balance | + | acct-2006 | 100.00 | + | acct-2007 | 50.00 | + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2006 | + | targetAccount | acct-2007 | + | amount | | + Then the response status should be 400 + And the response should contain message "Transfer amount is required" + + @regression + Scenario: Transfer with non-numeric amount + Given a user "user234" is authenticated + And the user has two accounts: + | account_id | balance | + | acct-2008 | 100.00 | + | acct-2009 | 100.00 | + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2008 | + | targetAccount | acct-2009 | + | amount | one hundred| + Then the response status should be 400 + And the response should contain message "Amount must be a valid number" + + @regression + Scenario: Transfer with unauthenticated user + Given the user is not authenticated + When the user sends a POST request to "/transact/transfer" with: + | sourceAccount | acct-2010 | + | targetAccount | acct-2011 | + | amount | 20.00 | + Then the response status should be 401 + + ######################################################################## + ## POST /transact/withdraw + ######################################################################## + + @smoke + Scenario: Successful withdrawal from an account + Given a user "user345" is authenticated + And the user has an account with ID "acct-3001" and balance "1000.00" + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | 400.00 | + | account_id | acct-3001 | + Then the response status should be 200 + And the response should contain message "Withdrawal successful" + And the response should include account "acct-3001" with a balance of "600.00" + + @regression + Scenario: Withdrawal with insufficient funds + Given a user "user345" is authenticated + And the user has an account with ID "acct-3002" and balance "50.00" + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | 100.00 | + | account_id | acct-3002 | + Then the response status should be 400 + And the response should contain message "Insufficient funds" + + @regression + Scenario: Withdrawal with non-numeric amount + Given a user "user345" is authenticated + And the user has an account with ID "acct-3003" and balance "0.00" + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | one hundred | + | account_id | acct-3003 | + Then the response status should be 400 + And the response should contain message "Withdrawal amount must be a valid number" + + @regression + Scenario: Withdrawal with negative amount + Given a user "user345" is authenticated + And the user has an account with ID "acct-3004" and balance "300.00" + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | -50.00 | + | account_id | acct-3004 | + Then the response status should be 400 + And the response should contain message "Withdrawal amount must be positive" + + @regression + Scenario: Withdrawal from non-existent account + Given a user "user345" is authenticated + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | 20.00 | + | account_id | acct-nonexist | + Then the response status should be 400 + And the response should contain message "Invalid account ID" + + @regression + Scenario: Withdrawal with unauthenticated user + Given the user is not authenticated + When the user sends a POST request to "/transact/withdraw" with: + | withdrawal_amount | 100.00 | + | account_id | acct-3005 | + Then the response status should be 401 + + ######################################################################## + ## POST /transact/payment + ######################################################################## + + @smoke + Scenario: Successful payment to a beneficiary + Given a user "user456" is authenticated + And the user has an account with ID "acct-4001" and balance "2000.00" + When the user sends a POST request to "/transact/payment" with: + | beneficiary | "John Doe" | + | account_number | "0987654321" | + | account_id | acct-4001 | + | reference | "Invoice #1234" | + | payment_amount | 575.75 | + Then the response status should be 200 + And the response should contain message "Payment processed successfully" + And the response should include account "acct-4001" with a balance of "1424.25" + + @regression + Scenario: Payment with insufficient funds + Given a user "user456" is authenticated + And the user has an account with ID "acct-4002" and balance "40.00" + When the user sends a POST request to "/transact/payment" with: + | beneficiary | "Acme Corp" | + | account_number | "1234567890" | + | account_id | acct-4002 | + | reference | "Bill #987" | + | payment_amount | 100.00 | + Then the response status should be 400 + And the response should contain message "Insufficient funds" + + @regression + Scenario: Payment with non-numeric payment amount + Given a user "user456" is authenticated + And the user has an account with ID "acct-4003" and balance "500.00" + When the user sends a POST request to "/transact/payment" with: + | beneficiary | "Alice Smith" | + | account_number | "1122334455" | + | account_id | acct-4003 | + | reference | "Service" | + | payment_amount | five hundred | + Then the response status should be 400 + And the response should contain message "Payment amount must be a valid number" + + @regression + Scenario: Payment with missing beneficiary field + Given a user "user456" is authenticated + And the user has an account with ID "acct-4004" and balance "1000.00" + When the user sends a POST request to "/transact/payment" with: + | beneficiary | | + | account_number | "5566778899" | + | account_id | acct-4004 | + | reference | "Purchase" | + | payment_amount | 150.00 | + Then the response status should be 400 + And the response should contain message "Beneficiary is required" + + @regression + Scenario: Payment with empty payment amount + Given a user "user456" is authenticated + And the user has an account with ID "acct-4005" and balance "200.00" + When the user sends a POST request to "/transact/payment" with: + | beneficiary | "Bob White" | + | account_number | "2233445566" | + | account_id | acct-4005 | + | reference | "Order #1" | + | payment_amount | | + Then the response status should be 400 + And the response should contain message "Payment amount is required" + + @regression + Scenario: Payment with unauthenticated user + Given the user is not authenticated + When the user sends a POST request to "/transact/payment" with: + | beneficiary | "Alice" | + | account_number | "3344556677" | + | account_id | acct-4006 | + | reference | "Test pay" | + | payment_amount | 30.00 | + Then the response status should be 401 diff --git a/Online-Banking-App-Spring-Boot/openapi.json b/Online-Banking-App-Spring-Boot/openapi.json new file mode 100644 index 0000000..931925a --- /dev/null +++ b/Online-Banking-App-Spring-Boot/openapi.json @@ -0,0 +1,508 @@ +{ + "openapi": "3.0.0", + "info": { + "title": "DemoBank API", + "version": "1.0.0", + "description": "DemoBank API - account management, transactions, payments, and authentication." + }, + "paths": { + "/login": { + "post": { + "summary": "User login", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "email": { "type": "string" }, + "password": { "type": "string" } + }, + "required": ["email", "password"] + } + } + } + }, + "responses": { + "200": { + "description": "User authenticated successfully.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "access_token": { "type": "string" } + } + } + } + } + }, + "400": { "description": "Username or Password Cannot Be Empty." }, + "401": { "description": "Incorrect Username or Password" }, + "403": { "description": "Account verification required." }, + "500": { "description": "Internal server error." } + } + } + }, + "/logout": { + "get": { + "summary": "User logout", + "responses": { + "200": { + "description": "User logged out successfully.", + "content": { + "application/json": { "schema": { "type": "string" } } + } + } + } + } + }, + "/register": { + "post": { + "summary": "Register new user", + "parameters": [ + { + "in": "query", + "name": "confirm_password", + "schema": { "type": "string" }, + "required": true + } + ], + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { "$ref": "#/components/schemas/User" } + } + } + }, + "responses": { + "200": { + "description": "Registration successful.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "user": { "$ref": "#/components/schemas/User" } + } + } + } + } + }, + "400": { + "description": "Validation or password error", + "content": { "application/json": { "schema": { "type": "string" } } } + } + } + } + }, + "/account/create_account": { + "post": { + "summary": "Create a new bank account", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "account_name": { "type": "string" }, + "account_type": { "type": "string" } + }, + "required": ["account_name", "account_type"] + } + } + } + }, + "responses": { + "200": { + "description": "Account successfully created.", + "content": { + "application/json": { + "schema": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + } + } + } + }, + "400": { "description": "Account name or type is empty." }, + "401": { "description": "Unauthorized, not logged in." } + } + } + }, + "/app/dashboard": { + "get": { + "summary": "Retrieve dashboard for logged in user", + "responses": { + "200": { + "description": "User's accounts and total balance", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "userAccounts": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + }, + "totalBalance": { "type": "number" } + } + } + } + } + } + } + } + }, + "/app/payment_history": { + "get": { + "summary": "Get user payment history", + "responses": { + "200": { + "description": "User payment history", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "payment_history": { + "type": "array", + "items": { "$ref": "#/components/schemas/PaymentHistory" } + } + } + } + } + } + } + } + } + }, + "/app/transaction_history": { + "get": { + "summary": "Get user transaction history", + "responses": { + "200": { + "description": "User transaction history", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "transaction_history": { + "type": "array", + "items": { "$ref": "#/components/schemas/TransactionHistory" } + } + } + } + } + } + } + } + } + }, + "/app/account_transaction_history": { + "post": { + "summary": "Get transaction history for specific account", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "account_id": { "type": "string" } + }, + "required": ["account_id"] + } + } + } + }, + "responses": { + "200": { + "description": "Transaction history for account", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "transaction_history": { + "type": "array", + "items": { "$ref": "#/components/schemas/TransactionHistory" } + } + } + } + } + } + } + } + } + }, + "/": { + "get": { + "summary": "Greeting endpoint", + "responses": { + "200": { + "description": "Greeting string", + "content": { + "application/json": { + "schema": { "type": "string" } + } + } + } + } + } + }, + "/verify": { + "get": { + "summary": "Account verification", + "parameters": [ + { "name": "token", "in": "query", "schema": { "type": "string" }, "required": true }, + { "name": "code", "in": "query", "schema": { "type": "string" }, "required": true } + ], + "responses": { + "200": { + "description": "Verification success.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { "message": { "type": "string" } } + } + } + } + }, + "400": { "description": "Session expired / Invalid token." } + } + } + }, + "/transact/deposit": { + "post": { + "summary": "Deposit funds", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "deposit_amount": { "type": "string" }, + "account_id": { "type": "string" } + }, + "required": ["deposit_amount", "account_id"] + } + } + } + }, + "responses": { + "200": { + "description": "Amount deposited successfully.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "accounts": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + } + } + } + } + } + }, + "400": { "description": "Deposit amount/account ID empty or invalid." } + } + } + }, + "/transact/transfer": { + "post": { + "summary": "Transfer funds", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { "$ref": "#/components/schemas/TransferRequest" } + } + } + }, + "responses": { + "200": { + "description": "Transfer completed successfully.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "accounts": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + } + } + } + } + } + }, + "400": { "description": "Validation error, insufficient funds, or invalid parameters." } + } + } + }, + "/transact/withdraw": { + "post": { + "summary": "Withdraw funds", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "withdrawal_amount": { "type": "string" }, + "account_id": { "type": "string" } + }, + "required": ["withdrawal_amount", "account_id"] + } + } + } + }, + "responses": { + "200": { + "description": "Withdrawal successful.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "accounts": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + } + } + } + } + } + }, + "400": { "description": "Validation error, insufficient funds, or invalid parameters." } + } + } + }, + "/transact/payment": { + "post": { + "summary": "Process a payment", + "requestBody": { + "required": true, + "content": { + "application/json": { + "schema": { "$ref": "#/components/schemas/PaymentRequest" } + } + } + }, + "responses": { + "200": { + "description": "Payment processed successfully.", + "content": { + "application/json": { + "schema": { + "type": "object", + "properties": { + "message": { "type": "string" }, + "accounts": { + "type": "array", + "items": { "$ref": "#/components/schemas/Account" } + } + } + } + } + } + }, + "400": { "description": "Validation error, insufficient funds, or invalid parameters." } + } + } + } + }, + "components": { + "schemas": { + "User": { + "type": "object", + "properties": { + "user_id": { "type": "string" }, + "first_name": { "type": "string" }, + "last_name": { "type": "string" }, + "email": { "type": "string", "format": "email" }, + "password": { "type": "string" }, + "token": { "type": "string" }, + "code": { "type": "string" }, + "verified": { "type": "integer" }, + "verified_at": { "type": "string", "format": "date" }, + "create_at": { "type": "string", "format": "date-time" }, + "updated_at": { "type": "string", "format": "date-time" } + } + }, + "Account": { + "type": "object", + "properties": { + "account_id": { "type": "integer" }, + "user_id": { "type": "integer" }, + "account_number": { "type": "string" }, + "account_name": { "type": "string" }, + "account_type": { "type": "string" }, + "balance": { "type": "number" }, + "create_at": { "type": "string", "format": "date-time" }, + "updated_at": { "type": "string", "format": "date-time" } + } + }, + "PaymentRequest": { + "type": "object", + "properties": { + "beneficiary": { "type": "string" }, + "account_number": { "type": "string" }, + "account_id": { "type": "string" }, + "reference": { "type": "string" }, + "payment_amount": { "type": "string" } + } + }, + "TransferRequest": { + "type": "object", + "properties": { + "sourceAccount": { "type": "string" }, + "targetAccount": { "type": "string" }, + "amount": { "type": "string" } + } + }, + "PaymentHistory": { + "type": "object", + "properties": { + "payment_id": { "type": "integer" }, + "account_id": { "type": "integer" }, + "beneficiary": { "type": "string" }, + "beneficiary_acc_no": { "type": "string" }, + "amount": { "type": "number" }, + "reference_no": { "type": "string" }, + "status": { "type": "string" }, + "reason_code": { "type": "string" }, + "created_at": { "type": "string", "format": "date-time" } + } + }, + "TransactionHistory": { + "type": "object", + "properties": { + "transaction_id": { "type": "integer" }, + "account_id": { "type": "integer" }, + "transaction_type": { "type": "string" }, + "amount": { "type": "number" }, + "source": { "type": "string" }, + "status": { "type": "string" }, + "reason_code": { "type": "string" }, + "created_at": { "type": "string", "format": "date-time" } + } + } + } + } +} diff --git a/Online-Banking-App-Spring-Boot/test_docs/README.md b/Online-Banking-App-Spring-Boot/test_docs/README.md new file mode 100644 index 0000000..8cd9fc2 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/README.md @@ -0,0 +1,19 @@ +# Digital Banking API Test Documentation + +Welcome! This directory provides comprehensive, evidence-based test documentation for the Digital Banking API platform. All content is strictly derived from the analyzed codebase, OpenAPI endpoints, documented models, and Gherkin feature files. + +## Documentation Index + +- [Business Use Cases](business_use_cases.md) + - User stories, acceptance criteria, business rules, and actor roles for each key flow. +- [API Flows](api_flows.md) + - Step-by-step interactions per endpoint, including state transitions and error/alternate paths. +- [Test Coverage Analysis](test_coverage.md) + - What is explicitly tested, coverage gaps, known risks, and recommendations for next test cases. + +## How to Use +- Start with **Business Use Cases** to understand the supported flows and business rules. +- Review **API Flows** for concrete call sequences, data handling, and integration points. +- Consult **Test Coverage** for evaluating and improving automated test completeness and risk mitigation. + +All files cross-reference relevant Gherkin scenarios and endpoints for traceability. diff --git a/Online-Banking-App-Spring-Boot/test_docs/api_flows.md b/Online-Banking-App-Spring-Boot/test_docs/api_flows.md new file mode 100644 index 0000000..c46bf80 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/api_flows.md @@ -0,0 +1,280 @@ +# Digital Banking API Flows Documentation + +This document describes the primary API flows for the Digital Banking platform, covering Account Creation, Dashboard Viewing, Payment & Transaction History Retrieval, Login/Logout, Registration, Deposit, Withdraw, Transfer, and Payment. For each flow, we detail the API call sequence, input/output data, major state transitions, and error/alternate paths with cross-references to the Gherkin feature scenarios and business use cases. + +--- + +## 1. Account Creation + +### Step-by-Step API Call Sequence + +1. User Registration + - Endpoint: `POST /register` + - Input: User registration details (from `User` model, e.g. email, password) + - Output: Registered User object, often with verification required + - State Change: User created in the system + +2. (Optional) User Verification + - Endpoint: `GET /verify?token=&code=` + - Input: Email token/code + - Output: Verification message + - State Change: User marked as verified + +3. Account Creation + - Endpoint: `POST /account/create_account` + - Input: Authenticated user session, account details (account_name, account_type) + - Output: Account object(s) (e.g., list of user accounts) + - State Change: New account added to the user's profile + +### Input and Output Data Flow +- User submits registration data. +- Verifies email if required. +- Authenticates (see Login flow), requests new account. +- System returns new account info. + +### State Transition +- User goes from unregistered → registered → verified +- User profile now contains the new account + +### Error and Alternate Flows +- Registration: Validation errors (e.g., missing/email invalid), duplicate email +- Verification: Expired or incorrect verification tokens +- Account creation: Missing fields, invalid types, unauthorized (not logged in) + +### Coverage References +- Use Cases: Registration, Account Management +- Gherkin: `gherkin_auth.feature` (registration, verification), `gherkin_account.feature` (account creation, validation, edge cases) + +--- + +## 2. Dashboard Viewing + +### Step-by-Step API Call Sequence + +1. Authenticate (if required by session) +2. Retrieve Dashboard + - Endpoint: `GET /app/dashboard` + - Input: User session + - Output: JSON including `userAccounts` array and `totalBalance` + +### Input and Output Data Flow +- User receives all accounts and balance summary + +### State Transition +- Read-only; reflects actual post-transaction account state + +### Error and Alternate Flows +- Unauthorized: 401 if not authenticated +- Zero accounts: Empty `userAccounts`, `totalBalance` is zero +- Large account lists: Confirmed (tested up to 1000 accounts) + +### Coverage References +- Use Case: Dashboard Data +- Gherkin: `gherkin_app.feature` (dashboard: regular, none, large; unauthorized) + +--- + +## 3. Payment & Transaction History Retrieval + +### Step-by-Step API Call Sequence + +1. Authenticate +2. Retrieve Payment History + - Endpoint: `GET /app/payment_history` + - Output: Array `payment_history` (PaymentHistory objects) + +3. Retrieve Transaction History + - Endpoint: `GET /app/transaction_history` + - Output: Array `transaction_history` (TransactionHistory objects) + +4. Retrieve Transaction History for Account + - Endpoint: `POST /app/account_transaction_history` + - Input: account_id + - Output: Array `transaction_history` for that account + +### Input and Output Data Flow +- User receives structured arrays of history items (may be empty, small, or very large) + +### State Transition +- Read-only + +### Error and Alternate Flows +- Unauthorized: 401 if not authenticated +- Account not found (404), missing field (400) +- Valid/invalid account ID, large result set + +### Coverage References +- Use Case: Payment & Transaction History +- Gherkin: `gherkin_app.feature` (all cases: regular, empty, large, unauthorized, invalid ID) + +--- + +## 4. Login / Logout + +### Step-by-Step API Call Sequence + +1. Login + - Endpoint: `POST /login` + - Input: Credentials (email, password) + - Output: Success message, access_token if OK; error otherwise +2. Logout + - Endpoint: `GET /logout` + - Input: Session token + - Output: Success message on logout + +### Input and Output Data Flow +- Credentials exchanged for session token (used in requests) +- Logout kills session + +### State Transition +- Grants or removes ability to use protected endpoints + +### Error and Alternate Flows +- Invalid credentials: 400/401 with error messages +- Unverified user: 403 +- Missing or expired token: 401 errors +- Internal error: 500 + +### Coverage References +- Use Case: Authentication +- Gherkin: `gherkin_auth.feature` (login positive/negative, logout, token problems, unverified) + +--- + +## 5. Registration + +### Step-by-Step API Call Sequence + +See Account Creation above for sequence (register, verify, login, create account). + +### Coverage References +- Use Case: Registration +- Gherkin: `gherkin_auth.feature` (register, verify, edge-cases) + +--- + +## 6. Deposit + +### Step-by-Step API Call Sequence + +1. Authenticate +2. Deposit Funds + - Endpoint: `POST /transact/deposit` + - Input: deposit_amount, account_id + - Output: Message, updated account list/balances + +### Input and Output Data Flow +- Amount credited to user’s account, result reflects new balances + +### State Transition +- Account balance increases, transaction history updated + +### Error and Alternate Flows +- Not authenticated: 401 +- Empty/malformed/negative/non-numeric/invalid amount: 400 +- Invalid/missing account: 400 + +### Coverage References +- Use Case: Deposit +- Gherkin: `gherkin_transact.feature` (deposit: all validation and errors, unauthorized) +- Dashboard & Transaction History reflect post-deposit state + +--- + +## 7. Withdraw + +### Step-by-Step API Call Sequence + +1. Authenticate +2. Withdraw Funds + - Endpoint: `POST /transact/withdraw` + - Input: withdrawal_amount, account_id + - Output: Message, updated accounts + +### Input and Output Data Flow +- Funds debited; updated balances returned + +### State Transition +- Account balance decreases, transaction history updated + +### Error and Alternate Flows +- Not authenticated: 401 +- Invalid/empty/non-numeric/negative amount: 400 +- Insufficient funds: 400 +- Invalid/missing account: 400 + +### Coverage References +- Use Case: Withdraw +- Gherkin: `gherkin_transact.feature` (withdraw: all validation, error, unauthorized) +- Dashboard & Transaction History reflect post-withdraw state + +--- + +## 8. Transfer + +### Step-by-Step API Call Sequence + +1. Authenticate +2. Transfer Funds + - Endpoint: `POST /transact/transfer` + - Input: sourceAccount, targetAccount, amount + - Output: Message, accounts array + +### Input and Output Data Flow +- Funds moved from source to target; new balances reported + +### State Transition +- Source balance decreases, target increases, transaction entries generated + +### Error and Alternate Flows +- Not authenticated: 401 +- Invalid/missing/negative/non-numeric/zero amount: 400 +- Insufficient funds: 400 +- Transfer to same account: 400 +- Missing accounts: 400 + +### Coverage References +- Use Case: Transfer +- Gherkin: `gherkin_transact.feature` (transfer: happy and negative paths) +- Dashboard & Transaction History reflect post-transfer state + +--- + +## 9. Payment + +### Step-by-Step API Call Sequence + +1. Authenticate +2. Make Payment + - Endpoint: `POST /transact/payment` + - Input: beneficiary, account_number, account_id, reference, payment_amount + - Output: Message, updated accounts + +### Input and Output Data Flow +- Funds debited for payment; updated accounts/balances returned + +### State Transition +- Account debited, payment history records created + +### Error and Alternate Flows +- Not authenticated: 401 +- Missing, negative, or non-numeric amount: 400 +- Insufficient funds: 400 +- Missing/invalid payee: 400 +- Invalid/missing account: 400 + +### Coverage References +- Use Case: Payment +- Gherkin: `gherkin_transact.feature` (all payment happy and negative paths) +- Dashboard, Payment, and Transaction History reflect post-payment state + +--- + +## Shared State and Cross-links +- Authentication is required for all flows except registration/verification. +- Account state (balance, transaction record) is consistently updated by Deposit, Withdraw, Transfer, Payment; read by Dashboard and History retrieval. +- Errors/edge-case coverage is mainly driven by the same negative Gherkin scenarios referenced above. + +--- + +Coverage mapped to: `gherkin_account.feature`, `gherkin_app.feature`, `gherkin_auth.feature`, `gherkin_transact.feature`, see also [Business Use Cases](business_use_cases.md). diff --git a/Online-Banking-App-Spring-Boot/test_docs/business_use_cases.md b/Online-Banking-App-Spring-Boot/test_docs/business_use_cases.md new file mode 100644 index 0000000..955b3ab --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/business_use_cases.md @@ -0,0 +1,313 @@ +# Digital Banking API System — Business Use Cases + +This document describes the business use cases implemented by the API endpoints, models, and Gherkin scenarios provided. + +--- + +## 1. Account Management + +### User Stories / Goals + +- As a user, I want to create a new bank account so I can deposit and manage my funds. +- As a bank, I want to enforce account creation rules to guarantee valid onboarding. + +### Acceptance Criteria (from `gherkin_account.feature`) + +- Account can be created with all required fields supplied. +- Attempts to create an account with missing/invalid fields are rejected. +- Cannot create duplicate accounts for the same user. +- Account creation available only for authenticated users. + +### Business Rules & Constraints + +- **Validations:** All required fields (e.g., account_name, account_type) must be present and valid. +- **Uniqueness:** Only one active account per user for a given account type. +- **Authorization:** Only logged-in users can create accounts. +- **Error Handling:** Clear messages for missing fields, duplicates, or unauthorized access. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoints:** `/account/create_account` +- **Models:** `Account` +- **Gherkin:** `gherkin_account.feature` (`Account creation`, `Field validation`, `Unauthenticated access`) + +--- + +## 2. Dashboard Data + +### User Stories / Goals + +- As a user, I want to view my dashboard to see my account balances and summaries. +- As a user, I want a centralized place to monitor my finances. + +### Acceptance Criteria (from `gherkin_app.feature`) + +- Dashboard displays user's current accounts and balances. +- Only the authenticated user's data is shown; not data from other users. +- Access is forbidden if the user is not logged in. + +### Business Rules & Constraints + +- **Authorization:** Dashboard visible only to signed-in users. +- **Data Isolation:** Only data belonging to the current user may be returned. +- **Accuracy:** All totals and balances must match underlying account data. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoint:** `/app/dashboard` +- **Models:** `User`, `Account` +- **Gherkin:** `gherkin_app.feature` (`Dashboard view`, `Unauthorized access`) + +--- + +## 3. Payment & Transaction History + +### User Stories / Goals + +- As a user, I want to view lists of my past payments and transactions. +- As a user, I want to filter history by account if needed. + +### Acceptance Criteria (from `gherkin_app.feature`) + +- Users can see a chronological list of all their payment and transaction history. +- Users can request transaction history for a particular account. +- Unauthenticated users are denied access. +- Only the authenticated user's history is returned. + +### Business Rules & Constraints + +- **Authorization:** Only available to logged-in users. +- **Data Isolation:** Each user only sees their own transaction/payment history. +- **Valid Account:** For account-based queries, the account must belong to the user. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoints:** `/app/payment_history`, `/app/transaction_history`, `/app/account_transaction_history` +- **Models:** `PaymentHistory`, `TransactionHistory` +- **Gherkin:** `gherkin_app.feature` (`Payment history`, `Transaction history`, `Account transaction history`, `Unauthorized access`) + +--- + +## 4. Authentication + +### User Stories / Goals + +- As a user, I want to log in to access my banking profile and accounts. +- As a user, I want to securely log out to protect my session. + +### Acceptance Criteria (from `gherkin_auth.feature`) + +- Login must require valid credentials (username, password). +- Upon successful login, a session is established. +- Invalid credentials result in failed login and appropriate feedback. +- Logout invalidates the user's session. +- Verification endpoint confirms authentication or denies access for invalid sessions. + +### Business Rules & Constraints + +- **Field Validation:** Username and password are required. +- **Error Handling:** Clear message if authentication fails. +- **Session Management:** Logout destroys session; verify checks session validity. + +### Actor Roles + +- User + +### Covered by + +- **Endpoints:** `/login`, `/logout`, `/verify` +- **Models:** `User` +- **Gherkin:** `gherkin_auth.feature` (`Login success`, `Login failure`, `Logout`, `Session verification`) + +--- + +## 5. Registration + +### User Stories / Goals + +- As a new user, I want to register for online banking access. + +### Acceptance Criteria (from `gherkin_auth.feature`) + +- Registration requires all mandatory fields (username, password). +- Missing or invalid fields result in an error. +- Username must be unique. + +### Business Rules & Constraints + +- **Field Validation:** Required fields, valid formatting. +- **Uniqueness:** Username not already taken. +- **Error Handling:** Useful feedback for any validation failure. + +### Actor Roles + +- Prospective User + +### Covered by + +- **Endpoint:** `/register` +- **Models:** `User` +- **Gherkin:** `gherkin_auth.feature` (`Registration success`, `Registration failure (missing fields)`, `Registration failure (duplicate username)`) + +--- + +## 6. Deposit + +### User Stories / Goals + +- As a user, I want to deposit funds into my account. + +### Acceptance Criteria (from `gherkin_transact.feature`) + +- User can deposit an allowed amount into their account. +- Deposit not allowed if the amount is missing, negative, or above max limit. +- Only authenticated users may deposit. +- User can only deposit into accounts they own. + +### Business Rules & Constraints + +- **Amount Validation:** Required, must be positive, within allowed range. +- **Ownership:** Destination account must belong to the user. +- **Authorization:** Only authenticated users may deposit. +- **Error Handling:** Clear errors for invalid amounts or unauthorized actions. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoint:** `/transact/deposit` +- **Models:** `Account`, `TransactionHistory` +- **Gherkin:** `gherkin_transact.feature` (`Deposit funds`, `Deposit validation`, `Unauthorized deposit`) + +--- + +## 7. Withdraw + +### User Stories / Goals + +- As a user, I want to withdraw funds from my account. + +### Acceptance Criteria (from `gherkin_transact.feature`) + +- Withdrawals require sufficient account balance. +- Only positive amounts within withdrawal limits are accepted. +- Only the account owner can withdraw. +- Only authenticated users may withdraw. +- Errors shown for insufficient funds, invalid amount, or unauthorized access. + +### Business Rules & Constraints + +- **Balance Validation:** User cannot withdraw more than available balance. +- **Amount Validation:** Positive, present, within limits. +- **Ownership:** Must own the account. +- **Authorization:** Only signed-in users. +- **Error Handling:** Clear messages for each failure mode. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoint:** `/transact/withdraw` +- **Models:** `Account`, `TransactionHistory` +- **Gherkin:** `gherkin_transact.feature` (`Withdraw funds`, `Withdrawal fails (insufficient funds)`, `Withdrawal validation`, `Unauthorized withdrawal`) + +--- + +## 8. Transfer + +### User Stories / Goals + +- As a user, I want to transfer money between my accounts or to another user's account. + +### Acceptance Criteria (from `gherkin_transact.feature`) + +- Source and destination accounts must both exist. +- User must own the source account. +- Sufficient funds must be available. +- Transfer amount must be valid and within limits. +- Transfers cannot be made to the same account. +- Only authenticated users can transfer. +- Appropriate errors for all validation failures. + +### Business Rules & Constraints + +- **Account Validation:** Both accounts must exist; source must belong to user. +- **Amount Validation:** Positive, present, within limits. +- **Edge Case:** Cannot transfer to the same account. +- **Sufficient Balance:** Source must cover the amount. +- **Authorization:** Only authenticated users. +- **Error Handling:** Errors for each failed check. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoint:** `/transact/transfer` +- **Models:** `TransferRequest`, `Account`, `TransactionHistory` +- **Gherkin:** `gherkin_transact.feature` (`Transfer funds`, `Transfer fails (insufficient funds)`, `Transfer fails (invalid accounts)`, `Transfer validation`, `Unauthorized transfer`) + +--- + +## 9. Payment + +### User Stories / Goals + +- As a user, I want to make payments from my account to payees. + +### Acceptance Criteria (from `gherkin_transact.feature`) + +- Payments require valid payee, amount, and user authorization. +- User must have sufficient funds. +- Payment amount must be positive and within limits. +- Only account owners can make payments. +- Only authenticated users. +- Errors returned for invalid payee, insufficient funds, or unauthorized actions. + +### Business Rules & Constraints + +- **Payee Validation:** Payee field required and must exist. +- **Amount Validation:** Required, positive, within limits. +- **Sufficient Balance:** User must have enough funds. +- **Ownership:** Account must belong to user. +- **Authorization:** User must be signed in. +- **Error Handling:** All validation failures return descriptive errors. + +### Actor Roles + +- Authenticated User + +### Covered by + +- **Endpoint:** `/transact/payment` +- **Models:** `PaymentRequest`, `Account`, `PaymentHistory` +- **Gherkin:** `gherkin_transact.feature` (`Make payment`, `Payment fails (invalid payee)`, `Payment fails (insufficient funds)`, `Payment validation`, `Unauthorized payment`) + +--- + +# Cross-References + +- All transaction endpoints (Deposit, Withdraw, Transfer, Payment) are restricted to authenticated users, account ownership is enforced, and amount input is validated. +- Transaction and Payment history endpoints are used to review actions completed in other business areas. +- Dashboard centralizes account-level data for the authenticated user. + +--- + +Each use case above references the concrete endpoints, models, and Gherkin scenario(s) demonstrating coverage. No requirements or interpretations have been inferred beyond the supplied evidence. diff --git a/Online-Banking-App-Spring-Boot/test_docs/test_coverage.md b/Online-Banking-App-Spring-Boot/test_docs/test_coverage.md new file mode 100644 index 0000000..086ee4d --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/test_coverage.md @@ -0,0 +1,91 @@ +--- +# Test Coverage Analysis & Recommendations + +This analysis details the current test coverage for the Digital Banking API system, strictly evidence-based. It summarizes what is validated by Gherkin test scenarios, identifies gaps/risks from endpoint-to-feature mapping, and prioritizes recommendations. All analysis cites the actual feature files and [Business Use Cases](business_use_cases.md) / [API Flows](api_flows.md). + +--- + +## 1. Coverage Summary + +### Endpoints & Business Logic Directly Verified + +**References:** +- Gherkin files: `gherkin_account.feature`, `gherkin_app.feature`, `gherkin_auth.feature`, `gherkin_transact.feature` +- Business Use Cases & API Flows ([see docs here](business_use_cases.md), [here](api_flows.md)) + +#### Account Management (`/account/create_account`) +- Success, duplicate, empty/missing, maximum, and invalid value creation all tested. +- Both happy and negative authorization paths (authenticated/unauthenticated) tested. + +#### Dashboard & Histories (`/app/dashboard`, `/app/payment_history`, `/app/transaction_history`, `/app/account_transaction_history`) +- Dashboard retrieval for users with 0, 1+, and large account sets. +- Payment/Transaction history: no history, some, large dataset; authenticated and unauthenticated paths (401), missing or invalid IDs (400/404). + +#### Authentication & Registration (`/login`, `/logout`, `/verify`, `/register`) +- Login: valid, invalid credentials, missing fields, malformed, unverified, server error. +- Logout: valid, missing/bad/expired tokens (401, 403). +- Registration: valid, missing, duplicate username, basic field validation. +- Verification: valid and expired token paths. + +#### Transactional (`/transact/deposit`, `/transact/withdraw`, `/transact/transfer`, `/transact/payment`) +- All flows: success, insufficient funds, ownership, amount field validation (missing, non-numeric, negative, empty). +- Special: Explicit checks for same-account transfer and payee validation. +- All paths test authorization and required field rejection. + +--- + +## 2. Coverage Gaps & Risks + +- **Account Management:** + - No evidence of tests for bulk deletes/updates (if supported). + - No explicit test for minimum/maximum allowed account IDs or for duplicate account_type per user beyond uniqueness error. + +- **Authentication & Registration:** + - No scenario for session/token expiry during active use or lockout after many failed logins. + - Password reset flows are not included (no endpoint in provided set). + +- **Dashboard / App Endpoints:** + - No scenarios for permission checks (multi-actor or admin type roles) or name boundary values for apps (e.g., max/min). + +- **Transactions:** + - Maximum allowed transaction or payment amount (upper bound) is not directly tested, nor are concurrent actions or business rate limits. + - No tests for malformed JSON, unexpected data types, or random field input beyond what's stated in Gherkin (e.g., unexpected extra fields). + - No test for pagination or segmented retrieval in histories (see large history, but not pagination). + +- **General Risks:** + - Absence of tests for rate-limiting or fraud detection (business and API perspective), which could lead to systemic risk. + - Potential for privilege escalation without explicit multi-actor or admin scenarios. + +--- + +## 3. Testing Recommendations + +### Critical (High-Risk, Directly Traceable) +- **Transactions:** + - Add test scenarios for zero/negative and maximum allowed amount values where not covered (see `gherkin_transact.feature`). + - Include high-frequency (rate) and fraud/abuse attempt flows (if supported by API). +- **Auth:** + - Add scenarios for session/token expiry while in use, and repeated failed logins (lockout/banning logic), covering all session edge states (`gherkin_auth.feature`). +- **Accounts:** + - Explicitly test min/max input lengths (account names/types), and for boundary account IDs (see business rules in [Business Use Cases](business_use_cases.md)). +- **General API:** + - Add tests for malformed requests, unexpected data types, and explicit error code assertions for more granular validation. + +### Moderate / General +- **Transaction & Payment History:** + - Add test cases for extremely large histories, pagination (if supported)—extend cases in `gherkin_app.feature`. +- **Role-based Access & Multi-actor:** + - Add scenarios for permissions, especially if any role beyond "authenticated user" exists in the business rules. + +### Low / Good Practice +- Check for duplicate account creation per (user, account_type), repeated deletion, and state after cascading changes. + +--- + +## References +- [Business Use Cases Documentation](business_use_cases.md) +- [API Flows Documentation](api_flows.md) +- Gherkin Features: `gherkin_account.feature`, `gherkin_app.feature`, `gherkin_auth.feature`, `gherkin_transact.feature` + +--- +**Summary**: All major flows are robustly covered by Gherkin tests with good success/error path balance for core endpoints. To fully mitigate system and business risk, explicit negative, edge, limits, role-permission, and advanced error scenarios should be added as prioritized above. \ No newline at end of file