FIRSTの原則というものがあります。
Fast（テストは早いほうがいい）
Isolated（プロダクトコードと疎な関係のほうがよい）
Repeatable（何度も繰り返し実行できる＝状態をもたない）
Self-validating（結果検証がコードで出来ている）
Timely（適切なタイミングで行われる）
これが良いテストの原則として、「Clean Code アジャイルソフトウェア達人の技」（Robert C. Martin , アスキー・メディアワークス, 2009）などど語られています。
これは正しいです。圧倒的に正しい。
だが、テストはこれだけ守ってればいいわけではありません。それよりももっと大事なことがあります。
それは「意味のあるテストをすること」です。
これは当たり前すぎて書籍では語られないのかもしれません。しかし、私の経験では多くの現場で意味のないテストが書かれていることが多いです。意味のないテストは如何にFIRST原則を守っていても、如何に素晴らしいテストコードであっても、如何に美しいパイプラインを構成していようと限りなく無価値に近いです。
「意味のないテスト」とは主に「バグが見つけられないテスト」です。
例えば以下のようなものがあります。
・必ずPassするアサーションしかない
・ほぼ同じテストが既に存在している
・同値クラスの同じ集団ばかりつかっている
・カバレッジをあげることだけ考えて意図がないためにアサーションの意味がない
・ソートするコードに、ソート済みのデータを与えるなどのバグに気付かない条件を与えている
など。
自動テストは大事だし、その実装方法も大事なのだけれど、それ以前の問題としてテスト自体の目的を見失わないようにしないといけません。
どんなテスト書けばいいんだろう、っておもったらまずはどんなバグを見つけるテストにするか、どんなリスクを顕在化させるテストにするかを考えましょう。