TDDはもちろんペアプロがすごくよい経験になった、というのが最大の感想です
ドライバーとナビゲーターの入れ替えをあんなに頻繁にやるものなんだ…ということだけでも個人的にはすごくプラスになりました。
主催者やTAの方々、そして当日自分の環境に合わせてペアを組んでくれた @akuraru さん ありがとうございました。
そしてVOYAGE GROUPさん、
お題とか詳細は皆さんが各所でまとめてますし、togetterにもまとまってますのでそちらで。
#tddbc ScalaでTODOリストとか、実装が10行とかってのは半分嘘です。前者はSpecs2をacceptance の形で書けばそれっぽく使えて、後者は「仕様は全部は満たしてないけど現状の実装はまだ10行程度で一応動くよw」のレベルでした。そのうちブログとかにまとめます〜
— 駄猫さん (@daneko0123) 2013年3月18日
と言ってしまったので書きます。
まず、こんな環境でした。
- scala2.10 + specs2 + sbtでtestぶん回し
多分気になっている人もいると思いますし、一応こうやりました的なことを書いていきます
TODOもコード?
Scalaのテストフレームワークは、Spec2、To Doもコードで書いてるよ! #tddbc
— ずきゅ~んたんさん (@ZuQ9Nn) 2013年3月16日
えーっと、半分本当で半分ウソです。
specs2ではこのような書き方が可能になります。
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
import org.specs2._ | |
class LtsvSpec extends Specification { | |
def is = | |
"TDDBC 2013-03-16 Tokyo".title ^ | |
""" | |
LTSVを読み込むクラスを作る | |
今回 @akuraru さんとペアになって短時間で考えた結果 | |
基本的にMapでKey/Valueを保持し | |
Keyの順番に関してはListで管理することにした | |
"""^ p^ | |
"LTSV一行を管理するクラス" ^ | |
p^ | |
"key value をsetする場合" ^ set^ | |
"keyを指定して値を取得する場合" ^ get^ | |
"dumpメソッドで出力する場合" ^ dump^ | |
end | |
def set = | |
"key/valueを与えるとMapとListが更新される" ! pending ^ | |
"既に保有するキーの場合は、Mapのvalueが更新され、" + | |
"Listで管理するkeyの順序は更新するキーが最後尾に来る" ! pending ^ | |
"正常系ならEither::Right(None)が返る" ! pending ^ | |
"正常系且つ更新ならEither::Right(Some(古いvalue))が返る" ! pending ^ | |
"keyがnullの場合はLeft" ! pending ^ | |
"keyが空文字はLeft" ! pending ^ | |
"valueがnullはLeft" ! pending ^ | |
"valueは空文字はOK(Right)" ! pending ^ | |
endp | |
def get = | |
"keyが存在すればSome(value)が返る" ! pending ^ | |
"keyが存在しなければNoneが返る" ! pending ^ | |
endp | |
def dump = | |
"dumpは tab区切り末尾改行のLTSVで出力する" ! pending ^ | |
endp | |
} |
pendingを空のチェックボックス代わりに使っているだけです。
pendingを実際にテストを行うメソッドに書き換えればチェックした!みたいな。
詐欺ですねw
この書き方(specs2のサイトではacceptance specifications とあるので、受け入れテストを前提としている書き方?)だと(甘めに言えば)そのままTODOリスト書いているのと変わらない形で書けますので、
TODOリストもScalaで書いた( ー`дー´)キリッ
と言っても許され…ますよね?
というのを誇張しました、スミマセンでした。
他にもgradle同様HTML出力とかもしてくれますし、spock同様DataTablesもありますし、specs便利です。
ちなみにhtml出力画面はこんな感じ。

話それますが機会があればgradle+spockはとても触りたいですね。
あとScalaTestで同じようなことが出来るかどうかは、使ったこと無いので知りません、ごめんなさい。
@zuq9nn 書けますよ。必ず何らかの値を持つ様にコードが書けるし、書いて行くので、nullチェックや例外分は短くなります。
— あくらる@こわくないさん (@akuraru) 2013年3月16日
なるほど…(ぉぃ
まあnullとか例外とか嫌ですよね。
で、先ほど当日未実装だった部分をテキトーにやったところ、ソースの行数が30行ぐらいになっちゃった。
改行だけの部分のカウントを除いて、dumpメソッドを再度ワンライナーに戻して、あと何かすれば10行程度になるかも?
何れにしても自分のScala力と今回のお題(Exception返せ!とか)だと10行は難しいかも…
ましてやvar使っちゃったし、もう負けてる感満載w
sbtでぶん回す
sbt を回しながら IntelliJ で Scala のコードを書いてるペアがいる #tddbc
— Takuto Wadaさん (@t_wada) 2013年3月16日
最近sbtは酢豚と読むらしいです(scala conference jpでそう聞いたw)
sbtではtestと叩くとtestが全実行されますが、「~test」で実行するとファイルが変更される度にtestを回してくれるので大変便利です。
コード書いてセーブすれば勝手に実行される素敵環境がすぐ出来ます。
PCのパワーと電源がある限りひたすらぶん回しておけばいいのです(ぇ
ただ正直なところ…テストケース一つを実行するならJava+JUnit+QuickJUnitのほうが体感速度は速くて気持ちいいと思いますw
Scalaもテストの実行そのものは早いんですけど、コンパイル待ちが…うーん…
結論:もっとマシンパワーがあればなんとかなる
あんまりここで書いちゃうと水曜日の「Scalaを勉強する会」でしゃべることがネタOnlyになっちゃうのでこのへんで許してください。
一応githubにソース置いてますので、興味がありましたら御覧ください。
あ、もちろん「フツーこう書くだろJK」的なご指導ご鞭撻もよろしくお願いします。
https://github.com/daneko/tddbc
そうそう、ペアプロにおいて環境の違いはどうやって埋めるべきなんでしょうね?
自分の環境(Intellijにvimプラグイン)とかだと、相手がemacs派だったりした場合とか…
あー、仕事でScala書きてー…