テストしやすいというのはどういうことか。

っていうのをちょっと考えてます。
WebのプログラムっていうのはMVCに分かれてるとか、特にモデル部分っていうのはDBにアクセスする部分とビジネスロジックとが分離してるといいよ。それらが別々にテストできるといいとか。何かができてないときは、そこをモックで生めてテストするとか。
たぶん、そんな感じなんだと思います。

でも世の中はそんなにうまくなくて、ぐちゃぐちゃなのが大半で。それをどううまくテストするかっていうことに頭を悩ませるのがお仕事なんだろうなぁ。

いっちゃん簡単なテスト。
ブラウザで開いて、表示されるかどうか見る。
この辺が一番初め。
いろんなパラメータで試す。
んで、それだとアプリ単位でのテストだから、さらに中身を切り分けて・・・っていう段階なのかな？
そもそもこれって結合レベルのテストだよね。処理単体でのテストを書く方がバグが防げるとか、バグが起きたときに範囲を絞れるとかそういう利点があるんだよね、たぶん。

もうちょっと掘り下げて考えよう
メソッド単体でユニットテストを書く。
んで、実行するのに必要なことは？それが単体で実行できるかどうかっていうこと。
引数で渡すオブジェクトは用意できるかどうか？処理が大きすぎないかどうか？
DBの状態はどうなっているか？
DBの状態に依存しないテスト、パラメータに依存しないテスト。この辺はDBやパラメータ単体でのテストが必要になるだろうし。
そういうきりわけが必要。
もちろんメソッド一つでは文脈的に意味が無い場合も多いし、クラスが組み合わさって動作する場合にはその単位でテストするのに意味があるだろうし。
ただ、それらが最小の範囲に収まるようにうまくテストしないといけませんよね。

書きすぎるテスト？
そこまでする必要があるのかが分からないテストもあるかもしれない。
必要なのは、失敗しそうなものを探すことかもしれない。
きわどいこと。
仕様を確認したいなってところ。
境界線ぎりぎりのところだったり。
一般的じゃない。そもそもこうしてくれっていう願い以外のところ。

まずは処理の噛み砕きガ必要。

あとは、依存性を少なくすること。
オブジェクト指向ってやつだ。
そのクラスの状態はそいつが責任もたないといけない・・・とか。
メソッドの引数がやたらおおかったり複雑化してもいけない・・・

あー、副作用があるとテストできないか・・・それが大きいな。