目次

・本日の成果・考え
・最後に

本日の成果

現在のファイルおよびクラス構造

Dify_desktop
 ├─ .settings
 ├─ bin
 └─ src
     └─ app
         ├─ logger
         ├─ test
         ├─ util
         │   └─ CommonFunction.java
         ├─ windowView
         │   ├─ api
         │   │   ├─ DifyApiClient.java
         │   │   ├─ DifyRequestDto.java
         │   │   ├─ DifyResponseDto.java
         │   │   └─ RetrieverResourceDto.java
         │   ├─ config
         │   │   ├─ AppSettingDto.java
         │   │   ├─ AppSettingFactory.java
         │   │   ├─ AppSettingFactoryTest.java
         │   │   └─ SettingLoader.java
         │   └─ window
         │       ├─ JavaBridge.java
         │       ├─ UliniWrapper.java
         │       ├─ WebEngineWrapper.java
         │       ├─ WindowController.java
         │       ├─ WindowLogic.java
         │       └─ WindowView.java
         ├─ Main.java
     ├─ resources
     │   └─ window
     │       └─ app.properties
     └─ window_interface
         ├─ BridgeCallback.java
         ├─ JsCall.java
         └─ UliniExecutor.java

各クラスの機能一覧

[util]

CommonFunction.java：共通処理を実装したクラス。
※文字列のnull/空白チェックやエスケープ処理

[windowView/api]

DifyApiClient.java：Difyとの通信制御をするクラス
DifyRequestDto.java：Difyへ送信するリクエストDTO
DifyResponseDto.java：Difyから受信するレスポンスDTO
RetrieverResourceDto.java：Difyレスポンス内の retriever_resources フィールドを扱うDTO

[windowView/config]

AppSettingDto.java：ウィンドウやアプリ全般の設定値を保持するDTO
AppSettingFactory.java：AppSettingDtoの生成を担うファクトリ
SettingLoader.java：AppSettingFactoryを起動し、DTOを構築するローダ

[windowView/window]

JavaBridge.java：JavaとJavaScript間の橋渡しをするブリッジ
UiIniWrapper.java：UiIniExecutor を実装したラッパークラス。UIスレッド上で安全に処理を実行するためのクラス。
WebEngineWrapper.java：JavaFX WebEngineの操作をラッパークラス
WindowController.java：画面更新や通信呼び出しを制御するコントローラ
WindowLogic.java：アプリのウィンドウ機能全般の制御ロジック
WindowView.java：JavaFX Application継承クラス。画面の初期化・ウィンドウ生成・JavaBridge登録を担当

[resources/window]

app.properties：設定情報を保持するプロパティファイル

[window_interface]

BridgeCallback.java：JavaBridge経由で呼び出すコールバック処理を定義
JsCall.java：Java側からJavaScriptを呼び出す処理を提供
UiIniExecutor.java：Runnable を UI スレッドで実行する runLater() を定義

リンクテストのシナリオ

以下を検討してみました。

----------------------------------------------------------------------------------------------------
テストケース                    | LTで確認できる点
----------------------------------------------------------------------------------------------------
1. インタフェース契約     : DTO（Request/Response）の構造がAPI仕様通りか、必須フィールド・型が正しく渡るか。
                         -JSON⇄DTO変換が正しく動き、想定外のフィールドでも破綻しないこと。

2. スレッド境界           : バックグラウンド受信スレッドからUIスレッドに処理が正しく委譲されるか。
                         - runLater経由でUI更新され、順序が保持されているか。

3. JSブリッジ整合        : Java⇄JavaScript呼び出しが正しく橋渡しされるか。
                         - エスケープ処理によりDOM更新時にスクリプトが実行されず、安全に表示されるか。

4. エラーパス復帰        : 通信失敗やJSONパース異常が発生した際、例外がUIまで波及せずに制御できるか。
                         - UIが固まらず、エラーメッセージ表示や復帰ができるか。

5. 設定読込             : 設定ファイルが正しく読み込まれ、AppSettingDto経由でウィンドウへ適用されるか。
                         - 値が欠落・不正な場合のフォールバックや例外処理が適切に機能するか。

6. ユーザーフロー完遂    : WindowLogic → View → Bridge → Controller → API → Response → UI反映という一連の流れが
                         - 部品間で破綻なくつながるか。モックAPIを用いてUI反映まで確認。

7. パフォーマンス/容量   : 大きなレスポンス（多数のチャンクや大容量JSON）を処理してもUIがフリーズしないか。
                         - runLater連投時も順序通り処理され、応答性が維持されるか。
----------------------------------------------------------------------------------------------------

主な観点は以下です。

クラスではなく機能ごとの連携がどうか。
連携前後でエラーが発生したら困るかどうか。
連携で受け渡す情報（データ）の整合性ではなく、処理側の挙動に注目して検討。

おそらく抜けているポイントもあると思いますが、これ以上検討しても自分のみでは、質が上がらないと思いますし、ずっと作業が止まっている方が問題だと思うので、とりあえずスタートしようと思います。
今後問題が発生したら随時対応する形にしようと思います。

最後に

一旦作成したクラスの整理とリンクテストケースの作成で作業を切りたいと思います。
前回の投稿からおよそ1ヶ月経過しました。
資格勉強があまり進んでおらず、かなり焦っている状況です。
とはいえ、チャットbot企画の実現とより良い案件の参画のために、このポートフォリオを見せる形にすることが必要なことも事実です。
単体テストと違って、アプリとしての機能を理解した上で、確認すべき箇所を検討するのがかなり難しいです。
QAエンジニアの単価が高い理由が理解できました。
とりあえず、次回から作成したテストケースの細かな確認点を整理してソース作成に移りたいと思います。

最後に、ここではお見せしませんが、チャット画面で送信ボタンを押してから、チャンクの表示が完了するまでの間、送信ボタンを非活性にする機能を追加しました。
HTMLでボタンにdisabled にtrue,falseを付与するだけだったので、記事にするまでもありませんでした笑。

以上、ここまでお付き合いありがとうございます。