ユニットテストの長所（TDD、
BDD-この場合は問題ではない）、および人々が
まだそれらを使用しない理由について多くの言葉が言われてい
ます 。
しかし、主な理由の1つは、人々がどこから始めればよいかわからないからだと思います。 それで、私は単体テストに関する記事を読みました。 いつか試してみることにしました。 しかし、次は何ですか？ どこから始めますか？ これらすべての要件を発明する方法、テスト方法に名前を付ける方法は？
最近、
単体テストをBDD仕様に変換する傾向が広まりつつあります。つまり、優れた単体テストでは何かをテストするのではなく、プログラムの動作を記述する必要があるということです。 しかし、このいまいましい動作を記述する方法。 これらすべてのテストケースの名前を思い付くためのインスピレーションを得る場所
これについて説明します。
インスピレーションを得る場所
驚くべき発見に到達すると、このインスピレーションはどこにでもあり、毎日私たちを取り囲んでいます。 何も発明する必要はありません。 簡単に使用できます。 この発見は私にとって非常に重要であるように思えたので、私はそれを誰とでも確かに共有することを急いでいます。
それで、ユニットテストを書くための私のTOP-5インスピレーションの源。
5.チーフへの報告
ミーティングの毎朝、ボスは「昨日は何をしましたか？」と尋ねます。
-彼はバグを修正しました。上司は言葉を発するだけでなく、掘り続けます。
-どんなバグ？
-さて、validateReferenceNumberメソッドを修正しました。
-具体的には、そこで何を修正しましたか？
「まあ、以前に入力で空の文字列を指定するとクラッシュしました。今では落ちませんが、falseを返します。」ガッチャ！
おわかりのように、実際に完成した単体テストは鼻の前の空中にぶら下がっています。 会議の後、コンピューターの前に座って次のように書きます。
public class ReferenceNumberTest { @Test public void emptyStringIsNotValidReferenceNumber() { assertFalse(validateReferenceNumber("")); } }
理想的には、昨日これを行うべきでした。そうすれば、ボスは昨日追加した単体テストを確認でき、質問に煩わされることはありません。
冗談ではありません。コードレビューの代わりに単体テストをレビューする非常に成功した企業の例を知っています。
4.同僚との説明
同僚が毎日あなたのところに来て、尋ねます：
-聞いて、私はあなたのコードをデバッグするためにここにいますが、それでも私はそれがどのように機能するのか理解できませんか？あなたは辛抱強く彼に説明します：
-さて、見て、見て：Bがここに来て、Aがここから出てきます
「まだわかりませんが、なぜAですか？」
「まあ、私より小さいすべての文字について、このメソッドは次の文字を返すはずです。」
-ああ、今は明らかです。そしてまたガッチャ！
あなた自身、それを疑うことなく、テストケースの名前を作成しました。
同僚のカルマに精神的に+1を送信し、彼らは座って書いた：
public class NanoTechnologySecurityTest { @Test public void shouldReturnNextLetterForAllLettersExceptJa() { assertEquals("", encodeLetter("")); } }
3.クライアントとの会話
どんな美しい日にでも、クライアントは電話して次のように言うことができます。
-フォーム上のすべてのフィールドは、フィールドがフォーカスを失うとすぐに自動的に検証されるべきであることを説明しましたか？ それで、気が変わりました。 私は私の祖母にベータ版を見せました、そして、彼女はそれがはっきりしていないと言いました、そして、一般に、 ajaxは吸います。 クライアントが「送信」ボタンをクリックしたときにのみフィールドが検証されるようにします 。
繰り返しますが
クライアントがテストケースのテキストを作成しました。
クライアントのカルマに-10を精神的に送信して、私たちは座って書きました...もちろん、UIテストは通常の単体テストよりも少し複雑ですが、次のようになります。
public class TimotiFanClubRegistrationFormTest { @Test public void shouldValidateFieldsOnFormSubmission() { Form form = new Form(); assertTrue(form.isValid()); form.submit(); assertFalse(form.isSubmitted()); assertFalse(form.isValid()); form.setName("Baba Njura"); form.setEmail("Baba.Njura@yandex.ru"); form.submit(); assertTrue(form.isSubmitted()); } }
2.バグ
毎日、Jiraに（そして本当に幸運な人
-Pivotal Trackerに ）行くと、悪意のあるテスターがプログラムのバグを発見したことがわかります。 テスターが幸運な場合、バグの説明は次のように聞こえます。「間違ったパスワードを3回入力すると、アカウントはブロックされるはずですが、ブロックされません。 すでに15回参加しています。」
テスターに心から感謝します（彼からも感謝からでも、あなたは彼のカルマを救うことはできません）。
public class LoginPageTest { @Test public void shouldBlockAccountAfter3UnsuccessfulTries() { LoginPage page = new LoginPage(); page.login("vasjok47", "Toiota"); page.login("vasjok47", "Tojota"); page.login("vasjok47", "tayota"); assertTrue(AccountDAO.getAccount("vasjok47).isBlocked()); } }
これには別の用語である「
バグ駆動型開発」もあります。 私はこのアプローチを後悔していません。ユニットテスト（仕様でもあります）はコード（TDDの主な原則）の前に記述される必要がありますが、インスピレーションの源としてバグトラッカーが非常に適しています。
1.コミットメッセージ（ロシア語ではどうですか？）
これが私のお気に入りのポイントです。詳細に説明したいと思います。
コードを変更するとき、通常これには理由があります。 理由は通常、このコードで何か別のことをすることです（リファクタリング、パフォーマンスの向上、および風水用のブラケットの配置は除外します）。
電子メールを検証するコードがあったとしましょう。 特に、メールの最後にピリオドと2文字が必要であることを確認しました。 そして、彼のための単体テストがあっても、すべては人々が持っているようなものです。 そして、ある期間が過ぎると、たとえば、一部のクライアントでは電子メールが「.info」で終わるなど、さらに多くの文字があることが
突然判明します。 言うよりすぐに、コードが修正され、既存の単体テストに1行も追加されました。
public class EmailValidatorTest { @Test public void testValidateEmail() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info"));
そして今、私たちはこのビジネスを
CVS （そして幸運な人々、SVNの人々、そして一般的に幸運な人々、
GITの人々）にコミットしたいと思います。
コミットの場合、説明（コミットメッセージ）を記述する必要があります。通常、その説明にはコードの変更点が記載されています。 そして、あなたは書く：
svn commit -m " ."
これが本物のGotchaです！
これが必要なものです。 まだEnterキーを押さないでください。
このテキストをマウスで強調表示して停止しました。 単体テストクラスを開きました。 彼らは
Testを書き、コピーしたテキストを貼り付けて英語に翻訳しました。 少し明確にしたり、一般化して味わうことができます。
public class EmailValidatorTest { @Test public void validEmailShouldEndWithDotFollowedBySeveralLetters() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info")); } }
これで、カルマに安全にコミットして精神的に+1を送信できます。 今日、私たちは空気中の知識をより具体的なものに具体化することができました。 これで、この知識はどこにも移動せず、プロジェクトの各アセンブリで自動的にチェックされます。
まあ、それは素晴らしいですね？