読者です 読者をやめる 読者になる 読者になる

自動テストがない状態から、受け入れテストを書くとき何書いたらいいのかメモ

自動テストがない時

→受け入れテストから始めるのがセオリーらしい(ATDDとか)

しかし、受け入れテストで何書いたらいいのかが意外とちゃんと書かれてない印象。

 

 

受け入れテストで、あまりページの要素を細かくチェックすると壊れやすくなる+スローテストになる。

  • うまく単体テスト側でカバーしましょうとなっているけど、その単体テストがない。。。卵が先かニワトリが先か

 

使用するテストツール

  • WebAPIだったらxUnitとかrspecとかそういうの
  • ページだったら、selenium、capybara

 

 

最初のチェック項目

まずは、薄く広く網をかける。

  • アクセスするとページが返ってくるか確認
  • ステータスコード
  • (可能であれば手動の画面チェックリストでチェックしている項目をコードに落としていく)

 

気軽に書いて、捨てる(この辺りは我流)

  • 要素をチェックする部分は壊れやすいが、短期間であればそこそこ役立つ
  • (画面仕様はそこまで変わらないけど、テストデータを毎回整えるのが意外と難易度高い)
  • 動かなくなったら、割りきってその部分は捨ててしまう。

 

参考

あーありがち - 実はCapybaraってよく分からないんです

レガシーなコードもたくさんあるのでそういうときにせめて外からテスト揃えておくと安心だよねぇと調べてから思ったけど、それって

Rails での spec:requests にも同じことが言えるんじゃ?

と思い始めた。今まで request を元に内部で分岐する部分のテスト以外は真面目に書いてなかったけど、

単にちゃんとページが返ってくる

ことを spec でガードしておくのも大事だなと急に思い直した。初期の頃にはほとんど意味を感じない spec だけど、ある程度複雑になってきたときに予想していなかったところに影響が出てしまったことを素早く検知するために、

「ページが表示されて当たり前じゃん」と思っていても spec:requests は書いておいた方がいい

 

xUnitのルーツから考えると、サンプルコードを書くことから始めるのがよさそう

挫折しないための自分用メモ

 

 

アジャイル開発とTDDを半年間実践してみた顛末と、これから

0-9, TDDの準備としてのサンプルコードテストのすすめ

 

テスト駆動開発ハンズオン後編

 

xUnitのオリジナルはSUnitで、原作者のケント・ベック氏はインタビューでこう答えている。

『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。:An Agile Way:ITmedia オルタナティブ・ブログ

Kent: ぼくの職業プログラマとしての最初は、Smalltalkだった。Smalltakはテスティングの習慣がある。ちょっとプログラムを変更したら、ちょっと動かしてみる。というインクリメンタルなサイクルを回す。でも、それは自動化されていなかった。以前コンサルタントとして開発プロジェクトに助言を求められたときに、自動テストを書いてみるようにすすめたかったが、やり方がなかった。Smalltak でやっていることの構造を、そのままオブジェクトモデルにそのまま実装したらどうなるか考えた。Workspaceがクラスで、変数がインスタンス変数、テストしたいコード片がメソッド。これは、ナイーブなマッピングだ。そこで、マニュアルでテスティングしている部分、すなわち、プリントアウトして期待される結果と比較することを、「じゃあ、ここはコンピュータにやってもらおう」と考えた。これが、assertionの原型。ここまでが、アーキテクチャの起源だ。いつごろだったかな、うーん、1992かな。これが最初のユニットテストフレームワーク

 

ワークスペースとは、Smalltalk環境におけるターミナル画面(+エディタ)のような物。

 

加えてSmalltalkにはサンプル用のコードをクラスにつける習慣がある

(メソッド分類におけるexamplesカテゴリの存在)

 

Pharo(Smalltalkの実装のひとつ)マニュアルより

PharoByExample-japanese/SUnit/SUnit.tex at master · SquareBracketAssociates/PharoByExample-japanese · GitHub

 

\st コミュニティは、長らくテストを重視してきました。\st のプログラミング環境ではインクリメンタルな開発が容易だからです。
\st の伝統的な開発では、プログラマはメソッドを実装するとすぐにワークスペースでテストします。
メソッドのコメントにテストを書いたり、セットアップが必要なテストはサンプルメソッドとして実装したりする場合もあります。
しかしこれらの方法には問題があります。まずワークスペースにテストを書いた場合(イメージファイルを共有しない限り)他のプログラマから使えません。
コメントやサンプルメソッドにした場合、状況は多少改善されますが
それでも、メソッドの開発に合わせてテストを見直し、さらに自動的に実行させるのは簡単ではありません。