jaxwsdemo/requirements.md

ご要望にお応えします。 データベース（SQLite）に対して、テストデータやマスタデータを事前に投入・管理するための 「顧客登録API (Data Input API)」 を機能要件に追加しました。

これにより、自動テスト生成ツールは 「データの参照（Read）」 だけでなく 「データの永続化（Write）」 や、「登録処理が正しく行われたかの検証」 を行う必要が出てきます。

更新された requirements.md です。

---

Requirements: JAX-WS Loan Approval Service Demo (with SQLite & Data Input)

1. Project Overview

This project serves as a target application to evaluate an Automated Unit Test Generation Tool. It is a SOAP-based Web Service designed to simulate a loan approval process. It utilizes SQLite for data persistence and includes APIs for both Loan Processing (Business Logic) and Customer Management (Data Input).

1.1 Objectives

• Dependency Injection Analysis: Verify if the tool can detect dependencies and inject mocks.
• Database Interaction: Evaluate tests for both Reading (Select) and Writing (Insert) operations.
• State Verification: Verify if the tool can assert that data input via one API is correctly reflected in the database.

---

2. System Architecture

2.1 Technology Stack

• Language: Java 11 or higher
• Protocol: SOAP 1.2
• Framework: JAX-WS (Jakarta XML Web Services)
• Database: SQLite
• Library: org.xerial:sqlite-jdbc

2.2 Architectural Components

• Service Endpoint: LoanApprovalService (Contains both Loan Logic and Customer Registration).
• Data Access Layer (DAO): Interfaces for DB I/O.
• Infrastructure: Concrete implementations using JDBC/SQLite.

---

3. Database Design (Schema)

The application uses a local SQLite database (loan_app.db).

3.1 Table: customers (Master Data)

CREATE TABLE customers (
    customer_name TEXT PRIMARY KEY,
    is_blacklisted INTEGER DEFAULT 0, -- 0: False, 1: True
    registered_at TEXT
);

3.2 Table: loan_history (Transaction Data)

CREATE TABLE loan_history (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    applicant_name TEXT,
    requested_amount INTEGER,
    approved INTEGER,
    approved_rate REAL,
    rejection_reason TEXT,
    processed_at TEXT
);

---

4. Data Models (POJOs)

4.1 Input: LoanRequest (Process Logic)

(Existing Loan Request model)

4.2 Input: CustomerRegistrationRequest (Data Input)

New POJO for registering customers.

Field Name	Type	Description	Constraints
customerName	String	Name to register	Unique, Not Empty
blacklisted	boolean	Initial blacklist status	-

4.3 Output: LoanResponse

(Existing Loan Response model)

---

5. DB I/O API (Repository Layer)

The CustomerRepository is updated to support Data Input.

5.1 CustomerRepository (Read & Write)

public interface CustomerRepository {
    /**
     * Checks if the applicant is on the blacklist.
     */
    boolean isBlacklisted(String name);

    /**
     * Registers a new customer into the database.
     * @param name Customer Name
     * @param isBlacklisted Blacklist status
     * @return true if registered, false if already exists.
     */
    boolean registerCustomer(String name, boolean isBlacklisted);
}

5.2 LoanHistoryRepository (Write-Only)

(Same as previous version: saves loan results)

---

6. Functional Requirements

The LoanApprovalService now exposes two main Web Methods.

6.1 Feature A: Customer Registration (Data Input API)

Method: registerNewCustomer(CustomerRegistrationRequest request)

• Input Validation:
  • If request.customerName is null or empty, throw SOAPFaultException.
• Business Logic:
  • Call CustomerRepository.registerCustomer(name, blacklisted).
  • If returns true: Return string "Registration Successful".
  • If returns false (Duplicate): Return string "Error: Customer already exists".
• Test Goal: Verify that data passed to this method is correctly forwarded to the Repository's save method.

6.2 Feature B: Loan Processing (Core Logic)

Method: processLoanApplication(LoanRequest request)

(Logic remains the same as previous version)

1. Validate Inputs.
2. Check Blacklist: Call CustomerRepository.isBlacklisted.
   • Note for Integration Testing: If registerNewCustomer was called previously with blacklisted=true, this check must return true.
3. Check Credit Score (External Mock).
4. Decide Approval.
5. Save History: Call LoanHistoryRepository.saveHistory.

---

7. Implementation Constraints

7.1 Dependency Injection

The Service must have setters for:

• setCustomerRepository(CustomerRepository repo)
• setLoanHistoryRepository(LoanHistoryRepository repo)
• setCreditScoreService(CreditScoreService service)

7.2 Database Initialization

The DatabaseManager should include a method to resetDatabase() (DROP/CREATE tables) to ensure a clean state for integration tests.

---

8. Expected Test Scenarios (Target for Generator)

The tool is expected to generate tests covering:

1. Data Input Unit Test (Mock):
   • Scenario: Call registerNewCustomer("Alice", true).
   • Assertion: Verify customerRepository.registerCustomer("Alice", true) was called exactly once.
2. Data Input Logic Test:
   • Scenario: Repository returns false (Duplicate).
   • Assertion: Service returns message "Error: Customer already exists".
3. Integration Flow (Optional but Ideal):
   • Step 1: Call registerNewCustomer("BadUser", true).
   • Step 2: Call processLoanApplication for "BadUser".
   • Assertion: Loan is rejected immediately due to Blacklist.
4. Process Flow with DB Recording:
   • Scenario: Loan Approved.
   • Assertion: loanHistoryRepository.saveHistory is called with approved=true.