まずは、どんなテストは書かないでよいか。技術的に書けないということもあるし、書く手間が正当化できないということもある。
- テンプレート(.kid) - テンプレートには画面の構成やデザイン、レイアウトと、機能性とが含まれている。見た目の部分は、これはテストを書けない。マークIアイボールを利用したテスト(人間が目で見る)のが一番だ。機能性の部分はできればテストを書きたいところだが、.kidファイルのテストを書く方法が技術的に分からない。いや、.kidファイルは.pycにコンパイル(?)されているのだし、仕様をよく読めば方法はありそうな気はする。だが、それよりはテンプレートに機能性は極力入れないことで、テストを書かないで済ますのがよさそうだ。
- モデルのCRUDアクセス - SQLObjectを使う場合だが(SQLAlchemyはまだなにも調べてないのです。もちろん使ったこともない)、基本的なアクセス、Create/Read/Update/DeleteについてはSQLObjectが面倒を見てくれるので、テストを書く必要はない。もっとも、複雑なリレーションがある場合などは、「仕様どおり」にできているかどうかを確認するためのテストを、書きたくなる場合はありそうだ。Readについては、検索条件などをメソッドとして実装することがあるので、テストを書いたほうがよい。と言うか、モデルに対してメソッドを実装したなら、そこはテストを書くべきだ。書かないでよいのは、つまるところ自分で書いていない部分だけ。
- JavaScript - えええと、すいません。JSの単体テストフレームワークが存在することは知ってるんですが、使ったことないのでパス。自分は主に画面デザインとべったりの部分をJavaScriptで書くことが多いので(それ以外はサーバーサイドに持っていってしまう)、JavaScriptのみの単体テストがあまりメリットがないということもある。
