- HOME >
- ポンコツPdM
ポンコツPdM

SIerでの開発・プロジェクト運営の経験をもとに、Java・Springの実装、設計・テスト、チーム開発で役立つ手順をまとめています。
学習と現場をつなぐ
この記事でわかることJavaのenumで注文の状態を表しても、setterから自由に書き換えられると、出荷済みをキャンセルできます。出荷とキャンセルを注文の操作にし、拒否した後も状態が変わらないことをJUnitで確かめます。 注文管理画面のキャンセルボタンから、注文の状態を更新する処理を作ります。注文が未出荷なら、そのままキャンセルできます。すでに荷物を出荷した注文までキャンセル済みになると、倉庫では出荷済みなのに管理画面ではキャンセル済み、という食い違いが起きます。 対象は、Javaのクラスとenumを ...
この記事でわかることJUnitの @TempDir に前回の連携ファイルを作り、書き込み途中で IOException を起こします。前回分の全バイトが残るか、一時ファイルが残らないかを、実際のファイルで確認します。 毎朝のバッチが daily.tsv を作り、別システムは決まったパスから読み込みます。入力の読み込みに失敗した日は連携ファイルを更新せず、前回分を残す運用です。エラーが返っても、出力先をすでに上書きしていたら、その運用は成り立ちません。 実行用サンプル ZIPには、直接書く実装と一時ファイル ...
この記事でわかることJUnitで動かした送料計算を、Spring BootのGET APIにつなぎます。送料のルールを変えたときに落ちるテストと、URLやJSONを変えたときに落ちるテストを、同じコードで確かめます。 購入画面に送料見積もりを表示することになりました。今まではJavaのメソッドに小計を渡していましたが、画面チームは小計をURLの文字列で送り、送料をJSONで受け取りたいと言っています。ここで増えた仕事は、整数へ変換し、既存の計算を呼び、成功と失敗をHTTPで伝えることです。 対象は、Jav ...
この記事でわかること仕様書にない既存動作を調べ、残すべき戻り値をJUnitで確かめる手順です。Javaの配送判定を、整理する前、整理した後、新しい仕様を入れた後の3段階で比較します。 保守チームに「離島の注文は発送前に人が確認する」という依頼が来ました。配送判定のクラスにはすでに、発送できない品目を止める処理と、住所が不足した注文を保留する処理が混ざっています。担当を分ければ離島の条件は追加しやすくなります。順番を入れ替えただけで、発送禁止の品が確認待ちに流れると困ります。 仕様書には「配送できない場合は ...
この記事でわかることJavaのメソッドへ開始・終了時刻を毎回渡している処理を、小さなクラスにまとめます。同じ入力で分割前後を比較し、時刻の成立条件と会議室ごとの予約ルールをどこに置くか判断します。 会議室の予約画面に「利用時間」と「既存の予約との重なり」を出すとします。初めは、メソッドへ時刻を二つずつ渡せば動きます。次に、別の画面にも同じ処理を足すことになりました。呼ぶ場所が増え、startとendをいつも正しく組み合わせて渡す必要が出てきます。 対象は、Javaの変数、メソッド、newを読める人です。開 ...
この記事でわかることint同士の掛け算をlongに代入したら、在庫数がマイナスになりました。どの時点で数があふれたかを確認し、合計をlongで扱う修正と、intの範囲外を例外で止める修正を比べます。 倉庫の集計では、箱数と1箱あたりの個数を受け取って合計個数を出します。個々の値はintで受け取れますが、掛け合わせると約21億を超えることがあります。たとえば50_000 * 50_000の答えは2,500,000,000。受け皿だけlongにしたコードでは、実行すると −1,794,967,296 になりま ...
テスト対象のShippingFee.javaと、テストコードのShippingFeeTest.javaをセットで動かし、JUnitの使い方を覚えます。まず送料計算の3件を成功させ、本体の条件を1か所変えて失敗させます。最後に、その失敗表示から直す場所を見つけます。 この記事で解説するコードの全文はこちら テスト対象・テストコード・pom.xmlを、実行できる一式で用意しました。記事に載せたものと同じ3テスト版です。ZIPを展開し、2つのJavaファイルを開いたまま読み進めてください。 ShippingFe ...
Javaのテスト入門で最初に読む1冊。送料計算から境界値と期待値を選び、JUnitで確かめます。
Java初心者の最初の1冊と、必要に応じて補うHTML/CSS・SQLの本。短いコードと6項目で、次に進む準備ができたか確かめます。
「このAPI変更は開発チームでお願いします」と任された。しかし、画面の文言を誰が決めるのか、利用側への影響を誰が確認するのか、本番反映を誰が承認するのかは決まっていない。実装担当が全部を抱えたり、最後のレビューで判断が止まったりします。 この場面では、作業者を増やす前に、実行者・確認者・判断者を分けます。特に一つの判断に最終責任を持つ人を明記します。 その人が全ての情報を一人で集めるという意味ではありません。判断材料を作る人、影響を確かめる人と組み合わせます。 以下は架空の問い合わせ管理アプリで、件名の文 ...