CUCUMBER | Project Background - PicklesJar/pickles GitHub Wiki

Cucumber とは、BDD を志向した開発ツール(テストツール)のことです。

Test automation with Cucumber-JVM - SlideShare

元々は Ruby で開発されたテストフレームワークでしたが、その後様々な言語をサポートするようになり、もちろん Javaもサポートされています。(Java 版を限定する際は、Cucumber-jvm と呼称されるようです。)

このフレームワークの特徴をあげると、まずは設計思想のシンプルさ、明瞭さです。

誤解を恐れずに言えば、Cucumber はシナリオ・ファイル（Cucumber では拡張子"feature"のファイル）に記載された文言と正規表現で紐付けされたメソッドを突合、合致したメソッドをそのシナリオの記載順に従って実行するだけのツールです。確かにこれだけなのですが、これを上手に利用すればテストコードの再利用が可能となり、多くの TDD 導入プロジェクトで見られるテストコードのメンテナンスの悪さやコピーコードの嵐から解放されることが期待できます。（PicklesJar ではこれをさらに一歩進め、一般的なデザインパターンについてはテストコードが事前に作成されていて、テストコードの再利用をより積極的に行うことを目指します。）

そして英語を主要言語としないプロジェクトにおいて Cucumber 導入による最も大きな恩恵は幅広い言語への対応です。先の説明にもある通り、Cucumber は詰まるところ正規表現に合致するメソッドを実行するだけなので、正規表現に合致させることができればシナリオ・ファイルに記載する言語は何でも構わない、当然日本語でシナリオが書けるわけです。

BDD で開発する場合、実は英語を読み書きできる場合は特別なツールは必ずしも必要ではありません。もちろん、ソースファイルより Cucumber で採用されているようなシナリオの方が可読性は向上しますが、とはいえ英語で記載されたコードの様式さえ工夫すれば BDD の思想を体現できない訳ではない。ところが英語以外を主要言語としている場合は同じようにはいかないので、Cucumber のようなツールを利用することにより劇的に BDD 導入効果が現れるのです。

ちなみに、Java について言えばメソッドやクラスの命名に日本語が利用できます。しかし、実際問題それは多くの場合利用されていない機能だと思います。その理由はいくつかあると思いますが、多くの静的解析ツールが日本語などの英語以外を想定しないで作ってあったりすることは理由としてあげられると思います。また、異言語が混在するソースコードは可読性低下を招くという意見もあるでしょう。コメントなど読解する際に完全な意味的な違いがあれば問題はないものの、ソースコードに複数言語の混在があると読みにくくなるということはあり得ると思います。もちろんこれは個人の主観によって意見が別れると思いますが、BDD ツールによってこういった問題が一気に解決できることは理解できるのではないでしょうか。

このように Cucumber は我々に多くの恩恵をもたらしてくれるツールですが、事実、大多数の人が知っているツールという訳ではありません。それは Cucumber にもいくつかの問題があるからです。

まず jUnit などをそのまま利用するだけでテストコードを作る場合に比べて作成するファイルが増えます。つまり、僅かではあるものの手間が増えのです。小規模のプロジェクトでは、そもそもその手間をかけてまで導入する必要性がないのです。

また前記の問題にも関わりますが、Cucumber を導入したからといって短期ではテストコードの開発コストは殆ど変わりません。テストコードの再利用性は間違いなく向上しますが、その効果が現れるのは中長期にこれを継続し、またこれに耐えられる設計もする必要があります。そのため BDD を志向していたとしても小規模プロジェクトなどではこの継続性を得ることが難しく、結果、導入を見送ることにつながるのです。（あくまでテストの話なので、一定の品質が確保できればコストが少ないに超したことはないのです。）

さらには BDD ツールであるため誰もが容易にテストの内容を理解でき、メンテナンス性が大幅に向上しますが、一方でその必要性が強く求められる大規模開発の現場にはそもそも BDD という考え方が浸透していない（というか、テストの自動化すら導入されていない）のでなかなか広まらないという背景的問題もあります。

しかしここまでの説明で Cucumber 導入のメリットを理解して頂いた皆さんは、どうにかこの問題を解決できないだろうかと考えるのでないでしょうか。背景的問題は時間をかけて解決していくしかないものの、コストを低下させるだけならなんとか、と。

PicklesJar は、まさにこの問題に取り組むプロジェクトです。単に問題を解決するだけではなく、より積極的にテストコードの再利用を可能とする設計を導入することよって、最終的には多くの開発現場でテスト工数を限りなく０に近づけるようにすることを目標としています。