昨夜は AgileChina 2011 のオープンハウスイベントで、私はコーディングセッションのボランティアとして参加しました。コーディング セッションの主な目的は、参加する開発者にペア プログラミング、テスト駆動開発、リファクタリングのプロセスを体験してもらうことです。会社では 8 ~ 9 人の同僚と参加する同僚がこのプロセスを一緒に体験できるように、次の 4 つの異なるタイプのプログラミングの質問を用意しました。
タイムシート
スーパーマーケットのレジ
ソースコードの行数
ブラックジャックゲーム
イベントは 2 つの小さな問題を除いて非常に成功しました: 1. 会社はこのイベントのために新しいキーボードとマウスを購入しましたが、入力するときの感触が悪く、キーボードのキーが平らでした。ある参加者はキーボードにあまり慣れていないため、いつも誤ってスラッシュを何度も入力してしまうことがあります。 2. システムのロック画面のショートカット キーが IDE の書式設定コードのショートカット キーと競合し、間違ったキーを 2 回入力して画面をロックしてしまいました。さらに、そのマシンは私のものではなく、入力を手伝ってくれる他の同僚を見つけなければなりませんでした。汗だくです。 Pair の最終ラウンドで、クラスメートが「assertEquals を使用しないのはなぜですか?」と尋ねました。皆さんはassertThatを使用しているようですが、assertEqualsやassertTrueなどの使用はあまり推奨されていないようです。 イベントも終わり間近で集合写真を撮る予定だったので、簡単に答えました。この質問に対する詳しい回答は次のとおりです。 アサーションから何を取得したいですかテストのアサーションから何を取得したいですか?テストが失敗した後に赤いバーを表示するだけでは済みません。さらに、テストからいくつかの情報も取得したいと考えています。 1. テストが失敗したのはどこですか?すべてのアサーションがこの機能を提供できます2. テストが失敗した理由を定義するのは困難です。ほとんどのアサーションは同様の機能を提供できます: 期待される結果と実際の結果 ただし、アサーションが異なれば提供される情報も異なります。等しいなどの単純な主張を使用して比較することが難しい問題もあります。さらに、アサーションには文書化という非常に重要な役割もあります。つまり、テスト コードを読むと、すべての期待を満たしているかのようにアサーションが表示されます。そして非常に明確な期待。 実際の例assertThat の 2 番目のパラメータを見てください。org.hamcrest には非常に豊富な Matcher 実装があります。たとえば、API はユーザー オブジェクトのリストを返し、このリストに期待するユーザーが含まれていることをアサートしたいとします。hamcrest には hasItem のような Matcher があります。1: assertThat(userDAO.findAll(), hasItem(expected));
1: assertTrue(userDAO.findAll().contains(expected));
1: assertThat(userDAO.findAll(), not(hasItem(expected));
1: assertFalse(userDAO.findAll().contains(expected));
1: assertEquals(userDAO.findBy(id), expected);