概要: 主に上記の記事を読んでの感想というか僕の意見
基本的に僕は、Web App のテストを書くとするならば、
- 外部向け API のテスト
- 内部向け API のテスト
- UI/UX の動作テスト
を中心に書くかなぁと思う次第です。
僕は最近というより、以前から Web App を書いた経験が少ないというかほとんどないので、あんまり分かってない感じですが、とりあえず、機械的に処理できる、
- 外部向け or 内部向け の API テスト
に関しては、
- これが正常な動作である
と定義するためのテストは必要ではないかな、と思います。
で、あと UI/UX のテスト、具体的には Angular.js とか Knockout.js とかで、
- UI のアクションをトリガーに行う 動作
についてのテストはキッチリと書いておいた方がいいんではないかなぁと僕は思います。
例えば、あるボタンを押すと XMLHttpRequestが飛ぶとか、そういう内部的かつ機械的にテストできる、そういった感じの範囲のヤツであれば、テストで機械的に動作チェックしておくと、後々改良する際に楽じゃ内意かなぁと思うのです。
あと僕は基本的に、 テスト っていうのは、
- これこれの動作はこうあるべき
と記すための一種の仕様書みたいな存在だと思うので、小さなスクリプトならともかく、ある程度の大きいコードだと、テスト書かないとプログラマーが死ぬ気がしています。
っていうか最近の@mizzy さんとかが作ってる serverspec とか configspec とか、そういうのって、
- 仕様書としてテストを書く
って感じだと思うので、Web API のテストとかもそういう感じで書いていけば良いのではないかなぁと僕は思います。
ちなみにこれは僕が最近死んだ例ですが、Golang みたいな静的型付けの言語で、JSON や XML を Decode/Encode (Golang だと Marshal/Unmarshal) する際には、本当に細かい JSON or XML オブジェクト単位でテスト書いた方がいいです。
僕の今作ってる、
で経験したんですが、Atom Feed を Golang の構造体に Unmarshal する際に、
- ガッとコードを書き
- ガッとテストを書き
- ガッとテストを実行！
したら、
＿人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人＿ ＞ Unmarshal は出来るけど、構造体にマッピングされてない！！！ ＜ ￣ Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ￣
という状態になって、色々となにがなんだか分からない……となって、最終的には一からコード書き直した、というケースをつい先日経験したので、基本的には JSON や XML の Decode/Encode はキッチリテスト書いた方が良いと思います。本当に……。
という訳で今日の記事は終了。
なんかリンク先の記事と論点がずれてる気がしないでもない。
#FIXME
