実践JUnit 読んだ

夏季休暇取って連休なので、積本消化します。なぜか4冊追加したけど。

これね https://www.oreilly.co.jp/books/9784873117300/

書いてあること大体は首肯できる内容だった。 JUnit に関する内容だけど、テスト全般に言えることも多いのでjava以外にも応用できるはず。 コード自体はほっとんど読んでなくてザーッと見る程度。

以下メモ。書いてあることだけでなく、読者のお気持ちも含まれる。

  • めちゃくちゃ初心者向けという雰囲気
  • hamcrest は matchers のアナグラム
  • javaのサンプルコードよみたくねー
  • sut
    • system under test
  • クラスの振る舞いをテストする
    • なのでprivateをテストするのは良くない
      • privateも一応実行は出来なくはない
      • けどそれってテストとSUTが密結合になってしまう
      • ちょっと変更するたびにテストが落ちる => テストを修正する => めんどくせーからテスト書くの辞めるわになりがち
    • privateの中に興味深い処理がある
      • 単一責任になってないのでは
    • => クラスを分けるのが適切?
  • given-when-then
  • 全部のテストを実行すべき
    • は言い過ぎでなるべく多くのテストを実行する
    • DB操作など低速なのでパッケージを分けるなり、カテゴリ (@Category) 追加して遅いテストを分離しておく
  • 低速なコンポーネントへの依存を辞める
    • よく分からんやり方で実現してるけど、mock, stubで対処できそう
  • 時間を止めたいときは Clock を使う
  • test infected
  • infinitest?
    • ASだと動かないっぽい?
  • timely
    • 後からテスト追加しようはたいていしない
    • いま書こう
    • 実績がある古いコードはあまりテストを書く意味がない
      • 仕様書という意味でテストを書くのはありだと思ってる
  • 0-1-n
    • 0個か1個かn個かでテストを行えばいいケースがほとんど
  • リファクタリングにもテストは有効
    • リファクタリングしすぎてパフォーマンスが心配?
    • 「それがどうした」
    • まずはコードをクリーンにするのが最優先
    • クリーンならパフォーマンスを向上させるコードにするのも容易
  • ここらへんからかなりリファクタリングの話に寄ってくる
  • visitor パターン
  • モックがホントに使われているか確かめる
    • 実運用のコードをちょっと書き換えてみる
    • ありえない値をstubしてみる
      • 例えば緯度経度を0とかにしてみる
  • nullチェックはやらんでええ
    • javaだからかな
    • kotlinでもnullチェックしないで!!でunwrapするでも良いかも
  • 一つのテストに一つのアサーションが原則
    • 名前もわかりやすくなる
  • 他の関数を探し回らなくても理解できるのが良いテスト
  • ここでもAAAは出てた
    • arrange-act-assert-(after)
    • AAAごとに空行あける
    • Arrangeは@Beforeで分割出来るよね
  • テストのために設計を変えるのは嫌
    • テストで扱いやすい設計は実運用コードでも扱いやすい設計になっているはず
  • テストを書くときはまず失敗させろ
    • TDDでもよく言われているやつ
    • 成功するテストは何書いても成功する
    • 失敗するテストは成功させるために理解して書き直さなければいけない
  • マルチスレッドはテスト大変
    • アプリのロジックとマルチスレッドのロジックを分離する
  • 統合テストは大変
    • 例えばDB周り
    • ユニットテストで検証できるロジックを増やす
    • 統合テストは減らす
  • カバレッジ
    • 70%がライン
    • ただ数字だけを上げたいなら実は楽勝
      • assertしないで実行だけするとか
      • でもそれには意味がない