Gherkin に tlhIngan Hol を加えてみた

この記事はTDD Advent Calendar 2013の18日目の記事です。前日はkidachi_さんの「今度こそ快適・王道なTDD生活が始められる良記事10選+α [Rails/RSpec]」でした。

現状

~~pull request中...~~
merged at 2014FEB24

動機

Cucumber や SpecFlow で feature を書いてテスト駆動で開発して動かすと楽しいですね。主に結合以降のレベルで使っています。
テスト仕様書そのままが動かせるし、これが受け入れ側でも分かる言語で書かれているのがいいし、自分でもパッと見なにをやっているか分かります。

しかし足りないものがあります。グローバルとかしましい昨今、クリンゴン語が使えません。
これだと銀河系内の大きな市場をとりのがしていることにはならないか? そう考えて非力ながら組み込んでみました。

やったこと

Gherkin の語彙を訳した

Gherkin の語彙を訳しました。
単純作業ですね。

English	日本語	tlhIngan Hol
feature	機能	Qap/Qu'meH 'ut/perbogh/poQbogh malja'/laH
background	背景	mo'
scenario	シナリオ	lut
scenario_outline	シナリオアウトライン	lut chovnatlh
examples	例	ghantoH/lutmey
given	前提	ghu' noblu'/DaH ghu' bejlu'
when	もし	qaSDI'
then	ならば	vaj
and	かつ	'ej/latlh
but	しかし	'ach/'a

テストも追加

やたら「'」が出てくるのでちゃんとparseされるか不安だからテストも書きました。

ソース

ここにあるので試しに使いたい方はどうぞ。
https://github.com/naghbIQtIqHom/gherkin/tree/Klingon

例

http://cukes.info の feature サンプルはこんな感じになります。

Feature: Addition
  In order to avoid silly mistakes
  As a math idiot
  I want to be told the sum of two numbers

  Scenario: Add two numbers
    Given I have entered 50 into the calculator
    And I have enterd 70 into the calculator
    When I press add
    Then the result should be 120 on the screen

perbogh: latlh
  Qagh Dogh junmeH
  mI' QeD bopDI' jIDogh
  cha' mI'mey vIchel 'ej vIjang vIneH
  
  lut: cha' mI'mey chel
    DaH ghu' bejlu' De'wI'vaD 50 vI'elmoH
    'ej De'wI'vaD 70 vI'elmoH
    qaSDI' chel vI'uy
    vaj 120 HotlhnIS De'wI'

効用

これで気難しい異星人相手の案件でも意思疎通がはかりやすくなり、雇客が得たい製品を作ることがより容易になります。

反省点

advent calendarの日までに取り込まれるまで行けなかった。というか受け入れてくれる気がしない。
なんか他のエントリーから浮いている。

明日は

明日は PoohSunny さんです。

GherkinvaD tlhIngan Hol vIchelchoH

TDD Advent 'ISjaH 2013 wa'maH chorghDIch jaj 'oH lutvam'e'. wa'Hu' kidachi_ «今度こそ快適・王道なTDD生活が始められる良記事10選+α [Rails/RSpec]» «[Rails/RSpec] wa'maH latlh je lutmey QaQ DalaDchugh, DaH 'eb TDD vangDI' ngeDtaHvIS yIntaHlaH» ghItlhlu'pu'.

DaH ghu'

~~pull request vIngeH~~
tera' DIS cha' SaDnIS wa'maH loS jar cha' jaj cha'maH loS mutlhlu'ta'!

mo'

Cucumber SpecFlow ghap lo'DI', feature ghItlh, vaj De'wI' qaD. tIv. vImuchDI, vIlo'.
qaDmeH lut qetlaH. nom mebvaD jIHvaD je yajlaH.

'ach wej yon. tlhIngan Hol Hutlh. SuyvaD qIb qelqu'. mo'vam vIqelmo', vIghunchoH.

vangpu'

Gherkin mu'mey mugh

Gherkin mu'mey vImugh. nap.

English	tlhIngan Hol
feature	Qap/Qu'meH 'ut/perbogh/poQbogh malja'/laH
background	mo'
scenario	lut
scenario_outline	lut chovnatlh
examples	ghantoH/lutmey
given	ghu' noblu'/DaH ghu' bejlu'
when	qaSDI'
then	vaj
and	'ej/latlh
but	'ach/'a

qaDbogh vay' vIghun

«'» poj 'e' vIqaDmeH vIghun.

Hal De'

Dalo' DaneHchugh, yIlo'.
https://github.com/naghbIQtIqHom/gherkin/tree/Klingon

ghantoH

http://cukes.info feature ghantoH mughlu':

Feature: Addition
  In order to avoid silly mistakes
  As a math idiot
  I want to be told the sum of two numbers

  Scenario: Add two numbers
    Given I have entered 50 into the calculator
    And I have enterd 70 into the calculator
    When I press add
    Then the result should be 120 on the screen

perbogh: latlh
  Qagh Dogh junmeH
  mI' QeD bopDI' jIDogh
  cha' mI'mey vIchel 'ej vIjang vIneH
  
  lut: cha' mI'mey chel
    DaH ghu' bejlu' De'wI'vaD 50 vI'elmoH
    'ej De'wI'vaD 70 vI'elmoH
    qaSDI' chel vI'uy
    vaj 120 HotlhnIS De'wI'

vaQ

nov DaSutlhDI', nov qech DayajlaH. vay' neHbogh meb DaghunchoHlaH.

jIqel'egh

qaSDI' Advent 'ISlaH jajwIj, pull request wej laj.
chaq lajbe' 'e' vIQub. jIpay.

wa'leS

wa'leS ghItlh PoohSunny
Qapla'!

TDD Advent Calendar 内でエントリーが浮いているのでビビッたので最近TDD布教中に思ったことなど

コード作成者レベルで3つ程度

ユニットテストのテクニックが広まっていない

IDEなどで統合されてユニットテストを作って簡単にテストもできるようになったのでカバレッジ目指せ100%と意気ごむが、ユニットテストでの依存関係の断ちかたのテクニックを知らない。
意識が高い部署でもテストダブルとか知らない。GoFのデザインパターンのように読まれる本が日本語で出て、やりかたへのアクセスが容易にならないかと思う。
xUnit Test Patterns の邦訳ってないんでしょうか。けどぶ厚いしなあれ。
モックなどを解説した日本語で読める書籍何冊か出ているけど C#版のそれが出てくれると助かります。 C#で行うユニットテスト的な名前で。テスト駆動は記載されてなくて十分です。Visual Studio と MSTest 中心に書いてあると助かります。私の今いる現場的には。

テストがお荷物になっている。

テストをガイドや目標にして、それをパスするように作っていくと目的の製品ができる。という考えかたにならない。
テストはコードが全て書き終ってから書くもの。スケジュールもそうなっているし。
そして開発中は仕様の変更などで書いたテストが無駄になる、テストコードはレビューやメトリクス調査の対象でない、メンテナンス対象でもないので次の開発時に動かなくなっていたりする。
などの理由でテストコードははプロダクトコードができてから書きたい。
テストはしないといけないとは思っている。

TDDを広めようと簡単な例題を実習形式で行なっても実務では適用されにくい。

自分でやってプロダクトコード作成のときにギャップを埋めるのは苦しかったので適用されない心理は分かる。
とりあえずテストコードよりプロダクトコード書いてしまいたい。
これは場数を踏むと慣れていくのだろうか。効果的な導入教育での学習ステップを考えたい。
何が難しいのか内省ができてないけど。

導入の流れ

こうすればコード作成者はテスト駆動で開発するのが障壁低いかなあと考えています。

独立性の高いユニットテストを作れるようになる
↓
テストの考えかたと扱いに対するパラダイムシフト
↓
テスト駆動

明日は

明日は PoohSunny さんです。