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 さんです。