EveryDayRailsSpecを復習がてらやった、Cucumberは白痴？

https://leanpub.com/everydayrailsrspec
https://github.com/everydayrails/rspec_rails_4

これは、RailアプリをSpec含めてまるっと学ぶために良い知見を与えてくれます。
Code School もやってみようかな。

やったこといくつか

• modelに対するspec
• controllerに対するspec
  • controllerはrequest specよりも高速だが、modelやruby onject specより遅い
  • 1つのfeature specで、複数のcontrollerをカバーできる
• attributes_for
  • FactoryGirlで、属性のハッシュを作成する
• controller_specは、request_specで内包すれば良いのかなとも私自身も思っていたのですけど、controllerですませた方が良いところもあるかも。
• 以下のような棲み分けができるかも
  • request_specは、なるべくいくつものmethodをまたいだフルのハッピーパスを通すことができるレベルの試験を実施する
  • 細かな同値・境界値に対するspecはcontroller_specで内包、もしくはmodelでできるならmodel_specで実施する

Turnipで記述していたやつ、RSpecのfeature-specを参考に少し書き直してみようかな。
https://relishapp.com/rspec/rspec-rails/v/2-14/docs/feature-specs/feature-spec

• shared_examplesとit_behaves_likeのような記述、確かに使い勝手よいな。
  例えば、

のような場合、以下のように記載を簡単化できるのですね。

<br />describe "basic functions"

  describe "guest user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
  do

  describe "no-premium user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
    it_behaves_like "for non-premium users"
  do

  describe "premium user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
    it_behaves_like "for premium users"    
  end
end

• Turnipでは、このようなshared_examplesのような機能はなかったはず。。。sendやtable specで構造化できる箇所はある。
• feature_specのdescribe/it箇所をmarkdownなりで出力できるスクリプトを用意すると、それを使って非エンジニアの人とコミュニケーションにもなるかもしれない。
• Appiumの用途の場合、Table Specのように記述できる量って、もしかしたらあまりないのかもしれない。そうすれば、RSpecのfeature_specが現実的に一番実用性が高いのかも？

• stubやmockを使うことに関しても言及していますね。stubやmockを使うことで、局所的な関心ごとに対するテストの高速化を見込みます。一方、そのテストではあくまで保証できる動作は局所的な話しでしかないので、その局所的な領域以外の話は別に評価されなければいけません。
• 速度と網羅性がトレードオフになりますね。。。
• これを解決する手段としては、やはりrequest specでstub/mockを極力使わないC0カバレッジ100%を確認するなどが必要にも思えますが、サービスが巨大だとそれもかなわないかもしれないですね、、、

• Timecopのgem、日付に対するテストとして使えそう。

  • テストを実施する時間を止める（特定の日にする）
    • 特定の日に発生する事象を確認できる
  • テストの実施している間の時間を止める
    • タイムスタンプに対するテストを実施するなどで使える

ところで、 http://ssig33.com/text/DHH%20についての見解 でも書かれていたのですが、Cucumberを使うやつは白痴と書かれていたけれど、Cucumberというツールを使うことに対してなのですかね。ATDDのようなスタイルに対して言及しているのですかね。私はそこまで知見がないのでよくわからないけれど、CucumberのTable specやScenario Outlineのような記述は役立つと思うのだけれど。受け入れの自動化という階層では、シナリオを主体に考えられるので。
それとも、non-engineerを視野に入れているというところで彼の考えるところと違うのでしょかね。ふむ。