頼み方を型にして、テストで裏を取る

前回はあえて型を出さずに進めました。まず通じることを体験してもらうためです。実際、ふつうの日本語で頼んで動きました。

ただ、それだけだと「たまたま通った」で終わります。持ち帰って明日も使えるようにするには、何が効いていたのかを言葉にしておく必要があります。

効いていたのは4つです。1つ目、どのファイルの話かを @ で指定したこと。付けないと探し回るので時間がかかり、関係ないファイルまで直されることがあります。2つ目、やってほしいことを1つに絞ったこと。2つ以上を1回で頼むと、片方だけ直った状態で返ってきます。3つ目、やってほしくないことを添えたこと。前回の D1-4 で「元の受注に戻る参照は入れないで」と言わなかった場合、見た目は動くのに壊れたものが出ます。4つ目、どうなったら終わりかを決めておいたこと。これが無いと、実装が済んでいるのに終わったかどうか分からなくなります。前回まさにここで止まりました。

この4つは、Java の知識とは関係ありません。COBOL でも Python でも C# でも同じです。今日はこの形を使って進めます。

OrderServiceImpl の validateStatusTransition は、受注ステータスをある値から別の値へ変えてよいかを判定するメソッドです。配布時点では case Order.STATUS_CONFIRMED が SHIPPED への遷移しか許していないため、確定済みの受注をキャンセルできません。業務ルールでは PENDING と CONFIRMED からのキャンセルを認めます。出荷済み以降は認めません。モノが動いたのに帳簿だけ消える状態になるためです。

確認は PATCH /api/orders/{id}/status で行います。内部で validateStatusTransition が呼ばれるからです。PATCH /api/orders/{id}/cancel は cancelOrder という別のメソッドを呼ぶので、遷移ルールの確認には使いません。手順3で作るボタンも、押したときに叩くのは /status のほうです。

ステータス値は文字列の直書きではなく Order の定数を使います。綴り間違いをコンパイルの時点で見つけられるからです。

画面のボタンがうまく動かないときは、ターミナルから直接叩いても確かめられます。

打つのは次の1行です。curl -X PATCH http://localhost:8080/api/orders/2/status -H "Content-Type: application/json" -d '{"status":"CANCELLED"}'

返ってきた status が CANCELLED になっていれば通っています。

配布データでは id=2 と id=3 が CONFIRMED、id=4 が SHIPPED で入っています。id=2 を一度 CANCELLED にすると遷移元が変わるので、やり直すときはアプリを起動し直してください。H2 はメモリ上で動くので、起動のたびに配布時の10件へ戻ります。

新しいファイルは作りません。編集は OrderServiceImpl.java の中と、自分のダッシュボードだけです。手順4で起動し直すのは OrderServiceImpl を直したためで、ボタンを足した HTML のほうは再読み込みだけで反映されます。ボタンの見た目や文言をあとから直すときは、起動したまま再読み込みで確かめてください。

OrderServiceImplTest は findById・createOrder・changeStatus・cancelOrder・findAll の代表ケースが正常系・異常系とも実装済みで、changeStatus の @Nested に4件の TODO コメントが残っています。CONFIRMED から SHIPPED、SHIPPED から DELIVERED、CANCELLED からの遷移は全部不可、同一ステータスへの遷移は不可、の4件です。テスト基盤は組んであるので @ExtendWith や @Mock を書き足す必要はありません。AssertJ の assertThat と assertThatThrownBy、Mockito の when と verify、既存テストと同じ書き方に揃えるだけです。追記先は既存ファイルで、新規ファイルは作りません。

mvn test -Dtest=OrderServiceImplTest は9件中1件が赤です。Day2 で初めてテストを走らせると赤が1件出ますが、これは配布時点で仕込んである失敗で、環境の不備ではありません。DELIVERED の受注をキャンセルできてしまう穴が cancelOrder に残っていて、例外が出ずにキャンセルが通り、スタブしていない save が null を返すので、続く行で NullPointerException になります。画面に出るのは expecting ... InvalidOrderStateException but was ... NullPointerException の行です。Day3 の題材なので、今日は直しません。走らせる前に配布時点の状態を一度見ておくと、自分が足したテストの失敗と切り分けやすくなります。

@ を打つと候補が出るので、ファイル名でもパスでも選べます。実行結果の読み方には癖がひとつ。Maven のコンソールに出るのはクラス単位の集計行と落ちたテストの名前だけで、通ったテストのメソッド名は表示されません。名前まで確かめたいときは target/surefire-reports/TEST-com.example.order.service.OrderServiceImplTest$ChangeStatusTest.xml を開き、testcase name に自分が足したメソッド名が並ぶのを見てください。

同一ステータスへの遷移には専用のチェック文がありませんが、どの case も自分自身を遷移先に挙げていないので例外が出ます。このテストは配布時点でも緑です。もうひとつ、CONFIRMED から CANCELLED が成功する前提のテストは、Day1 の D1-5 を済ませていなければ落ちます。落ちたときは validateStatusTransition の CONFIRMED の case を開いて、SHIPPED しか許していないことを自分で確かめてください。生成物の誤りなのか実装の穴なのかは、ここが分かれ目です。採否の基準は docs/生成物チェックリスト.md の B-5 に書いてあります。

BuggyOrderCalculator は受注5件を内部に持つ単体クラスで、公開メソッドは3つです。仕様は Javadoc に書いてあります。数量10個以上で5%、20個以上で10%、50個以上で15%の割引。指定顧客の受注が1件もなければ合計0円。納品予定日の当日にまだ出荷されていない受注も遅延に数える。この3つを頭に入れてからテストを書きます。

置き場所には一手いります。このクラスは exercises/day2 にあり、Maven は src/main/java の下しかコンパイルしないため、テストクラスから参照できません。移さずに走らせると「シンボルを見つけられません」でコンパイルが止まります。移したあとは修正もそのファイルに対して行い、exercises 側には戻しません。

期待値は電卓で先に出しておきます。突き合わせる基準がないと、生成物の粗は見つけにくくなります。数量10・単価50000なら5%引きで475000円、いまの実装が返すのは500000円。getCustomerOrderTotal は合計の初期値が null のままなので、該当受注ゼロの顧客では null がそのまま返ります。メソッド自体は例外を投げません。NullPointerException になるのは戻り値を int で受けたときで、自動アンボクシングで null を数値に展開しようとして落ちます。期待値0で突き合わせるテストは値が合わずに Failures、int で受けるテストは Errors 側に出ます。

/gen-test はこのプロジェクトに同梱したコマンドで、実体は .claude/commands/gen-test.md です。handson フォルダを開いた状態で claude を起動すると、/ge まで打てば候補に出ます。テストが1件でも赤いと Maven は BUILD FAILURE で終わりますが、今日はそれが狙いどおりの状態なので、Results: の下の Tests run と Failures、Errors の行だけ読んでください。

修正後の確認は java -Dfile.encoding=UTF-8 src/main/java/com/example/order/buggy/BuggyOrderCalculator.java です。main に自己診断が入っていて、直る前は「バグ発生!」が3か所、直ったあとは割引と遅延が「正常」、存在しない会社の合計が0円と出ます。

仕込んであるコードスメールは次の8種類です。答え合わせに使ってください。

1. 長大メソッド。generateMonthlyReport が97行、generateCustomerSummary が91行、generateHighValueAlert が55行。集計と整形と出力を1つのメソッドでやっています。

2. ループ内の文字列連結。result = result + ... が87箇所。文字列は変更できない型なので、つなぐたびに新しい文字列が作られます。件数が増えると効いてきます。

3. マジックナンバー。税率の 1.1 が3箇所、高額の閾値 1000000 が1箇所、緊急の閾値 2000000 が2箇所。数字を見ても何の数字か分かりません。

4. 深いネスト。最大7階層。262行目から290行目あたりが特にひどく、条件を追うのが難しくなっています。

5. 重複したロジック。ステータスを判定する同じ形の分岐が84行目、179行目、261行目の3箇所にあります。1つ直したら3つとも直す必要があります。

6. 意味のない変数名。cnt、tmp、d、q、p、val、st、dt など12種類。名前から中身が分かりません。

7. 生の Map で持っている。Map<String, Object> が5箇所。取り出すたびにキャストが要り、キーを打ち間違えても気づけません。

8. 引数を使っていない。generateCustomerSummary は顧客名だけで絞り込んでいて、月の絞り込みがありません。

全部潰す必要はありません。35分で何種類まで行けるかです。1〜6は比較的安全で、7は影響範囲が広く、8は仕様の判断が要ります。8に手を出すと出力が変わるので、今日は触らないでください。