Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

C13 — Proposed Characterisation Tests

Diagram coverage

Purpose and test boundaries

This chapter proposes characterization scenarios for the behavior evidenced in the supplied source. These are proposed tests only: no scenario is reported as executed, passed, or failed. The scenarios describe the current behavior that a reviewer could capture before changing the application, including explicit stubs, error paths, limits, and source disagreements. Detailed field definitions and relationships belong in C06, end-to-end journeys in C04, business-rule interpretation in C05, and interface or database exchange detail in C08.

The evidence contains more than one implementation surface. The Java target, particularly D4_Main.java, D4_Orders.java, D4_Cust.java, D4_Report.java, and D4_Stock.java, should be tested separately from the Informix-4GL programs such as ordmenu.4gl.main, menu1.4gl.main, d4_orders.4gl, and d4_cust.4gl. Similar menu names do not establish that these programs are the same runtime path. In particular, Java D4_Orders.update_order() and D4_Orders.delete_order() are reported as stubs, while ordmenu.4gl.main contains modify and delete logic. E0002 E0009 E0012

Startup and reference-data loading

D4_Main.java selects the stores7 database, loads states and stocks before presenting the main menu, and uses bounded global arrays: p_state holds up to 50 entries and p_stock up to 30. The loaders stop at those capacities, but the supplied evidence does not establish whether truncation is visible to the user. E0008 E0012

Proposed test: startup loads reference data

• Given the Java application can connect to the configured stores7 database and the state and stock/manufacturer data contain records within the supported limits
• When D4_Main starts
• Then state and stock data are loaded before the main menu is available, and stock selection during order entry can retrieve a matching stock record.

Proposed boundary test: excess reference rows

• Given more than 50 state rows or more than 30 stock rows are returned
• When get_states() or get_stocks() loads the results
• Then only the configured in-memory capacity is retained, and the observed counter and user-visible behavior are recorded.
• Question: Does the framework display, log, or otherwise expose truncation, or is the excess data silently discarded?

This test should not be generalized to every runtime configuration. The Java loader evidence establishes the local array limits, while the 4GL evidence separately describes arrays of 50 states and 30 stocks. E0008 E0009

Customer maintenance

The supplied Java evidence describes D4_Cust operations for adding, querying, updating, and deleting customers, including browse navigation and state selection. Customer deletion checks for related rows in orders and presents an “active orders” message, but the Java query is reported as counting all orders rather than filtering demonstrably active orders. The 4GL d4_cust.4gl source likewise blocks deletion when matching orders exist. E0002 E0009

Proposed test: add and retrieve a customer

• Given valid customer values for fname, lname, company, address, city, state, zipcode, and phone
• When add_customer() completes without interruption
• Then a customer row is inserted, a generated customer number is obtained, and the new customer can be found through the customer query/browse flow.

Proposed exception test: interrupted customer entry

• Given customer entry is in progress
• When the user uses the documented interruption control, such as F2/Ctrl-Y in the Java evidence or the corresponding interrupt behavior in the 4GL documentation
• Then no customer row is written, the form returns to its prior menu state, and any displayed customer number or partially entered values are characterized.

The exact key mapping is not uniform across the evidence: help text describes DEL or CTRL-C for interruption, while the Java analysis reports F2 or Ctrl-Y. The test should therefore identify the exact executable under test rather than treating these controls as interchangeable. E0003 E0009

Proposed test: deletion with related orders

• Given a selected customer with at least one row in orders
• When deletion is requested and confirmed
• Then deletion is refused and the related-order warning is shown.

Proposed boundary test: completed or paid orders

• Given a selected customer whose related orders are completed or paid, but still present in orders
• When deletion is requested
• Then the observed result is recorded.
• Question: Is “active order” a business status, or does the current implementation intentionally treat every existing order as active?

This question is consequential because the Java evidence reports SELECT COUNT(*) FROM orders WHERE customer_num = ?, which does not visibly restrict the count to open or unpaid orders. E0002

Java order entry and invoice behavior

The implemented Java order path is centered on D4_Orders.add_order(). It selects or creates a customer, collects header data and line items, begins a transaction, inserts the order, inserts item rows, commits, and then generates an invoice. Rollback is explicitly attempted for reported insert failures, but rollback after an uncaught exception is not established. E0012

Proposed test: order with valid line items

• Given an existing customer and valid order header values
• And one or more line items with valid stock number, manufacturer code, quantity, and unit price
• When add_order() is completed
• Then an order header and corresponding item rows are inserted, the transaction commits, a generated order number is used, and invoice generation is invoked.

Proposed boundary test: ten line items

• Given an order containing ten line items
• When the line-item entry is completed
• Then all ten items are retained and displayed or invoiced according to the current implementation.

Proposed exception test: invalid stock lookup

• Given a stock number/manufacturer-code combination that cannot be found
• When the user continues item entry
• Then the application’s clearing, error, and navigation behavior is recorded, including whether the user is returned to stock-number entry.

The Java evidence reports that an invalid lookup clears description and unit price; the 4GL evidence separately warns that get_item() may lack explicit missing-row handling. These should be treated as distinct executable behaviors, not reconciled into one expected result. E0002 E0009

Proposed failure test: item insertion failure

• Given the order header insert succeeds but insertion of at least one item reports failure
• When add_order() handles the failure
• Then the transaction is rolled back, an insertion error is displayed, no committed partial order remains, and invoice generation is not performed.

Proposed failure test: exception after transaction start

• Given an exception occurs after beginTransaction() and outside the explicit negative-status branches
• When the exception handler runs
• Then the database transaction state and any residual rows are observed.
• Question: Does ErrorHandler, DBHelper, or another framework layer perform rollback automatically?

The source shows explicit rollback for selected failure branches but not in the broad exception handler. This test is intended to characterize that boundary, not to assume a transaction defect. E0012

Proposed monetary comparison test

• Given line totals whose sum produces a fractional-cent result after adjustment
• When the interactive order total and invoice total are both generated
• Then their displayed values are compared for rounding differences.

order_total() applies Money.valueOf(1.1d), while invoice generation separately applies 6.5% sales tax and 3.5% shipping. The rates suggest intended 10% equivalence, but the Money implementation and rounding behavior are not supplied. E0002 E0012

Separate legacy order-menu scenarios

ordmenu.4gl.main reports a different current behavior from Java D4_Orders: it contains Add, Query, Modify, and Delete paths. The modify path can replace order items, and deletion removes the selected order and its items after confirmation. These scenarios apply only to that exact 4GL program. E0009

Proposed test: modify an existing 4GL order

• Given chosen = 1 after an order has been selected
• When Modify changes order dates or replaces its item array
• Then the updated order and replacement items are observed, including the result if item replacement fails.

Proposed exception test: modify or delete without a selected order

• Given chosen is not set to indicate a selected order
• When Modify or Delete is requested
• Then the program displays “No order has been chosen.” and does not alter the database.

Proposed negative-confirmation test

• Given a selected customer or order
• When deletion is requested and the user answers n
• Then the database row remains, and the UI must be checked for whether it nevertheless clears the form and displays “Record deleted.”

The source analysis identifies that del_cust() and del_ord() perform those success messages outside the confirmation branch, making misleading success feedback a specific characterization point. E0010

Reports, stock, and command execution

Java D4_Report contains implementation evidence for mailing labels and accounts receivable, while print_backlog() and print_stock() are explicit stubs. Java D4_Stock similarly exposes menu handlers that report “This option has not been implemented.” Output options include file, printer, and screen for the implemented reports. E0002 E0009

Proposed test: report destination selection

• Given print_option is set to file, printer, or screen
• When mailing labels or accounts receivable is generated
• Then the selected destination is used, including default filenames such as labels.out or ar.out where applicable.

Proposed stub test

• Given the user selects backlog, stock-list, or any Java stock-maintenance operation
• When the operation is invoked
• Then the application displays the unimplemented-option message and performs no successful business-state transition.

Proposed security-sensitive test

• Given the Java D4_Main.bang() prompt accepts a command
• When the command is submitted
• Then the exact behavior of _app.execute(true, Str.valueOf(cmd)), including permitted scope and error handling, is captured in a controlled environment.
• Question: Is command execution restricted by the framework or operating environment, or does it execute arbitrary user-supplied commands?

The visible call path shows no application-level allowlist. This is a security characterization point for C09, not proof of a deployed vulnerability. E0012

Evidence and outcome recording

Each proposed scenario should record the exact executable name, input values, database preconditions, displayed messages, committed rows, rollback outcome, generated files, and whether behavior matches the source expectation. A result that differs between D4_Orders.java, ordmenu.4gl.main, and d4_orders.4gl should be preserved as an implementation distinction rather than averaged into one system result. Unresolved discrepancies and missing framework behavior should be carried forward to C14 and C15.