設計・テスト・レビュー

2026/11/4

Javaの現在日時をテストで固定する方法｜Clock.fixedで期限判定を確認する

「昨日まで通った期限判定テストが、今日になったら落ちた」。期限を固定して期待結果だけ書き、判定の中でLocalDate.now()を呼んでいると起こる失敗です。テストのたびに予定日を書き換える運用では、期限当日と翌日の境界を保証できません。ここで取る方針は、現在日時を業務ロジックの入力として扱い、Clockを渡すことです。題材は「締切日当日まで申請でき、翌日からできない」という架空の申請機能。画面表示やDB保存ではなく、期限判定を毎日同じ条件で確かめます。実行サンプル締切日の当日・翌日と、同じ瞬間を ...

設計・テスト・レビュー

2026/11/4

JUnitのParameterizedTest・CsvSourceの使い方｜境界値と空文字を正しくテストする

JUnitのParameterizedTestは、先に決めた入力と期待結果を、一行ずつ同じテストへ渡すために使います。この記事では「件名は空白だけを認めず、Unicodeコードポイント数で1〜100」という仕様を、6行の境界値テストへ移します。100文字を誤って拒否したとき、どのケースが落ちたかまで確かめます。対象コード・テスト・pom.xmlの全文はこちらJava 17・JUnit 5.12.2で動かす独立Mavenプロジェクトです。件名判定、問い合わせの対応開始判定、仕様から選んだケース、CsvSo ...

設計・テスト・レビュー

2026/11/4

privateメソッドをモックしたい？通信の失敗をテストするなら、置き換える場所を変える

公開メソッドの中でprivateメソッドを呼び、その中で外部へ通知している。通知の失敗をテストしたくて「Mockito private モック」と検索した。この場合、置き換えたいのはprivateという実装上の区切りではなく、外部通信です。この記事では、通知サービスを例に、privateの名前に依存せず、通信失敗時の動きを確認する形へ変えます。新しく書くテストでは、まず通信を差し替えられる依存にする。純粋な整形処理は公開メソッドの結果から確認し、成功・失敗を作りたい外部依存を置き換えます。既存のPow ...

設計・テスト・レビュー

2026/11/5

Javaのメソッド分割の基準｜privateに切るか、別クラスにするか

Javaのメソッドを分ける基準は、行数よりも「名前を付けて説明できる仕事のまとまり」です。まず同じクラスのprivateメソッドへ切り出し、取込の進行と、1行を変換する規則を分けます。別クラスにするかは、その規則を独立した担当として扱う理由があるかで判断します。分割前・分割後のコード全文と、比較用サンプル同じ入力を3版へ渡し、保存回数と例外まで比べられます。Java 17で実行できます。ZIPにはJavaソース6件、README、検証記録、LICENSEを含みます。分割前：BeforeImporter. ...

設計・テスト・レビュー

2026/11/4

改修のテストはどこまでやる？単体・結合・手動の範囲を決める例

「単体テストは通った。でも、画面やDBまで全部試すべき？」改修のたびに、どこまで確認すればよいか迷うことがあります。先に結論見つけたい失敗から、確認する範囲を選ぶ。変更した行数やケース数だけで決めない。実物とモックを明記する。「単体・結合」は確認する範囲、「手動」は実施方法として分ける。未確認のリスクも残す。省く確認は、判断する人と補う方法をセットで相談する。この記事では、架空の問い合わせ管理を使い、入力・権限・検索の3つの改修からテスト範囲を考えます。確認を省くときの伝え方も、記入例で示します ...

設計・テスト・レビュー

2026/11/5

AIが書いたコードをそのまま使っていい？提出前の確認チェックリスト

AIのコードで画面が動き、テストも通った。それでも、このまま仕事の成果物として提出してよいのか迷うことがあります。先に結論利用許可と、渡す情報を確認する。アカウント・用途・操作の範囲は、契約や設定と合わせる。仕様は、許可・拒否・失敗の場面で照合する。正常に動いたことだけで判断しない。確認済みと未確認を分けて採用を判断する。未確認がある相談用の成果は、その状態を明記する。架空の問い合わせ管理を使い、提出前の判断材料を整理します。特定製品の性能や契約条件を比べる記事ではありません。所属先の規程と、採 ...

設計・テスト・レビュー

2026/9/8

コードレビューで指摘されたらどう返す？修正・質問・見送りの例文

レビューで「ここは直した方がよさそうです」と届いた。直すべきか、理由を聞いてよいか、今回は対象外だと伝えてよいか。コードより返答に時間がかかることがあります。先に結論まず指摘の意図を確かめる。必須の修正か、改善提案か、質問かを揃える。修正・質問・見送りの相談を分ける。判断が残る点を「対応しました」で閉じない。変更箇所と確認結果、残る判断を返す。未確認は未確認として伝える。以下は、件名が必須・1〜100文字の問い合わせ管理を改修する架空の会話例です。実際のレビューや実行済みのテスト結果ではありませ ...

設計・テスト・レビュー

2026/11/4

テストケースの作り方｜仕様・境界値・期待結果をJUnitと対応させる実例

「問い合わせの対応開始をテストしておいて」と言われ、担当者が一度操作できることだけを確認した。レビューで「投稿者が操作したら？完了済みだったら？拒否した後の状態は？」と聞かれ、ケースを足すたびに終わりが見えなくなる。そんなときは、テストコードを書く前に仕様の条件と、その条件で守る結果を対応させます。この記事でわかること件名1〜100文字という仕様から、正常系・異常系・境界値を選ぶ理由。権限と状態を変えるケースで、入力・事前条件・操作・期待結果を揃える方法。仕様の1行をJUnitのassertionへ ...

設計・テスト・レビュー

2026/9/8

プルリクエストの書き方｜初めてのPRで伝える変更理由・確認結果

PRの説明が「件名を追加しました」だけだと、レビューする人は差分から目的や確認状況を探すことになります。何を書けば、変更を判断してもらいやすいのでしょうか。先に結論目的・変更点・確認結果・未確認・見てほしい点の五つを揃える。「テストOK」は条件と結果に分ける。まだ試していないことは未確認と書く。説明と実際の差分を照合する。変更や追加確認をしたら、説明も更新する。以下は、問い合わせに必須・1〜100文字の件名を追加する架空例です。実在のPRや実行済みのテスト結果ではありません。差分から見えない「 ...

設計・テスト・レビュー

2026/9/8

仕様確認のチェックリスト｜実装前に聞くべきことと質問例

「問い合わせに件名を追加してください。必須でお願いします」。入力欄を作れば始められそうでも、下書きの扱いや変更できる人、過去データへの影響が気になることがあります。先に結論依頼を利用者の操作に置き換える。誰が、いつ、何をできるかを確かめる。決まっていることと未決事項を分ける。根拠・決める人・着手への影響を残す。回答を資料とテストへ反映する。確認待ちの間に進めてよい範囲も相談する。以下は架空の問い合わせ管理の例です。件名は必須・1〜100文字、状態は「下書き・受付済み・対応中・完了」、利用者は投稿 ...

« Prev 1 2 3 4 5 Next »