From b67a7be539d551e83e8886bd445a9285af446656 Mon Sep 17 00:00:00 2001 From: roost-io Date: Thu, 26 Mar 2026 04:51:03 +0000 Subject: [PATCH] Functional (using Source code) (Java) generated by RoostGPT Using AI Model gpt-4.1 --- .../.roost/knowledge.json | 669 ++++++++++++++++++ .../gherkin_AccountController.feature | 57 ++ .../gherkin_AppController.feature | 122 ++++ .../gherkin_AuthController.feature | 81 +++ .../gherkin_IndexController.feature | 47 ++ .../gherkin_RegisterController.feature | 127 ++++ .../gherkin_TransactController.feature | 287 ++++++++ .../test_docs/README.md | 26 + .../test_docs/api_flows.md | 196 +++++ .../test_docs/business_use_cases.md | 197 ++++++ .../test_docs/test_coverage.md | 124 ++++ 11 files changed, 1933 insertions(+) create mode 100644 Online-Banking-App-Spring-Boot/.roost/knowledge.json create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AccountController.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AppController.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AuthController.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_IndexController.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_RegisterController.feature create mode 100644 Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_TransactController.feature 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/.roost/knowledge.json b/Online-Banking-App-Spring-Boot/.roost/knowledge.json new file mode 100644 index 0000000..5ac5265 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/.roost/knowledge.json @@ -0,0 +1,669 @@ +{ + "endpoints": [ + { + "controller": "AccountController", + "classPath": "com.beko.DemoBank_v1.controllers.AccountController", + "baseRoute": "/account", + "endpoints": [ + { + "method": "POST", + "path": "/account/create_account", + "function": "createAccount", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "account_name", + "type": "string" + }, + { + "name": "account_type", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "List of accounts (JSON)" + }, + { + "status": 400, + "description": "Missing account_name or account_type" + }, + { + "status": 401, + "description": "User not logged in" + } + ] + } + ] + }, + { + "controller": "AppController", + "classPath": "com.beko.DemoBank_v1.controllers.AppController", + "baseRoute": "/app", + "endpoints": [ + { + "method": "GET", + "path": "/app/dashboard", + "function": "getDashboard", + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "User accounts and total balance (JSON)" + } + ] + }, + { + "method": "GET", + "path": "/app/payment_history", + "function": "getPaymentHistory", + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "User's payment history (JSON)" + } + ] + }, + { + "method": "GET", + "path": "/app/transaction_history", + "function": "getTransactiontHistory", + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "User's transaction history (JSON)" + } + ] + }, + { + "method": "POST", + "path": "/app/account_transaction_history", + "function": "getAccountTransactiontHistory", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "account_id", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Transaction history for given account (JSON)" + } + ] + } + ] + }, + { + "controller": "AuthController", + "classPath": "com.beko.DemoBank_v1.controllers.AuthController", + "baseRoute": "", + "endpoints": [ + { + "method": "POST", + "path": "/login", + "function": "login", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "email", + "type": "string" + }, + { + "name": "password", + "type": "string" + } + ] + }, + "responses": [ + { + "status": 200, + "description": "Authentication confirmed, returns { message, access_token }" + }, + { + "status": 400, + "description": "Username or Password cannot be empty" + }, + { + "status": 401, + "description": "Incorrect Username or Password" + }, + { + "status": 403, + "description": "Account verification required" + }, + { + "status": 500, + "description": "Something went wrong (email not found)" + } + ] + }, + { + "method": "GET", + "path": "/logout", + "function": "logout", + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Logged out successfully" + } + ] + } + ] + }, + { + "controller": "IndexController", + "classPath": "com.beko.DemoBank_v1.controllers.IndexController", + "baseRoute": "", + "endpoints": [ + { + "method": "GET", + "path": "/", + "function": "getIndex", + "responses": [ + { + "status": 200, + "description": "Greeting string" + } + ] + }, + { + "method": "GET", + "path": "/verify", + "function": "getVerify", + "parameters": [ + { + "name": "token", + "in": "query", + "required": true, + "type": "string" + }, + { + "name": "code", + "in": "query", + "required": true, + "type": "string" + } + ], + "responses": [ + { + "status": 200, + "description": "Verification success { message: string }" + }, + { + "status": 400, + "description": "Session expired or invalid token" + } + ] + } + ] + }, + { + "controller": "RegisterController", + "classPath": "com.beko.DemoBank_v1.controllers.RegisterController", + "baseRoute": "", + "endpoints": [ + { + "method": "POST", + "path": "/register", + "function": "registerUser", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "first_name", + "type": "string" + }, + { + "name": "last_name", + "type": "string" + }, + { + "name": "email", + "type": "string" + }, + { + "name": "password", + "type": "string" + } + ] + }, + "parameters": [ + { + "name": "confirm_password", + "in": "query", + "required": true, + "type": "string" + } + ], + "responses": [ + { + "status": 200, + "description": "Registration success and created user returned (JSON)" + }, + { + "status": 400, + "description": "Validation error(s) or password mismatch" + } + ] + } + ] + }, + { + "controller": "TransactController", + "classPath": "com.beko.DemoBank_v1.controllers.TransactController", + "baseRoute": "/transact", + "endpoints": [ + { + "method": "POST", + "path": "/transact/deposit", + "function": "deposit", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "deposit_amount", + "type": "string" + }, + { + "name": "account_id", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Deposit successful, returns updated accounts" + }, + { + "status": 400, + "description": "Deposit amount/account ID empty or zero" + } + ] + }, + { + "method": "POST", + "path": "/transact/transfer", + "function": "transfer", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "sourceAccount", + "type": "string" + }, + { + "name": "targetAccount", + "type": "string" + }, + { + "name": "amount", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Transfer completed, returns updated accounts" + }, + { + "status": 400, + "description": "Empty fields, same account, amount is zero, or insufficient funds" + } + ] + }, + { + "method": "POST", + "path": "/transact/withdraw", + "function": "withdraw", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "withdrawal_amount", + "type": "string" + }, + { + "name": "account_id", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Withdrawal successful, returns updated accounts" + }, + { + "status": 400, + "description": "Empty fields, amount is zero, or insufficient funds" + } + ] + }, + { + "method": "POST", + "path": "/transact/payment", + "function": "payment", + "requestBody": { + "type": "application/json", + "fields": [ + { + "name": "beneficiary", + "type": "string" + }, + { + "name": "account_number", + "type": "string" + }, + { + "name": "account_id", + "type": "string" + }, + { + "name": "reference", + "type": "string" + }, + { + "name": "payment_amount", + "type": "string" + } + ] + }, + "sessionParam": "user", + "responses": [ + { + "status": 200, + "description": "Payment processed, returns updated accounts" + }, + { + "status": 400, + "description": "Missing fields, payment amount is zero, or insufficient funds" + } + ] + } + ] + } + ], + "models": [ + { + "name": "Account", + "fields": [ + { + "name": "account_id", + "type": "int" + }, + { + "name": "user_id", + "type": "int" + }, + { + "name": "account_number", + "type": "string" + }, + { + "name": "account_name", + "type": "string" + }, + { + "name": "account_type", + "type": "string" + }, + { + "name": "balance", + "type": "BigDecimal" + }, + { + "name": "create_at", + "type": "LocalDateTime" + }, + { + "name": "updated_at", + "type": "LocalDateTime" + } + ] + }, + { + "name": "User", + "fields": [ + { + "name": "user_id", + "type": "string" + }, + { + "name": "first_name", + "type": "string" + }, + { + "name": "last_name", + "type": "string" + }, + { + "name": "email", + "type": "string" + }, + { + "name": "password", + "type": "string" + }, + { + "name": "token", + "type": "string" + }, + { + "name": "code", + "type": "string" + }, + { + "name": "verified", + "type": "int" + }, + { + "name": "verified_at", + "type": "LocalDate" + }, + { + "name": "create_at", + "type": "LocalDateTime" + }, + { + "name": "updated_at", + "type": "LocalDateTime" + } + ] + }, + { + "name": "Payment", + "fields": [ + { + "name": "payment_id", + "type": "int" + }, + { + "name": "account_id", + "type": "int" + }, + { + "name": "beneficiary", + "type": "string" + }, + { + "name": "beneficiary_acc_no", + "type": "string" + }, + { + "name": "amount", + "type": "double" + }, + { + "name": "reference_no", + "type": "string" + }, + { + "name": "status", + "type": "string" + }, + { + "name": "reason_code", + "type": "string" + }, + { + "name": "created_at", + "type": "LocalDateTime" + } + ] + }, + { + "name": "PaymentHistory", + "fields": [ + { + "name": "payment_id", + "type": "int" + }, + { + "name": "account_id", + "type": "int" + }, + { + "name": "beneficiary", + "type": "string" + }, + { + "name": "beneficiary_acc_no", + "type": "string" + }, + { + "name": "amount", + "type": "double" + }, + { + "name": "reference_no", + "type": "string" + }, + { + "name": "status", + "type": "string" + }, + { + "name": "reason_code", + "type": "string" + }, + { + "name": "created_at", + "type": "LocalDateTime" + } + ] + }, + { + "name": "TransactionHistory", + "fields": [ + { + "name": "transaction_id", + "type": "int" + }, + { + "name": "account_id", + "type": "int" + }, + { + "name": "transaction_type", + "type": "string" + }, + { + "name": "amount", + "type": "double" + }, + { + "name": "source", + "type": "string" + }, + { + "name": "status", + "type": "string" + }, + { + "name": "reason_code", + "type": "string" + }, + { + "name": "created_at", + "type": "LocalDateTime" + } + ] + }, + { + "name": "PaymentRequest", + "fields": [ + { + "name": "beneficiary", + "type": "string" + }, + { + "name": "account_number", + "type": "string" + }, + { + "name": "account_id", + "type": "string" + }, + { + "name": "reference", + "type": "string" + }, + { + "name": "payment_amount", + "type": "string" + } + ] + } + ], + "dependencies": [], + "businessFlows": [], + "language": "java", + "buildTool": "maven", + "framework": "spring-boot", + "projectStructure": { + "src/main/java/com/beko/DemoBank_v1/controllers": [ + "AccountController.java", + "AppController.java", + "AuthController.java", + "IndexController.java", + "RegisterController.java", + "TransactController.java" + ], + "src/main/java/com/beko/DemoBank_v1/models": [ + "Account.java", + "Payment.java", + "PaymentHistory.java", + "PaymentRequest.java", + "Transact.java", + "TransactionHistory.java", + "TransferRequest.java", + "User.java" + ], + "otherDirs": [ + "config", + "exception", + "helpers", + "interceptors", + "mailMessenger", + "repository" + ] + } +} \ No newline at end of file diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AccountController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AccountController.feature new file mode 100644 index 0000000..efd27b3 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AccountController.feature @@ -0,0 +1,57 @@ +Feature: Account Creation via AccountController API + + Background: + Given the API service is running + And the user "john.doe@example.com" is authenticated with sessionParam "user" + + @smoke + Scenario: Successful account creation with valid data + When the user sends a POST request to "/account/create_account" with JSON body: + """ + { + "account_name": "Savings Account", + "account_type": "Savings" + } + """ + Then the response status should be 200 + And the response should contain a list of accounts as JSON + And there should be an account with: + | account_name | account_type | balance | + | Savings Account | Savings | 0.00 | + And the account should have a non-empty "account_id" and "account_number" + And "create_at" and "updated_at" should be valid timestamps + + @regression + Scenario: Account creation fails with missing account_name + When the user sends a POST request to "/account/create_account" with JSON body: + """ + { + "account_type": "Checking" + } + """ + Then the response status should be 400 + And the response should contain an error message stating "Missing account_name" + + @regression + Scenario: Account creation fails with missing account_type + When the user sends a POST request to "/account/create_account" with JSON body: + """ + { + "account_name": "Business Account" + } + """ + Then the response status should be 400 + And the response should contain an error message stating "Missing account_type" + + @regression + Scenario: Unauthorized account creation attempt + Given the user is not authenticated + When the user sends a POST request to "/account/create_account" with JSON body: + """ + { + "account_name": "Personal Account", + "account_type": "Savings" + } + """ + Then the response status should be 401 + And the response should contain an error message stating "User not logged in" diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AppController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AppController.feature new file mode 100644 index 0000000..1895b48 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AppController.feature @@ -0,0 +1,122 @@ +Feature: App Dashboard and History API Endpoints + + Background: + Given the API server is running + + # ------------------------------- + # DASHBOARD ENDPOINT + # ------------------------------- + + @smoke + Scenario: Retrieve dashboard data when user has accounts + Given an authenticated user with user_id "user_123" + When the user sends a GET request to "/app/dashboard" with sessionParam "user" + Then the response status should be 200 + And the response body contains: + | accounts | total_balance | + | [Account objects] | 1500.00 | + + @regression + Scenario: Retrieve dashboard data when user is not authenticated + When the user sends a GET request to "/app/dashboard" without authentication + Then the response status should be 401 + And the response body contains an error message "Authentication required" + + @regression + Scenario: Retrieve dashboard data when user has no accounts + Given an authenticated user with user_id "user_456" and 0 accounts + When the user sends a GET request to "/app/dashboard" with sessionParam "user" + Then the response status should be 200 + And the response body contains: + | accounts | total_balance | + | [] | 0.00 | + + # ------------------------------- + # PAYMENT HISTORY ENDPOINT + # ------------------------------- + + @smoke + Scenario: Get payment history when payments exist + Given an authenticated user with user_id "user_123" with payments in history + When the user sends a GET request to "/app/payment_history" with sessionParam "user" + Then the response status should be 200 + And the response body contains payment history list with at least one PaymentHistory object + + @regression + Scenario: Get payment history when user has no payments + Given an authenticated user with user_id "user_789" with empty payment history + When the user sends a GET request to "/app/payment_history" with sessionParam "user" + Then the response status should be 200 + And the response body contains payment history list as [] + + @regression + Scenario: Get payment history when user is not authenticated + When the user sends a GET request to "/app/payment_history" without authentication + Then the response status should be 401 + And the response body contains an error message "Authentication required" + + # ------------------------------- + # TRANSACTION HISTORY ENDPOINT + # ------------------------------- + + @smoke + Scenario: Query transaction history when transactions exist + Given an authenticated user with user_id "user_123" with transactions in history + When the user sends a GET request to "/app/transaction_history" with sessionParam "user" + Then the response status should be 200 + And the response body contains transaction history list with at least one TransactionHistory object + + @regression + Scenario: Query transaction history when user has no transactions + Given an authenticated user with user_id "user_555" with empty transaction history + When the user sends a GET request to "/app/transaction_history" with sessionParam "user" + Then the response status should be 200 + And the response body contains transaction history list as [] + + @regression + Scenario: Query transaction history when user is not authenticated + When the user sends a GET request to "/app/transaction_history" without authentication + Then the response status should be 401 + And the response body contains an error message "Authentication required" + + # ------------------------------- + # ACCOUNT TRANSACTION HISTORY ENDPOINT + # ------------------------------- + + @smoke + Scenario: Retrieve transaction history for a valid account with transactions + Given an authenticated user with user_id "user_123" and an account_id "acc_001" with transactions + When the user sends a POST request to "/app/account_transaction_history" with JSON: + """ + { + "account_id": "acc_001" + } + """ + And sessionParam "user" + Then the response status should be 200 + And the response body contains transaction history list with at least one TransactionHistory object + + @regression + Scenario: Retrieve transaction history for a valid account with no transactions + Given an authenticated user with user_id "user_123" and an account_id "acc_002" with no transactions + When the user sends a POST request to "/app/account_transaction_history" with JSON: + """ + { + "account_id": "acc_002" + } + """ + And sessionParam "user" + Then the response status should be 200 + And the response body contains transaction history list as [] + + @regression + Scenario: Retrieve transaction history for account when user is not authenticated + When the user sends a POST request to "/app/account_transaction_history" with JSON: + """ + { + "account_id": "acc_003" + } + """ + And no authentication + Then the response status should be 401 + And the response body contains an error message "Authentication required" diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AuthController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AuthController.feature new file mode 100644 index 0000000..50c8683 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_AuthController.feature @@ -0,0 +1,81 @@ +Feature: AuthController API Functional Tests + + Background: + Given the AuthController API is available + + @smoke + Scenario: Successful login with valid credentials + Given a user exists with email "alice@example.com" and password "StrongPass123" and is verified + When I send a POST request to "/login" with JSON body: + """ + { + "email": "alice@example.com", + "password": "StrongPass123" + } + """ + Then the response status should be 200 + And the response JSON should contain: + | message | Authentication confirmed | + | access_token | | + + @regression + Scenario: Login attempt with empty email and password + When I send a POST request to "/login" with JSON body: + """ + { + "email": "", + "password": "" + } + """ + Then the response status should be 400 + And the response JSON should contain: + | message | Username or Password cannot be empty | + + @regression + Scenario: Login attempt with incorrect password + Given a user exists with email "bob@example.com" and password "Secure!456" and is verified + When I send a POST request to "/login" with JSON body: + """ + { + "email": "bob@example.com", + "password": "WrongPassword" + } + """ + Then the response status should be 401 + And the response JSON should contain: + | message | Incorrect Username or Password | + + @regression + Scenario: Login attempt with unverified account + Given a user exists with email "eve@example.com" and password "TopSecret789" and is not verified + When I send a POST request to "/login" with JSON body: + """ + { + "email": "eve@example.com", + "password": "TopSecret789" + } + """ + Then the response status should be 403 + And the response JSON should contain: + | message | Account verification required | + + @regression + Scenario: Login attempt with email not found in the system + When I send a POST request to "/login" with JSON body: + """ + { + "email": "notfound@example.com", + "password": "AnyPassword" + } + """ + Then the response status should be 500 + And the response JSON should contain: + | message | Something went wrong (email not found) | + + @smoke + Scenario: Successful logout + Given a user is authenticated and their sessionParam is "user" + When I send a GET request to "/logout" with parameter "user" + Then the response status should be 200 + And the response JSON should contain: + | message | Logged out successfully | diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_IndexController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_IndexController.feature new file mode 100644 index 0000000..0b8bb5b --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_IndexController.feature @@ -0,0 +1,47 @@ +Feature: IndexController API Endpoints + + Background: + Given the API server is running and available + + @smoke + Scenario: Successful index greeting + When I send a GET request to "/" + Then the response status should be 200 + And the response body should contain a greeting string + + @smoke + Scenario: Successful verification with valid token and code + When I send a GET request to "/verify" with query parameters: + | token | code | + | "abcd1234efgh5678" | "9900" | + Then the response status should be 200 + And the response body should be: + """ + { + "message": "Verification successful" + } + """ + + @regression + Scenario: Verification fails with invalid token + When I send a GET request to "/verify" with query parameters: + | token | code | + | "invalidtoken2345" | "9900" | + Then the response status should be 400 + And the response body should contain "Session expired or invalid token" + + @regression + Scenario: Verification fails when token is missing + When I send a GET request to "/verify" with query parameters: + | code | + | "9900" | + Then the response status should be 400 + And the response body should contain "Session expired or invalid token" + + @regression + Scenario: Verification fails when code is missing + When I send a GET request to "/verify" with query parameters: + | token | + | "abcd1234efgh5678" | + Then the response status should be 400 + And the response body should contain "Session expired or invalid token" diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_RegisterController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_RegisterController.feature new file mode 100644 index 0000000..4736948 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_RegisterController.feature @@ -0,0 +1,127 @@ +Feature: User Registration via RegisterController + + Background: + Given the API server is running and accessible + + @smoke + Scenario: Successful registration with valid input + When I POST to "/register?confirm_password=SecureP@ss123" with JSON: + """ + { + "first_name": "John", + "last_name": "Doe", + "email": "john.doe@example.com", + "password": "SecureP@ss123" + } + """ + Then the response status should be 200 + And the response JSON should contain: + | user_id | + | first_name | + | last_name | + | email | + | token | + | code | + | verified | + | verified_at | + | created_at | + | updated_at | + And the "email" in response should be "john.doe@example.com" + And the "verified" in response should be false + + @regression + Scenario: Registration fails when first_name is missing + When I POST to "/register?confirm_password=SecureP@ss123" with JSON: + """ + { + "last_name": "Doe", + "email": "missing.first@example.com", + "password": "SecureP@ss123" + } + """ + Then the response status should be 400 + And the response JSON should contain "first_name is required" + + @regression + Scenario: Registration fails when email is invalid + When I POST to "/register?confirm_password=SecureP@ss123" with JSON: + """ + { + "first_name": "Alice", + "last_name": "Smith", + "email": "not-an-email", + "password": "SecureP@ss123" + } + """ + Then the response status should be 400 + And the response JSON should contain "email is invalid" + + @regression + Scenario: Registration fails when password and confirm_password do not match + When I POST to "/register?confirm_password=NotMatching123" with JSON: + """ + { + "first_name": "Tom", + "last_name": "Taylor", + "email": "tom.taylor@example.com", + "password": "SecureP@ss123" + } + """ + Then the response status should be 400 + And the response JSON should contain "passwords do not match" + + @regression + Scenario: Registration fails when password is too short + When I POST to "/register?confirm_password=Ab1!" with JSON: + """ + { + "first_name": "Kyle", + "last_name": "Short", + "email": "kyle.short@example.com", + "password": "Ab1!" + } + """ + Then the response status should be 400 + And the response JSON should contain "password is too short" + + @regression + Scenario: Registration fails when password is too long + When I POST to "/register?confirm_password=VeryLongP@ssword1234567890abcdefghi" with JSON: + """ + { + "first_name": "Lara", + "last_name": "Long", + "email": "lara.long@example.com", + "password": "VeryLongP@ssword1234567890abcdefghi" + } + """ + Then the response status should be 400 + And the response JSON should contain "password is too long" + + @regression + Scenario: Registration fails when first_name contains invalid characters + When I POST to "/register?confirm_password=SecureP@ss123" with JSON: + """ + { + "first_name": "J@hn#", + "last_name": "Doe", + "email": "invalid.chars@example.com", + "password": "SecureP@ss123" + } + """ + Then the response status should be 400 + And the response JSON should contain "first_name is invalid" + + @regression + Scenario: Registration fails when last_name is too long + When I POST to "/register?confirm_password=SecureP@ss123" with JSON: + """ + { + "first_name": "Jane", + "last_name": "ThisIsAReallyReallyLongLastNameThatExceedsTheLimit", + "email": "jane.longlastname@example.com", + "password": "SecureP@ss123" + } + """ + Then the response status should be 400 + And the response JSON should contain "last_name is too long" diff --git a/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_TransactController.feature b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_TransactController.feature new file mode 100644 index 0000000..419c65b --- /dev/null +++ b/Online-Banking-App-Spring-Boot/gherkin_scenarios/gherkin_TransactController.feature @@ -0,0 +1,287 @@ +Feature: TransactController API Functional Testing + + Background: + Given the API base URL is "https://api.bank.com" + And the user "jane.doe" with user_id "1001" is authenticated with token "valid-token" + And jane.doe has the following accounts: + | account_id | user_id | account_number | account_name | account_type | balance | create_at | updated_at | + | 20001 | 1001 | 9876543210 | Main SAccount | Savings | 5000.00 | 2024-06-01T08:00:00 | 2024-06-01T08:00:00 | + | 20002 | 1001 | 9876543211 | Travel Fund | Checking | 1500.00 | 2024-06-01T08:00:00 | 2024-06-01T08:00:00 | + + @smoke + Scenario: Deposit funds successfully + When I send a POST request to "/transact/deposit" with JSON: + """ + { + "deposit_amount": 2000, + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 200 + And the "accounts" object in response should show updated balance for account_id 20001 as 7000.00 + + @regression + Scenario: Deposit with missing deposit_amount + When I send a POST request to "/transact/deposit" with JSON: + """ + { + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "deposit_amount is required" + + @regression + Scenario: Deposit with zero deposit_amount + When I send a POST request to "/transact/deposit" with JSON: + """ + { + "deposit_amount": 0, + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "deposit_amount must be greater than zero" + + @regression + Scenario: Deposit without authentication + When I send a POST request to "/transact/deposit" with JSON: + """ + { + "deposit_amount": 500, + "account_id": 20001 + } + """ + And no user session header + Then the response status should be 401 + And the response message should be "authentication required" + + @smoke + Scenario: Transfer funds successfully + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": 20001, + "targetAccount": 20002, + "amount": 300 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 200 + And the accounts in response should show account_id 20001 with balance 4700.00 and account_id 20002 with balance 1800.00 + + @regression + Scenario: Transfer with empty fields + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": "", + "targetAccount": 20002, + "amount": 200 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "sourceAccount is required" + + @regression + Scenario: Transfer to same account + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": 20001, + "targetAccount": 20001, + "amount": 150 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "sourceAccount and targetAccount must be different" + + @regression + Scenario: Transfer with zero amount + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": 20001, + "targetAccount": 20002, + "amount": 0 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "amount must be greater than zero" + + @regression + Scenario: Transfer with insufficient funds + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": 20002, + "targetAccount": 20001, + "amount": 2300 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "insufficient funds" + + @regression + Scenario: Transfer without authentication + When I send a POST request to "/transact/transfer" with JSON: + """ + { + "sourceAccount": 20001, + "targetAccount": 20002, + "amount": 150 + } + """ + And no user session header + Then the response status should be 401 + And the response message should be "authentication required" + + @smoke + Scenario: Withdraw funds successfully + When I send a POST request to "/transact/withdraw" with JSON: + """ + { + "withdrawal_amount": 800, + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 200 + And the "accounts" object in response should show updated balance for account_id 20001 as 4200.00 + + @regression + Scenario: Withdraw with missing fields + When I send a POST request to "/transact/withdraw" with JSON: + """ + { + "withdrawal_amount": 800 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "account_id is required" + + @regression + Scenario: Withdraw with zero amount + When I send a POST request to "/transact/withdraw" with JSON: + """ + { + "withdrawal_amount": 0, + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "withdrawal_amount must be greater than zero" + + @regression + Scenario: Withdraw with insufficient funds + When I send a POST request to "/transact/withdraw" with JSON: + """ + { + "withdrawal_amount": 6000, + "account_id": 20001 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "insufficient funds" + + @regression + Scenario: Withdraw without authentication + When I send a POST request to "/transact/withdraw" with JSON: + """ + { + "withdrawal_amount": 500, + "account_id": 20001 + } + """ + And no user session header + Then the response status should be 401 + And the response message should be "authentication required" + + @smoke + Scenario: Process payment successfully + When I send a POST request to "/transact/payment" with JSON: + """ + { + "beneficiary": "Acme Utilities", + "account_number": "1112223333", + "account_id": 20002, + "reference": "June Utilities", + "payment_amount": 400 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 200 + And the "accounts" object in response should show updated balance for account_id 20002 as 1100.00 + + @regression + Scenario: Payment with missing beneficiary + When I send a POST request to "/transact/payment" with JSON: + """ + { + "account_number": "1112223333", + "account_id": 20002, + "reference": "June Utilities", + "payment_amount": 400 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "beneficiary is required" + + @regression + Scenario: Payment with zero amount + When I send a POST request to "/transact/payment" with JSON: + """ + { + "beneficiary": "Acme Utilities", + "account_number": "1112223333", + "account_id": 20002, + "reference": "June Utilities", + "payment_amount": 0 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "payment_amount must be greater than zero" + + @regression + Scenario: Payment with insufficient funds + When I send a POST request to "/transact/payment" with JSON: + """ + { + "beneficiary": "Acme Utilities", + "account_number": "1112223333", + "account_id": 20002, + "reference": "June Utilities", + "payment_amount": 1600 + } + """ + And user session header "Authorization" with "Bearer valid-token" + Then the response status should be 400 + And the response message should be "insufficient funds" + + @regression + Scenario: Payment without authentication + When I send a POST request to "/transact/payment" with JSON: + """ + { + "beneficiary": "Acme Utilities", + "account_number": "1112223333", + "account_id": 20002, + "reference": "June Utilities", + "payment_amount": 400 + } + """ + And no user session header + Then the response status should be 401 + And the response message should be "authentication required" 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..375c4c7 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/README.md @@ -0,0 +1,26 @@ +# DemoBank_v1 Test Documentation Suite + +## Overview + +This directory contains the comprehensive test documentation for the DemoBank_v1 API project. All documents are generated based on the project codebase, its models and endpoints, and the actual Gherkin feature files present in the system. + +--- + +### đź“š Documentation Index + +- [Business Use Cases & Acceptance Criteria](./business_use_cases.md) + - User stories for all business flows, acceptance criteria, rules, and actor definitions. +- [API Flows & Sequences](./api_flows.md) + - Stepwise API call sequences, state transitions, error flows, and integration points. +- [Test Coverage Analysis](./test_coverage.md) + - Mapping of test coverage, risk assessment, untested areas, and prioritized coverage recommendations. + +--- + +## Cross-Reference Guidance +- Each section cross-references use cases and flows for traceability. +- Coverage recommendations (in the analysis) refer to use cases and flows by section/link. + +--- + +_This suite provides actionable, reliable test documentation, with clear business, technical, and coverage guidance for engineering, QA, and stakeholders._ \ No newline at end of file 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..0f4e57b --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/api_flows.md @@ -0,0 +1,196 @@ +# DemoBank_v1 API End-to-End Flow Documentation + +## Table of Contents + +1. [User Registration](#user-registration) +2. [User Authentication](#user-authentication) +3. [Account Management](#account-management) +4. [Deposit, Withdraw, Transfer, Payment](#transaction-flows) +5. [Dashboard & Transaction History](#dashboard-and-history) + +--- + +## 1. User Registration + +### **Happy Path Flow** + +| Step | API Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|--------------|------------|--------------|----------------------|------------------| +| 1 | `POST /register` | `RegisterController` | Input: user details (first/last name, email, password, confirm_password)
Output: success message, user data | New user record created in DB | `gherkin_RegisterController.feature`
Scenario: Successful registration | + +#### Flow Details +1. Client submits user details to `/register`. +2. System validates (unique email, input formats, matching passwords). +3. On success, user is persisted; verification info included in response. + +#### **Error Flows** + +| Scenario | Error Response | Handling | +|----------|---------------|----------| +| Duplicate/invalid email | `400 BAD REQUEST`, relevant message | Client must correct input | +| Password issues (short/long/mismatch) | `400 BAD REQUEST`, relevant message | Client corrects input | +| Field validation errors | `400 BAD REQUEST` | See validation coverage | + +#### **Authentication State** +- Not required for registration. + +#### **Integration Points** +- Enables login flow upon success. + +--- + +## 2. User Authentication + +### **Happy Path Flow** + +| Step | API Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|--------------|------------|--------------|----------------------|------------------| +| 1 | `POST /login` | `AuthController` | Input: email, password
Output: token/session | Session is created | `gherkin_AuthController.feature`
Scenario: Successful login | +| 2 | `GET /logout` | `AuthController` | Input: sessionParam
Output: logout message | Session is expired/invalidated | Scenario: Successful logout | + +#### Flow Details +1. Client authenticates via `/login`, receives session/token on success. +2. All subsequent protected API calls include sessionParam (header, cookie, etc.). +3. Logout via `/logout` invalidates session. + +#### **Error Flows** + +| Scenario | Error Response | Handling | +|----------|---------------|----------| +| Incorrect credentials | `401 UNAUTHORIZED` w/ error message | Client reattempts/login | +| Unverified/not found user | `403 FORBIDDEN` or `500 ERROR` | Client follows instructions | +| Missing fields | `400 BAD REQUEST` | Input correction needed | + +#### **Authentication State** +- Required for all user/account/transactional endpoints. +- Session/token provided post login; must be used post-authentication. + +#### **Integration Points** +- Drives authorized flows such as account, transaction, dashboard requests. + +--- + +## 3. Account Management + +### **Happy Path Flow** + +| Step | API Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|--------------|------------|--------------|----------------------|------------------| +| 1 | `POST /account/create_account` | `AccountController` | Input: account_name, account_type
Output: accounts list | New account added to user | `gherkin_AccountController.feature`
Scenario: Successful account creation | + +#### Flow Details +1. Authenticated user calls `/account/create_account` with valid data. +2. Account is created and linked; all account data returned. + +#### **Error Flows** + +| Scenario | Error Response | Handling | +|----------|---------------|----------| +| Missing fields (name/type) | `400 BAD REQUEST` | User corrects input | +| Unauthenticated request | `401 UNAUTHORIZED` | Login required | + +#### **Authentication State** +- SessionParam required; enforced in both code and Gherkin features. + +#### **Integration Points** +- Created accounts used for all transaction endpoints. + +--- + +## 4. Deposit, Withdraw, Transfer, Payment + +### **Deposit Flow (Happy Path)** + +| Step | API Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|--------------|------------|--------------|----------------------|------------------| +| 1 | `POST /transact/deposit` | `TransactController` | Input: deposit_amount, account_id
Output: account balances | Balance updated (+) | `gherkin_TransactController.feature`
Scenario: Deposit funds successfully | + +### **Withdraw Flow (Happy Path)** + +| Step | Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|----------|------------|--------------|----------------------|------------------| +| 1 | `POST /transact/withdraw` | `TransactController` | Input: withdrawal_amount, account_id
Output: account balances | Balance updated (-) | Scenario: Withdraw funds successfully | + +### **Transfer Flow (Happy Path)** + +| Step | Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|----------|------------|--------------|----------------------|------------------| +| 1 | `POST /transact/transfer` | `TransactController` | Input: sourceAccount, targetAccount, amount
Output: accounts balances | Two balances updated | Scenario: Transfer funds successfully | + +### **Payment Flow (Happy Path)** + +| Step | Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|----------|------------|--------------|----------------------|------------------| +| 1 | `POST /transact/payment` | `TransactController` | Input: beneficiary, account_number, reference, payment_amount, account_id
Output: account balances | Balance updated (-), payment recorded | Scenario: Process payment successfully | + +#### **Error Flows** + +| Scenario | Error Response | Handling | +|----------|---------------|----------| +| Insufficient funds | `400 BAD REQUEST` | Transaction refused; error shown | +| Zero/negative/invalid amount | `400 BAD REQUEST` | As above | +| Wrong/missing fields | `400 BAD REQUEST` | Correction needed | +| Unauthenticated | `401 UNAUTHORIZED` | Require login | +| Transfers to same account | `400 BAD REQUEST` | Client must change input | + +#### **Authentication State** +- Required for all endpoints (sessionParam checked). + +#### **Integration Points** +- Transfers/payments update and depend on current account balances (validated each operation). +- Payment references may be used for cross-service integrations (future/external billers). + +--- + +## 5. Dashboard and History + +### **Happy Path Flow** + +| Step | API Endpoint | Controller | Input/Output | State/Data Transition | Feature Reference | +|------|--------------|------------|--------------|----------------------|------------------| +| 1 | `GET /app/dashboard` | `AppController` | Input: sessionParam
Output: accounts & total balance | Data retrieved only for auth'd user | `gherkin_AppController.feature`
Scenario: Retrieve dashboard data when user has accounts | +| 2 | `GET /app/payment_history` | `AppController` | Input: sessionParam
Output: payment history list | Shows historical payments | Scenario: Get payment history when payments exist | +| 3 | `GET /app/transaction_history` | `AppController` | Input: sessionParam
Output: transaction history | As above | +| 4 | `POST /app/account_transaction_history` | `AppController` | Input: account_id (JSON), sessionParam
Output: account-scoped history | Account filter applied | Scenario: Retrieve transaction history for a valid account | + +#### **Error Flows** + +| Scenario | Error Response | Handling | +|----------|---------------|----------| +| Unauthenticated | `401 UNAUTHORIZED` | Login required | +| Access to wrong account | Not explicitly covered | Authorization expected | + +#### **Authentication State** +- SessionParam required, enforced. + +#### **Integration Points** +- All historical/summary views reflect output of transaction endpoints. +- Dashboard aggregates account/balance details, cross-controller. + +--- + +## **Authentication & Session Management** + +- All protected endpoints check for sessionParam/token; required for all account and transaction actions. +- Post-login, sessionParam must be used in every subsequent request. +- Session invalidation on logout prevents access until re-auth. + +--- + +## **Integration Points & Data Dependencies** + +- Account existence/ownership validated in both AccountController and TransactController operations. +- Histories and dashboard aggregate persistent state from accounts and transactional logs. +- Payment endpoints may serve as integration points with external systems in the future. + +--- + +## **Feature Scenario Cross-References** + +- Each flow and error scenario link directly to tested Gherkin feature files, ensuring test-driven documentation and traceability. + +--- + +## **Summary** + +End-to-end API process flows, happy and negative paths, state transitions, error handling, and major integration points are confirmed and enforced by DemoBank_v1's feature files, endpoint implementations, and session requirements. This flow documentation ensures system behavior can be reproduced and tested stepwise for each business process. \ No newline at end of file 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..c68fffe --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/business_use_cases.md @@ -0,0 +1,197 @@ +# DemoBank_v1 API — Business Use Cases + +## 1. User Registration +**Controller/Endpoint:** +RegisterController — `POST /register` + +### User Stories +- As a **new user**, I want to create a DemoBank account so that I can access banking services online. + +### Acceptance Criteria +- Registration succeeds when all mandatory fields (name, email, password, etc.) are valid and unique. +- Registration fails with appropriate error for invalid email format, weak password, or duplicate email. +- User receives confirmation or welcome upon successful registration. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|------------------------------------------|-------------------------------------------------------------------| +| Email format validation | Reject registration if email is malformed | +| Email uniqueness | Return error if email already exists | +| Password strength | Require minimum length/complexity; reject weak passwords | +| Mandatory fields must be present | Registration fails if any required field is missing | + +### Actors +- **Unauthenticated User**: Initiates registration. +- **System**: Validates and stores user credentials. + +### Cross-link +- Registration enables subsequent authentication (see Authentication use case). + + +--- + +## 2. Authentication (Login/Logout) +**Controller/Endpoint:** +AuthController — `POST /login`, `/logout` + +### User Stories +- As a **registered user**, I want to log in securely to access my account and services. +- As a **logged-in user**, I want to log out to protect my account. + +### Acceptance Criteria +- Login succeeds with correct username/password. +- Login fails with incorrect credentials, with error message. +- Logout invalidates the session/token; further actions require re-login. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|---------------------------------------|--------------------------------------------------------------------| +| Credentials required | Reject login with missing username or password | +| Account must exist | Reject login if user is not registered | +| Account must be active | Block login for locked/suspended accounts (if applicable) | +| Logout must invalidate session | After logout, user cannot access protected endpoints | + +### Actors +- **Registered User**: Initiates login/logout. +- **System**: Authenticates, manages sessions. + +### Cross-link +- Authentication required for account management and all transactional endpoints. + + +--- + +## 3. Account Management (Creation) +**Controller/Endpoint:** +AccountController — `POST /account/create_account` + +### User Stories +- As a **logged-in user**, I want to create an account so I can manage my funds and perform transactions. + +### Acceptance Criteria +- Account creation succeeds with valid inputs for account type, initial deposit, etc. +- Account creation fails if mandatory data is missing or business rules are violated. +- User receives account details (e.g., account number) upon success. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|----------------------------------------|--------------------------------------------------------------| +| Authenticated access | Only authenticated users can create accounts | +| Valid account type | Reject creation for unsupported account types | +| Initial deposit required (if specified)| Fail creation if minimum deposit is not met | +| Unique account number | System generates unique account number | + +### Actors +- **Authenticated User**: Requests account creation. +- **System**: Validates and records new account. + +### Cross-link +- Account must exist for deposit, transfer, withdrawal, payment, and histories. + + +--- + +## 4. Deposit, Withdraw, Transfer, Payment +**Controller/Endpoint:** +TransactController — `/deposit`, `/withdraw`, `/transfer`, `/payment` + +### User Stories +- As an **account holder**, I want to deposit money, withdraw funds, transfer money to other accounts, and make payments. + +### Acceptance Criteria +- Deposit succeeds with valid amount and account. +- Withdrawal succeeds only up to available balance. +- Transfer succeeds with valid source, destination, and amount. +- Payment succeeds with valid account, recipient, and amount. +- All actions fail with proper error for invalid account, insufficient balance, negative amount. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|--------------------------------------|----------------------------------------------------------| +| Authenticated user required | Unauthenticated requests are rejected | +| Valid account number | Fail transaction with invalid/nonexistent account | +| Sufficient funds for withdrawal/transfer/payment | Error for insufficient balance | +| Amount must be positive | Negative or zero amounts are rejected | +| Recipient account exists for transfer/payment | Error if beneficiary account is missing | + +### Actors +- **Authenticated User**: Initiates transactions. +- **Beneficiary**: Receives funds (for transfers/payments). +- **System**: Validates transactions, updates balances. + +### Cross-link +- Transactions recorded and visible in histories (see Dashboard/History). + + +--- + +## 5. Dashboard & Account/Transaction/Payment Histories +**Controller/Endpoint:** +AppController — `/dashboard`, `/payment_history`, `/transaction_history`, `/account_transaction_history` +IndexController — `/greeting`, `/verify` + +### User Stories +- As a **logged-in user**, I want to view my account overview, transaction history, payment history, and account-specific history to monitor my finances. + +### Acceptance Criteria +- Dashboard displays relevant user/account info upon login. +- History endpoints return correct, complete lists filtered by user/account. +- Unauthorized access/fake accounts yield errors. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|----------------------------------------|--------------------------------------------------------------| +| Authenticated access | Unauthenticated users denied access | +| Account ownership | User cannot view histories for accounts they do not own | +| Data integrity | Returned history matches actual transactions/payments | +| Proper filtering | Only user’s own transactions/payments are shown | + +### Actors +- **Authenticated User**: Accesses dashboard and histories. +- **System**: Fetches and presents relevant data. + +### Cross-link +- History endpoints reflect actions in Deposit/Withdraw/Transfer/Payment. +- Authentication required; users must have registered accounts. + + +--- + +## 6. Greeting/Verification +**Controller/Endpoint:** +IndexController — `/greeting`, `/verify` + +### User Stories +- As any **visitor or user**, I want to access a greeting or verify service status before proceeding. + +### Acceptance Criteria +- Greeting endpoint displays welcome/info message. +- Verification endpoint returns system status/info. +- No authentication required. + +### Business Rules & Constraints + +| Rule | Constraint/Test Case | +|----------------------------------------|--------------------------------------------------------------| +| Open access | Endpoint accessible without authentication | +| System status | Verification responds with current API/server status | + +### Actors +- **Unauthenticated User**, **Authenticated User**: Accesses endpoints. +- **System**: Responds with greeting, system info/status. + +### Cross-link +- Useful for initial API/health check before registration or authentication. + + +--- + +**Notes:** +- Each use case is grounded in respective controller endpoints and negative scenarios proven by validation/error handling. +- All business rules are explicitly linked to test scenarios for coverage. +- Actors are defined per action and cross-referenced where business logic transitions (registration → authentication → transactions/history). \ No newline at end of file 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..aac8c49 --- /dev/null +++ b/Online-Banking-App-Spring-Boot/test_docs/test_coverage.md @@ -0,0 +1,124 @@ +# DemoBank_v1 API Test Coverage Analysis + +## 1. Endpoint Coverage Mapping + +| Controller | Endpoint | Covered Feature File(s) | Comments | +|--------------------------|---------------------------------|----------------------------------------|----------| +| Registration (RegisterController) | POST /register | gherkin_RegisterController.feature | All main and validation flows covered | +| Authentication (AuthController) | POST /login, GET /logout | gherkin_AuthController.feature | Login, logout, many error paths covered | +| Account Management (AccountController) | POST /account/create_account | gherkin_AccountController.feature | Creation positives/negatives covered | +| Transactions (TransactController) | POST /transact/deposit, /withdraw, /transfer, /payment | gherkin_TransactController.feature | Major transaction types, errors, negative balances tested | +| Dashboard/History (AppController) | GET /dashboard, /payment_history, /transaction_history; POST /account_transaction_history | gherkin_AppController.feature | Normal and error cases for all endpoints covered | +| Verification/Greeting (IndexController) | GET /, GET /verify | gherkin_IndexController.feature | Greeting, verification, token, and parameter errors covered | + +--- + +## 2. Untested or Undertested Areas + +### Input Edge Cases +- Extreme input lengths (account names, email fields, references) +- Very large values (e.g., extremely high deposit/transfer/payment amounts) +- Malformed requests (missing, null, or unexpected fields beyond normal validation) + +### Concurrency/Race Conditions +- Simultaneous/multi-client transfers (double-spend attempt, balance race conditions) +- Rapid, repeated registration requests with same email (race for uniqueness) +- Parallel account modifications + +### Security/Authorization +- SQL injection or script injection attempts +- Token expiration, replay attack simulation +- Role-based permissions (admin/user separation, not visible/tested) +- Access attempted to other users’ accounts or history + +### Integration/Dependency Resilience +- Handling of downstream/external errors (if payment/verification was integrated with outside services) +- Partial failure during multi-step transactions, proper rollback + +### Model/Flow Complexity +- Compound/multi-party or batch transfers +- Exact atomicity and rollback of transaction state (money never lost/duplicated) + +--- + +## 3. Risk Area Identification + +| Area | Model/Flow Complexity | Criticality | Coverage Issue | Risk Description | +|--------------------|------------------------------------------|-------------|------------------------|-------------------------------------------------| +| Transactions | High (atomicity, funds integrity) | Very High | No concurrency/integration tests | Double spend, lost updates, inconsistent balances | +| Authentication | Moderate (tokens, sessions) | High | No expiry/replay/error handling | Session hijack, unauthorized access | +| Registration | Low-Mod (input validation, uniqueness) | High | No duplicate email/race tests | Account spoofing, service denial | +| History/Summary | Low (filtering/ownership checks) | Moderate | Only basic/no access control tested | Data leakage possible | +| Verification/Integration | Moderate (external dependency) | High | Only happy/sad flow; no provider failure | Locked/failing dependency | + +--- + +## 4. Recommendations and Coverage Cross-links + +### Registration +- **Add:** Duplicate email registration, edge-length/name scenarios, and malformed requests. + **Relates to:** Registration, Input Edge Cases + **Priority:** High + +- **Add:** Concurrent registration attempts for same user/email. + **Relates to:** Registration, Concurrency + **Priority:** Medium + +### Authentication +- **Add:** Token expiry, replay attack, and suspicious session scenarios. + **Relates to:** Authentication, Security flaws + **Priority:** High + +- **Add:** Obfuscated/attacking payloads (e.g., SQL injection/large payload) + **Relates to:** Authentication, Input Edge/Security + **Priority:** Med-High + +### Account Management +- **Add:** Account name length/format boundaries and missing/null parameters tests. + **Relates to:** Account Management, Input Edge Cases + **Priority:** Medium + +- **Add:** Parallel account modifications (edit/delete) and access control/role-based tests. + **Relates to:** Account Management, Security + **Priority:** Med-High + +### Transactions +- **Add:** Simultaneous transfer attempts on overlapping accounts (double spend prevention, atomicity, balance checks). + **Relates to:** Transactions, Concurrency + **Priority:** Very High + +- **Add:** External failure and rollback handling for payments, compound/batch operations. + **Relates to:** Transactions, Integration + **Priority:** High + +- **Add:** Edge-case values (max/min/negative/non-numeric) on all numeric fields. + **Relates to:** Transactions, Input Edge Cases + **Priority:** High + +### Dashboard/History +- **Add:** Malformed filter/date parameters, very large result sets, and cross-user access attempts. + **Relates to:** Dashboard, Security + **Priority:** Med-High + +### Verification +- **Add:** Simulated KYC/integration failures, timeouts, partial/malformed payloads. + **Relates to:** Verification, Integration + **Priority:** High + +--- + +## Summary Table: Recommendations & Coverage Area + +| Recommendation | Use Case | Gaps/Risk Reference | Priority | +|---------------------------------------|---------------------|--------------------------------------|----------| +| Duplicate/edge input registration | Registration | Input, Concurrency | High | +| Token expiry/replay scenarios | Authentication | Security | High | +| Parallel transactions/race conditions | Transactions | Transactions, Concurrency | Very High| +| Integration error/failure simulation | Transactions/Verify | Integration | High | +| Precise access/ownership tests | Account/History | Security, Ownership, Data Leakage | Med-High | + +--- + +## Conclusion + +DemoBank_v1's current Gherkin coverage robustly addresses mainline positive and negative flows per controller and business case. However, the most critical real-world gaps—especially concurrency (race), security, extreme data, and integration error handling—should be prioritized. Addressing these explicitly with new scenarios will strengthen overall system safety, reliability, and business compliance.