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

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

自動テストがない時

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

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

 

 

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

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

 

使用するテストツール

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

 

 

最初のチェック項目

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

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

 

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

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

 

参考

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

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

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

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

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

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

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