#TestingFrameworkMeeting を開催しました
発表資料やtogetterは以下にあります。
https://github.com/tddbc/TestingFrameworkMeeting/blob/master/links.md
久々にこの濃度のイベントに参加した気がしますね…。 今やってることに直接参考になる話とかも聞けたりしたので個人的には大満足でした。
というわけで熱にあてられたので記憶している範囲で振り返ってみます。
t-wadaさんの発表
「simplify, amplifyで何かお願いします」とゆるめにお願いしてしまって、あとあとこれで良かったのかと悩んでもいたけど、まーさすがt-wadaさんというか、最初の発表としていい感じに話を広げてくださった。
議論などの流れでアドリブ入ったり脱線したりしたのはなかなか楽しい展開だった。
Evolve slowly
私はてきとーに作ってはGitHubにポイ捨てするタチなのでそんなこと考えてなかったけど、確かにテスティングフレームワークは緩やかな発展のほうが良いというのには納得。 ただ、それで発展が阻害されてしまっては意味ないと思うので、適度な競合ライブラリはあっても良いのではないかとは思っている。
Runnerの挙動が全体的にバッチっぽい
- テストケースを収集して
- テスト実行して
- レポートを出力する
RUnnerとしてはこの流れが主流だけど、もっとincremental(?)にやれるのではという話を(たしかJUnit5の話の流れで)きいて、確かにこの部分はどの言語でもわりと胸中しているなと感じた。 そしてなかなか手を出しづらい場所でもあるよね…。
余談
シンプルな方向に作る人たちってどういう時にCoreに機能を追加するのだろう、と前々から思っていたけど、話きいたり質問して"Coreという存在はなく、小さな各ライブラリに依存性がある"という見方をするのが良い落とし所なのかなと個人的に結論付けた。
あとpower-assertが非英語圏で流行ってるというのに妙に納得した。
Goとテスト
tenntennさんの講演。 Goのテストに加えてGo文化の話も聞けて良かった。
標準パッケージとして色々揃っている
これは後方互換を重視する言語であれば強みだろう。 なにしろよほどのことがない限り公式がメンテするのだから。
ifとassertion
- Goのtestingライブラリにはassertionがない
- if文を書いてテストに失敗した時はErrorfなどを返す
というのに対して
- assertionがぱっと見どこにあるのかわかりづらい
という返しがあったのは、私にはなかった着眼点だった。 個人的にはifもassertionもそんなに変わりない気がしているが、違和感ある人はあるのだろう。
あえて機能を少なくすることで何が起こるか実験しいるのでは
みたいな意見があった。 推測の域を出ないけど興味深い考察だとは思うので、今後を見守りたいものである。
Lint
Kuniwakさんの講演。 私は個人プロジェクトではあまり使っていないが、仕事ではお世話になっているので最近の動向なども含めて色々きけて満足。
"変数名のtypoを単体テストで発見するのは遅すぎる"
静的型付け脳な私としては「それバックグラウンドでインクリメンタルコンパイルしておけば」と思わなくもないが、動的型付けだと確かにこの問題はあるのかもしれない。
省力化ツール
この話をきいて、かつてmzpさんが「機械的に調べられるものは機械が勝手に修正をコミットしてくれるまで行けばいいよね」的なことを仰っていたことを思い出した。
読み手のみの省力化だけでなく書き手の省力化も、というのが今後業界的な流れになってもおかしくないのではないだろうか。
Lintとテストレフームワークを共通化
Runnerを共通化するという発想は私にはなかった考えなので新鮮だった。 どのくらい新鮮だったかというと、翌日から F# と Scala の自作テスティングフレームワークにその機能を組み込めるか試して見る程度には。
ぱっと考えてみた限り原理的にはいけそうなだが、どこまでビルドチェーンを複雑にせずに組み込むかはちょっと考える必要がありそうだとは思ってる。
ASTにに含まれない情報はどうする？
- 具象構文木をlintの対象にする
- トークン列も組み合わせる
というパターンが存在するみたい(前者はやや実験的傾向がまだ強うそうに思うのだがどうなのだろう)。
余談
「PythonでVimScriptのLint作ってます」「GoでLuaのLint作ってます」の会話が個人的にツボだった。
QuickCheck(という名のテスト合成 + Property Based Testing)
私の発表。 これまた脱線しまくるという状況になった。
power assertに反逆したい
流行にはあえて反逆したくなることがあるので、そういうことを考えていますよという話をちょろっとしていた。 時間があったらもっと話したかったけど本題ではなかったので泣く泣くスキップ。。。
テストの合成
ここで色々と脱線してた。
- テストの合成とはなんぞや
- 初出ではなく、おそらく昔からある考えだとは思うけど出典見つけられず…
- テストが疎結合にならないのではないか?
- 疎結合とテスト実行速度のバランス次第だと思っている
- 話し損ねたこと
- unitを引数に受け取りテストケースを戻り値とする関数 -> 副作用を内包する
- 変数に束縛されたテストケース -> 副作用を持たない or 一度しか実行しない
- このあたりは言語によるかもしれない…?要検証
エッジケースの話
- だいたい人間でもわかりそうな部分のエッジケースしか発見できなさそう
これは一理あるけど、でも経験的に予想外のテスト失敗に遭遇したことがある身としては
性質自体を間違ってしまうリスクをどうやって減らす?
これは難しい問題だと思っている。 個人的には、
- よくある事例から性質を引っ張ってくる
- ミューテーションテスト
- 最初はユニットテストで担保し、ある程度でいけそうだと判断したら入れ替える
- エラー周りから攻める
- エラー系は入力集合を作りやすいことが多いし性質も"エラーになる"で終わらせられるから
あたりだと思っているが、根本的打開策になっていないのが厳しいところではある。
これはこれでスキルいるね
性質を導き出せるかは個人のスキルによるので、慣れていないとチーム全員で使うのは厳しいのではないかという指摘(というか参加者の感想)。
これは指摘通り。 まぁ、最初はリファクタリングの際に導入するとかで慣れていくしかないのではないでしょーか。
Serverspec
mizzyさんの講演。 OSSに対する姿勢などもきけて良い学びがあった。
AssurerとServerspecの思想の違い
実装動機が異なるとここまで異なるプロダクトになるのだなーと。
なぜRSpec?
- 強いこだわりがあるわけではない
- 非本質的なことには振り回されたくない
非本質的なことに振り回されたくないはかなり同意。 とはいえ、絶対に振り回されないは厳しいと思うのでどこまで最小限にできるかどうかなのかもな、と。
応用的な観点
テストをインフラの方面にもってきた、かつ敷居を低くしたというのを実感できる発表だった。
雑感
飛び入り発表
飛び入りでESDocやoktestの話も聞けて、大変参考になった。 この辺りは思うところがあったのでちょっとライブラリに手を加えたりしてみている。
懇親会での話
特に記憶に残っている話を箇条書きで。
- 枯れた(安定した)ライブラリが最終更新で判断されるのはなんか違う気がする
- GitHubのstarや最新コミットが目につきやすいので無意識・意識的に誘導されてしまう？
- どの程度使われているかに注目できれば良いのかも？人気言語まとめとかもどこかの団体が勝手にやってるわけだし
- 信頼問題
- Python2からPython3に移行できない理由とか
- 人は自分が使っている言語を擁護するように動く傾向がある
- DBセットアップのテスト
- Serverspec的なものをDBにも応用できないだろうか
- DB界隈とソフトウェア界隈の空気の違い?的な話
- 懇親会費が余ったのでJUnitに寄付することにした
- いつv1.0.0をリリースするか
- あれもこれもとズルズルいってしまう
- 対象環境が多いとどこまで対応してからリリースすべきか悩ましい
- 最低限という区切りを設ける/締切駆動開発などで時限式にするとか
furiosaやawsspecの話もきけて満足。
次回やるとしたら
やるかわからないけどこの辺り題材にゆるっと平日夜にやれないかな(議論したい、聞きたいというそこの貴方、発表者探しを手伝っていただけませんか? or 発表者になりませんか?)
謝辞
企画に関わってくださった皆様、発表者の方々、他のイベントと被りまくっていたのに本イベントに足を運んでくださった皆様に感謝します。 皆様のおかげで、とても意義のあるイベントになりました。
そしてmixiさんとKuniwakさん、朝早くから夜遅くまで会場準備撤収ありがとうございました。 とても気持ちよくイベントを行えました。
*1:というか心の葛藤?
