カラクリサイクル

『輝かしい青春』なんて失かった人の雑記

言及

概要: 主に上記の記事を読んでの感想というか僕の意見


基本的に僕は、Web Appのテストを書くとするならば、

  1. 外部向けAPIのテスト
  2. 内部向けAPIのテスト
  3. 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する際に、

  1. ガッとコードを書き
  2. ガッとテストを書き
  3. ガッとテストを実行!

したら、

_人人人人人人人人人人人人人人人人人人人人人人人人人人人人人人_
> Unmarshalは出来るけど、構造体にマッピングされてない!!! <
 ̄YYYYYYYYYYYYYYYYYYYYYYYYYYYY

という状態になって、色々となにがなんだか分からない……となって、最終的には一からコード書き直した、というケースをつい先日経験したので、基本的にはJSONやXMLのDecode/Encodeはキッチリテスト書いた方が良いと思います。本当に……。


という訳で今日の記事は終了。

なんかリンク先の記事と論点がずれてる気がしないでもない。