Cucumberとは

最近CSD研修を受け初めてCucumberの存在を知りました。
「きゅうり」という何だかよくわからないワードに強烈に惹きつけられました。
以下公式ドキュメントからの引用です。

Cucumber is a tool that supports Behaviour-Driven Development(BDD).
Cucumber reads executable specifications written in plain text and validates that the software does what those specifications say.

要約すると、きゅうりはBDDを支援するためのツールで平文で書かれたシナリオとテストコードの紐づけをしてくれます。

Scenario: 検索する
  Given 文字列を入力する
  When 検索ボタンを押す
  Then 検索が実行される

このようにシナリオのステップを列挙していき、プロダクトが仕様に沿って作られていることを確認します。
また、このシナリオの集合体をフィーチャー（機能）と呼びます。そして、Cucumberがシナリオを理解するための構文規則をGherkinと呼びます。

##Gherkin?

Gherkinってなんだ？と思い、調べてみました。

(酢漬け用)小キュウリ、ガーキン

###またきゅうりかよ！！！
どんだけきゅうり推しなんだよ・・・
ここでふと思ったのが、そもそもなんでCucumberって名前なのか。BDD支援ツールときゅうりの関連性が全く思い浮かばびません。
公式ページでも調べてみましたが、名前の由来には特に言及されていませんでした。
情報を漁っていたところ、作者であるAslak Hellesøy氏のインタビュー記事に名前の由来が書いていました。
https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years/

My wife suggested I call it Cucumber (for no particular reason), so that's how it got its name. I also decided to give the Given-When-Then syntax a name, to separate it from the tool. That's why it's called Gherkin (a small, pickled Cucumber).

for no particular reason（特に理由はないのですが）

！？

Cucumberを使うメリット

少し話が脱線してしまいましたが、ここでCucumberを使うメリットについて考えたいと思います。

ATDDを可能にする

Cucumber自体はBDDの支援ツールと銘打っていますが、CSD研修ではもう少しスコープを拡大し、ATDDにてCucumberを利用してました。
ATDD(受入テスト駆動開発)だと何がいいのか。ATDDのスタートはまずその名の通り、受入基準の仕様書を書くところから始まります。その受入テスト仕様書を自然言語で書くことができ、それがそのままテストコードと紐づきます。
これがCucumberを使ったATDDの一番のキモで以下の恩恵を受けることができます。

企画と開発の仕様に関する認識のズレをなくす
featureファイルを見れば誰でもプロダクトの機能仕様を把握できる
コードと直結する信頼性の高い仕様ドキュメントが必然的にできあがる
CIと連携することにより手動テストの削減できる

1に関してはもう企画がfeatureファイル書いちゃえばいいんじゃないかと個人的に思います。
2,3ができることでコードの属人化が防げるのではないかと思います。
4についてはATDDは受け入れテストなので、自動化によってそのままリリース前テストのコスト削減に繋がります。

Cucumberを使ったATDDをiOS開発へ

私自身普段はiOSエンジニアなので、CSD研修で学んだこのATDDの仕組みをiOSにも取り入れられないか模索しました。(研修ではJavaを用いたWebアプリケーション開発でした)
以下実際に構築したiOSにおけるシステム構成です。

Stepsの定義までをGherkinが担い、以後のテストをJavaメインに作りました。
JUnitのテストランナーとしてCucumberを指定し、端末制御をAppiumのJava Client Libraryにて行なっています。
JUnitを使用してキュウリシナリオを実行する

適用範囲

実際にCucumberを用いATDDできる環境を整え、実際に様式通り開発を行えれば理想的だとは思います。
ただ、正直TDD自体コストが高いので人材が潤沢なサービスであればいいですが、そうでなければなかなか厳しいかなとは思います。
なので、まずは回帰テストなど繰り返し行う部分をCucumberを用いたシステムで自動化してあげて必要最低限のプロダクトの仕様書の作成と手動テストの削減を行うのがいいのかなと思います。