コードを書いていたりコードレビューで実装を眺めたりしていて、こういうケースでもうまく動いてほしいけど落ちそう、と思ってテストケースを足すと実際にテストが落ちる、ということがしばしばある。はたから見ると野生の勘とか嗅覚みたいな感じになりそうだけど、コツはあるはず。
条件分岐や追加された実装からアタリをつけるのは1つのコツだと思う。実装が増えるということは、考慮しないといけない場合が増えるということである。追加された実装を起点に、考慮漏れがないかを探ってみる。エッジケースに見えるかもしれないけどありうるユースケースを考えて、それを実現するテストケースを足して、テストを走らせてみる。落ちればアタリだし、落ちなくても保険としてテストケースを足しておくのがよいと思う。競技プログラミングをやっている人にとっては、撃墜ケースみたいな形で言語化されていそう。
アプリケーションの核となる機能や、壊れると体験を著しく損うので壊れてほしくないようなパーツには、相応のテストがあるとよさそう。なんでもアサーションするべきというよりは、最も保証したい性質を確かめていくというイメージでやっている。確かめていたつもりだけど実は不十分だった、ということにあとから気づくこともあるけど、気づけるようになるのが尊いと思う。
以前も野生の勘について書いていた。野生の勘が言語化・体系化されてパターンになっていくのだろう、と考えている。
