ユニットテストをつくってみて、注意点など忘れそうなのでメモにまとめました。
どこまでテストをつくるかは難しいですが、必要な箇所をチームメンバーと確認して漏れがないようにカバーしておくべきかと思います。
〇ユニットテストについて
範囲を絞った状態の自動化されたテストをつくることでコード上の欠陥をみつけることができます。
・１つのテストに１つのアサーションをして、どこの部分がダメかわかるようにする。（テストの失敗の原因を分かりやすくする）
OCでは、UnitTestsとIntegratedTestsの２つの自動化されたテストがあります。
<UnitTests>
メソッドのテストのみを行う。
→クラスのメソッドに引数を渡して期待通りの処理をするかなど
・基本的には、getterやsetter以外のpublicメソッドは全てテストをつくる。
・privateメソッドのテストについては、重要なものであればテストつくったほうがよい。
・別クラスなどからメソッドが呼び出されている場合は、そのメソッド自体と呼び出し元のメソッドの両方ともテストをつくる。
例）以下の場合であれば、saveDriverStatusもinsertStatusDBもupdateLastDriverStatusもテストを作る。
public function saveDriverStatus($status){
$isSuccess = $this->insertStatusDB($status);
if($isSuccess){
$this->updateLastDriverStatus($status);
}
}<IntegratedTests>
大きな機能そのものを一連の流れを通してテストします。
→１つの大きな機能を最初から最後まで実行して問題なく機能するか（シナリオテストも含む？）
→複数のメソッドまたはクラスを組み合わせても問題ないかなども確認する
→範囲の大きい他ファイルを実行するようなテストにしてしまうとどこで欠陥が発生しているか分かりづらいので、範囲を作成した機能部分のみにするなど対象範囲を広げすぎないようなテストにする
・機能の設定でON/OFFなどの条件があるものは、それぞれの条件でのテストをつくる
例）「配送先が近くにある場合でも停滞検知するか」という設定項目がある場合→設定ONでのテストと設定OFFでのテストをそれぞれ作成