Initial commit: JAX-WS Hello World Service
- Complete JAX-WS Hello World implementation - Docker and Docker Compose support for easy deployment - Python test scripts for service validation - Comprehensive README with setup instructions for Windows and Linux - Maven configuration with JAX-WS dependencies 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
186
requirements.md
Normal file
186
requirements.md
Normal file
@ -0,0 +1,186 @@
|
||||
ご要望にお応えします。
|
||||
データベース(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)
|
||||
|
||||
```sql
|
||||
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)
|
||||
|
||||
```sql
|
||||
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)
|
||||
|
||||
```java
|
||||
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`.
|
||||
Reference in New Issue
Block a user