読者です 読者をやめる 読者になる 読者になる

テスト

先週のJUnitその1

先週のJUnitの復習

「最強のソフトフェアとは」小泉さん(説)

最強のソフトウェアとは変更に強いソフトウェアである。時代、人、場は変化してゆくものだが、それに対応できるソフトウェアこそ最強なのである。そして、変化できる事こそが、ソフトウェアのメリットなのである
では、変化できるソフトウェアとは具体的にどういうことなのだろうか。

それは、

変更した時にバグを出す事ができる事。

何どもテストを実施できたら最強のソフトウェアに近づく。そして、何どもテストを実施するためにテストを自動化するのである。
自動テストは、学習コストがかかっているので一概にコストがかからないとは言えない。なぜなら学習コストがかかったのにテストを一回きりしか行わないのではもったいないからである。しかし、最強のソフトウェアを作るためにテストを繰り返し行う場合、学習コストも無駄ではない。

私たちは最強のソフトウェアを作るために自動テストするのである

  • TDD(Test Driven Development)
    テストを行うことをベースに開発を進める。
    • Red(失敗)・・・まずはテストを書いて失敗させる
    • Green(成功)・・・Redだった箇所をGreenにすることを考えてガッと実装する
    • Refactor・・・リリースできる状態に改善する
  • BDD(Behavior Driven Development)

    ユーザーに対しての振る舞い

※自動テストだからといって全てを自動化できるわけではない。例えば、人間にしかわからない、「見栄え」や「操作感」などは人がテストするしかない。

JUnit

f:id:marikooota:20160515235025p:plain f:id:marikooota:20160515235016p:plain

  • 可読性の高いテストコード

プロダクションコードはメソッドの使い回しをするなど、重複する定義はまとめるべきだが、テストコードは重複したとしても、テストケースが独立していた方が可読性が高く実装しやすい。
つまり、何を前提として(Given)何を行い(When)何を期待しているのか(Then)が理解しやすいテストコードを書かなければいけない。
※When, Thenがない場合はGiven, Expect(事前準備ができているのか確認する)にする

テストケース・・・ある状態である入力(操作)をしたときにどのような結果を期待できるのかを記述したもの
SUT(System Under Test)・・・テスト対象となるクラスやオブジェクト。もし複数のSUTを一つのテストケースで扱った場合、そのテストケースで何のテストをしているのかが不明瞭になる。

  • アノテーションまとめ
    アノテーション 使い方
    @Test テストケースを定義したメソッドに付与する(テストメソッドの宣言)
    @Ignore 一時的にテストの実行を抑制したい場合に該当するメソッドをスキップできる
    @Before テストする前に実行してくれる(テストのブロックごとに)
    @After テストした後に実行してくれる(テストのブロックごとに)
    @BeforeClass 各テストで一回だけ、テストする前に実行される
    @AfterClass 各テストで一回だけ、テストした後に実行される