Skip to content

Instantly share code, notes, and snippets.

@tamago324

tamago324/ユニットテストのメモ.md

Created June 28, 2018 03:02
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save tamago324/6e5aa9638133e479bb75eaef050c6a2c to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save tamago324/6e5aa9638133e479bb75eaef050c6a2c to your computer and use it in GitHub Desktop.
Download ZIP
ユニットテストのメモを書いていく
Raw
ユニットテストのメモ.md

-　部品ごとにテストをすることで、その部品を使ったところでバグが出た時に調査する範囲が小さくなる

  • コードを書いたら、すぐテストする

  • ロジックのテストではなく、インターフェースのテストをする。もし、ロジックのテストを書いていたら、ロジックを修正するたびにテストも修正しないといけない。

  • 回帰テストをすることでリファクタリングによって影響が出ていないことを確認できる。

  • ホワイトボックスのテスト設計とブラックボックスのテスト設計の両方を用いる。 ホワイトボックスの考え方を用いて、境界値や同値分割のテストを実施。ブラックボックスの考え方を用いて、インターフェースでのテストを実施。

「ルール０ – 内部構造ではなく外的なふるまいをテストせよ」。つまり、クラスに対する期待値をテストするのであって現在の状態をテストするのではないということだ。 インターフェースのテストをしてね？ってことかな

  • ユニットテストはとにかく小さくする。もし、Webサービスやデータベースと連携するとしたら、それはユニットテストではなく結合テストなどのテストになる。
  • テストを先に書き、実行することでそのユニットには必要な機能を持っているかの判断が楽にできる。
  • テストの名前にドメイン言語を使う。"TestUpdateId"とかじゃなくて、もっと具体的な名前にする。未来の自分のために！！コードは読む機会が多いため、そのことを考えておくこと。
  • テストを短くする。1つのテストで1つのことをする。テスト名も簡潔になるし。
  • 1つのテストに1つのアサート。1つのテストの2つ以上アサートがあるということは2つのテストを行っているのと同じ。 また、1つ目のアサートで失敗した場合、2つ目以降のアサートは実行されない。また、たくさんアサートがあると、どのアサートで成功したか、失敗したがわからない。
  • テストはそれぞれで独立させる。テストAとテストBでお互いに依存していると、Bのテストを通すためにAを修正してしまうとか起きてしまう。
  • 適切なツールを使う。Cツールだけしか知らないから、Cを使うのではなく、適切なツールを選択すること。そのためにはいろいろやってみないとね。試すこと！
  • 何がユニットであるのかを定義すること

プログラマは、シンプルで速い、メンテナンスしやすいテストを書くために、数多くのテストコンセプトを知る必要があります。 私がプログラマに勧めるのは、 同値分割、境界値分析、テストカバレッジ、ポジティブテスト、ネガティブテストのような、いくつかの必要不可欠なコンセプトについて、同僚のテスタから学ぶことです。

テストの基礎を固めること

問題を分析し、可能ならば、分割し、それから、書かなければならないユニットテストは何かを考えます。 ここでアドバイスしたいのは、常にシステムのアウトプットから始めることです。 そして、そのアウトプットを生成する、起こりうるインプットを明らかにします。

この機能ではこんな出力にしてほしい！そしたら、こんな入力が必要になるね！という感じ？

  • カバレッジは不十分であることを示すが、十分であることを示しているわけではない。テストが通っていることはわかるけど、そのテストケースが十分であるかの判断はできない。

参考文献

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment