[追記] 次に書いたScenario, stepのリンク集もどうぞ：
http://blog.s21g.com/articles/1441

Given, When and Thenの基本はわかったんだけど、なんとなくスマートに書けるようになるにはまだ足りない気がする。というので色々snippetとして集めてみました。
(文法的にはもう古い物もあるので注意)

Given, When and Then

基本はここで：
http://wiki.github.com/aslakhellesoy/cucumber/given-when-then

Given -> When -> Then の順にしかこないのかと思ったら、下記にシナリオの途中にあらわれるThenもあった：
http://www.benmabey.com/2008/02/04/rspec-plain-text-stories-webrat-chunky-bacon/

   1    Scenario: A visitor successfully submits a new animal
   2      Given no animal named 'Alligator' exists
   3      When visitor goes to /animals/new
   4      Then visitor should see the Animal submission form
   5      When visitor submits an animal with name: 'Alligator', phylum: 'Chordata', animal class: 'Sauropsida', order: 'Crocodilia', family: 'Alligatoridae', genus: 'Alligator', and lay eggs:  'true'
   6      Then an animal named 'Alligator' should exist

Thenの後にWhenがくるのもありなのかも。

Stepの入れ子

http://wiki.github.com/aslakhellesoy/cucumber/calling-steps-from-step-definitions

   1  Given /^(.*) is logged in$/ do |name|
   2    Given "the user #{name} exists" 
   3    Given "I log in as #{name}" 
   4  end

記事作成のfeature

http://railscasts.com/episodes/155-beginning-with-cucumber

   1    Scenario: Create Valid Article
   2      Given I have no articles
   3      And I am on the list of articles
   4      When I follow "New Article"
   5      And I fill in "Title" with "Spuds"
   6      And I fill in "Content" with "Delicious potato wedges!"
   7      And I press "Create"
   8      Then I should see "New article created."
   9      And I should see "Spuds"
  10      And I should see "Delicious potato wedges!"
  11      And I should have 1 article
  12  
  13  #article_steps
  14  Given /^I have no articles$/ do
  15    Article.delete_all
  16  end

Scenarioは完結に、Stepで細かく

Imperative vs Declarative Scenarios
http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/

Scenarioを短くnarrativeに書いて、stepで細かいフォーム入力などを扱う感じに書かれていて一番しっくりきました。

Imperative 命令法/形の
Declarative => narrative 叙述の

   1   Story: Animal Submission
   2    As a Zoologist
   3    I want to add a new animal to the site
   4    So that I can share my animal knowledge with the community
   5  
   6    Scenario: successful submission
   7    Given I'm on the animal creation page
   8    When I add a new animal
   9    Then I should see the page for my newly created animal
  10    And the notice 'Thank you for your animal submission!'

   1  # animal_steps.rb
   2  When "I add a new animal" do
   3    fills_in 'Name', :with => 'Alligator'
   4    selects 'Chordata', :from => 'Phylum'
   5    fills_in 'Animal Class', :with => 'Sauropsida'
   6    fills_in 'Order', :with => 'Crocodilia'
   7    fills_in 'Family', :with => 'Alligatoridae'
   8    fills_in 'Genus', :with => 'Alligator'
   9    checks 'Lay Eggs'
  10    clicks_button 'Create'
  11  end

最新にしたらpaths.rbとBackgroundが追加されていたのでメモ。

features/support/paths.rb

Cucumberを最新にしてfeatureをgenerateしようとしたらpaths.rbがないと怒られたので、script/generate cucumberでpaths.rbファイルを生成しました。

Scenarioで記述するページはここで定義：

   1  ＃features/support/paths.rb
   2  module NavigationHelpers
   3    def path_to(page_name)
   4      case page_name
   5      when /the homepage/
   6        root_path         

Background

1feature内のScenarioに共通な前提条件を記述する。
Backgroundで書かれた条件は、各Scenario実行前、かつBefore Hookの後に実行されるようです。

The background is run before each of your scenarios but after any of your Before Hooks.
http://wiki.github.com/aslakhellesoy/cucumber/background

   1    Background:
   2      Given a global administrator named “Greg” 
   3      And a blog named “Greg’s anti-tax rants” 
   4      And a customer named “Dr. Bill” 
   5      And a blog named “Expensive Therapy” owned by “Dr. Bill” 

Cucumberのfeatureを実行すると、上記のエラーが出て困ったので探したら

I resolved it by uninstalling the old "bryanary-webrat" gem and making sure that "webrat" was up to date (0.4.3)

When you have both installed, ruby tends to load the old one instead.
http://groups.google.com/group/webrat/browse_thread/thread/d8ea685a1b1931a5#

古いwebrat gemを消しなさいと。

   1  gem search webrat
   2  
   3  *** LOCAL GEMS ***
   4  
   5  aslakhellesoy-webrat (0.3.2.2)
   6  webrat (0.4.4, 0.4.3, 0.3.4)

案の定古いwebratがあったのでaslakhellesoy-webratをuninstallしたら動きました！

submoduleネタをゲットしたのでメモ。

@githubのtwt：

GitHub gem builder will now pull in submodules prior to the build.
4:05 AM Apr 9th from web
http://twitter.com/github/status/1478454260

てことは配布しているgemではsubmoduleをpullしてくれるってことでしょうか！！
いいですね！

しかしtarball builderはsubmodule未対応

@github is there any plan to have the tarball builder do the same thing?
http://twitter.com/larrywright/status/1478514289

@larrywright not at the moment. We use git-archive which, for some unknown reason, doesn't support submodules.
http://twitter.com/github/status/1478579621

その1でsubmoduleをaddし、git-submodule statusコマンドでステータスを確認するところまでの作業をしました。
今度はaddした以外の人がpullして、submoduleを確認するところを書いてみます。

submoduleを取得：init & update

   1  git pull --rebase #submoduleを追加したコミットを取得
   2  git submodule 
   3  -e110f2056783465b8d719bdb1ab5fd14e7650f56 vendor/plugins/rspec

(-がついているので)この時点ではrspec submoduleが初期化されていません。よって下記のコマンドで初期化します：

   1  git submodule init
   2  git submodule update

又は

   1  git submodule update --init

updateすることによりソースファイルを取得します。
これで、addした以外の人もsubmoduleを追加することができました。しかし、まだこれで終わりではなくて実はいくつか検討すべき点があります：

• submoduleに修正を加えないかどうか
• どのバージョンを使うか：commit hash
• (railsの)deployはどうするか：Capistrano
• submoduleの削除

外部のrepoをそのままか、forkしてからか

submoduleをaddする前に検討すべき事項です(!)：
追加するremoteリポジトリを変更したくなる可能性があるかどうか検討する必要があります。例えばrailsやrspecなら変更を加えるというのはほとんどないように思われますが、完成度の低いpluginだと自分で修正したり、追加したりすることが考えられます。そのような場合、下記のようなシナリオが考えられます：

1. remoteをsubmodule(変更しない)
2. Githubであればforkして、それをsubmoduleにする
3. 自分のローカルにcloneして、それをsubmoduleにする
4. サーバにrepoを作ってremoteのファイルを追加、それをsubmoduleにする

1,2はなんとなく想像できますが、3,4は運用が面倒そうです...
また、railsまでsubmoduleにする記事もあったのですが、毎回deploy時にコピーすることになるのでdeployに時間がかかるだろうし、容量も食うので運用には向いていないかもしれません。

どのコミットをsubmoduleとして採用するか

submoduleを利用する際、外部のbleeding edgeブランチを積極的に採用したくはありません。なので、タグか特定のバージョン(コミット)を利用するのが適切です：

   1   cd vendor/plugins/rspec/rspec
   2   git tag 
   3  1.1.10
   4  (略)
   5  1.2.1
   6  1.2.2
   7   git checkout 1.2.2
   8   cd ../../..

rspecのタグ1.2.2を採用しました。このあとRAILS_ROOTに戻ってcommit, pushすればokです。
この後、他の人がこの変更を反映するには下記の作業を行います：

   1  git pull --rebase #submoduleを追加したコミットを取得
   2  git submodule update

Capistranoでsubmoduleを使えるようにする

一行追加するだけ！

   1  set :git_enable_submodules, 1

via http://github.com/guides/deploying-with-capistrano

submoduleの削除

rspecを例に：

1. .gitmodulesファイルから該当する行を削除
   

      1  [submodule "vendor/plugins/rspec"]        
      2  path = vendor/plugins/rspec        
      3  url = git://github.com/dchelimsky/rspec.git
   

2. .git/configファイルから該当する行を削除
   

      1  [submodule "vendor/plugins/rspec"]        
      2  url = git://github.com/dchelimsky/rspec.git
   

3. git rm --cached path_to_submodule
   パスの最後に/(スラッシュ)がない状態で：
   

      1  git rm --cached vendor/plugins/rspec
   

4. git commit、pushでおしまい

via http://git.or.cz/gitwiki/GitSubmoduleTutorial

.gitmodulesファイル

初めてsubmoduleを追加すると、下記のファイルが追加されます：

   1  .gitmodules

その他に.git/configも変更されます。

submoduleをもっとよく理解するRefs

• ここの解説が一番わかりやすかったです：
  http://woss.name/2008/04/09/using-git-submodules-to-track-vendorrails/
• vendor/railsにsubmodule使おうぜ！という...！
  http://woss.name/2008/04/11/using-git-submodules-to-track-vendorrails-2/
• submoduleがうまく動かなかったレポート
  http://blog.buildingwebapps.com/2008/5/20/got-git-submodules-not-a-go-go

[追記] その2を書きました：
http://blog.s21g.com/articles/1411

長くなりそうなので続きはその2で！

railsを使っているとpluginなどは外部repoをそのまま使いたくなります。そこで前から聞いていたsubmoduleを使ってみたくなりました。しかしこのsubmodule、わりと最近導入されたようなのでgitのバージョンによって動作に違いがあるようです。

というわけで、まず私の環境を書いておきます：

   1  % git --version
   2  git version 1.6.0.2

git submodule add

rspecを例に：

   1  % git submodule add  git://github.com/dchelimsky/rspec.git vendor/plugins/rspec

追加したらcommit and push

   1  % git commit -am "add submodule: plugins/rspec" 
   2  % git push origin master

これでサーバにsubmoduleが追加されました。他の人がpullなどすれば、submoduleを確認することができます(詳しくはその2を参照)
で、次にsubmoduleのstatusを確認してみます。

git submodule status

git statusと同じようなコマンドでsubmoduleの状態が確認できます：

   1  % git submodule status 
   2  9dc19a3a593f4ce1b4e221889091cebd773ea5c4 vendor/plugins/cache_fu (heads/master)
   3  -e110f2056783465b8d719bdb1ab5fd14e7650f56 vendor/plugins/rspec 651611999df3e57de6f36486b51abd3bf5d66cea vendor/rails (v2.2.0-1085-g6516119)

commit hashに-、+がついている時がある(上だとrspecに-がついてます)。
ざっくり説明：

• -がついているとまだ初期化されていない状態
  => git submodule update --initでok
• +がついているとサーバでindexしているcommit hasと異なるcommit hashだよというお知らせ
  => git submodule updateでok

このアプリは初めて企画したiPhoneアプリです。ezPhotoMailの方が後に作ったのですが、DBへのアクセスの勉強や、デザインの調整など色々しているうちに、リリースが遅くなってしまいました...なので思い出深い製品です！

今回はデザインを美術部さんにお願いしました。アイコンから、ボタンから背景までピンクなので、このhappy lovely pinkで日々の面倒な買い物リスト作りが楽しく思えたら幸いです！また、美術部さんのサイトでは素材提供も考えておられるとのこと、ぜひ定期的にチェックをお願いします！

Shopping Pink

シンプルなインターフェースで買い物リストが作成できます。ピンクを背景だけでなくアイコン・ボタンにも用いており、かわいらしさが特徴です。

iTunes URL:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=307045581&mt=8

特徴

• ピンクをテーマに背景を4つ用意
• 1タップで背景を変更することが可能
• シンプルな入力インターフェース
• 買い物アイテムの再利用が可能：History

Shopping Pink URL: http://www.s21g.com/ShoppingPink.html

iPhone appのバージョンアップを申請後、時期verを開発継続している際にrejectされた、という場面があったので、タグ・ブランチでの運用を始めました：ezPhotoMail2度目のrejectを食らってしまいました orz

rails@githubの場合：命名

ブランチ：バージョン＋stable/unstableの形
http://github.com/rails/rails/tree/2-3-stable

タグ：タグ名はvが入っている形
http://github.com/rails/rails/tree/v2.3.2.1

railsを参考にezPhotoMailでの運用を決めました、下記。

ezPhotoMailでの運用：命名

appリリース後、新しいバージョンをリリースする場合はタグを付けます：タグは後付けも可能。 ブランチ名にはタグ名のvがない、数字だけのものを採用することにしました。

ex

• タグ名：v1.1
• ブランチ名：1.1

タグ名とブランチ名を同じにするとcheckoutやshowなどでrefspec(refs/heads/1.1, refs/tags/v1.1などの形式)を挙げねばならず運用が面倒。

ezPhotoMailでの運用：rejectされた

• タグ名のvを取ったブランチがあるか確認、なければブランチを作成して修正

     1  git branch -r
     2  git checkout -b 1.1 refs/tags/v1.1 #1.1ブランチを作成してcheckout
     3  git push origin HEAD:refs/heads/v1.1 #HEADはカレントブランチ。refs/heads/v1.1はサーバ上のブランチ名
  
• ブランチがあれば、checkoutして修正
• Info.plistのversionの末端を+1する：1.1→1.1.1
• 申請用のzip作成：appName_1.1.1.zip
• add, commit・push
• (各ブランチを最新にして)1.1ブランチをmasterブランチにマージ

     1  git checkout 1.1
     2  git pull --rebase origin v1.1:1.1 #v1.1=サーバブランチ
     3  git checkout master
     4  git pull --rebase origin master #サーバでもローカルでも同じ名前master
     5  git merge 1.1 #masterに1.1をマージ
  
• 申請作業

ezPhotoMailでの運用：申請が通った

ブランチのInfo.plist内のバージョンを確認して、タグを作成。

おまけにしようと思ったのですが、長くなりそうなので別記事にします。

ブランチv1.1をサーバにpushする：

   1  % git push origin refs/heads/v1.1

タグv1.1をサーバにpushする：

   1  % git push origin refs/tags/v1.1 
   2  Counting objects: 1, done.
   3  Writing objects: 100% (1/1), 159 bytes, done.
   4  Total 1 (delta 0), reused 0 (delta 0)
   5  To ssh://git.s21g.com/mnt/git/ezPhotoMail.git
   6   * [new tag]         v1.1 -> v1.1

ローカルのタグをすべてサーバにpushする：

via http://github.com/guides/push-tags-to-github

   1  % git push --tags

サーバのタグを取得するには

tagをpushしたサーバ上のrepoをcloneすればtagも勝手に取得してくれるようです。cloneしてから、tagのブランチを作れば内容が確認できます。

   1  % git tag -l
   2  v1.1
   3  % git checkout -b 1.1 refs/tags/v1.1

又はブランチを作らずに内容を確認：

   1  % git checkout refs/tags/v1.1

ブランチ、タグ両方にv1.1があると、ambiguousだと怒られました。

   1  % git show v1.1
   2  warning: refname 'v1.1' is ambiguous.

ということで探してみたら、下記の記述：

• ブランチ "test" は "refs/heads/test" の略記です。
• タグ "v2.6.18" は "refs/tags/v2.6.18" の略記です。
• "origin/master" は "refs/remotes/origin/master" の略記です。
  http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#how-git-stores-references

fmfm フルパス？で指定してみると、うまく表示されました！：

   1  % git show refs/tags/v1.1