scalazのテストでscalacheckやめたい

ニャーニャーとなくぞんび @AoiroAoino

@xuwei_k 好みに合わせsyntax選べるライブラリありますけど、最初にどれを採用するかで盛り上がっちゃう(?)し、決めないと表記揺れで統一感なくなるしで面倒くさいってのはありますねw そう意味で、潔くDSLは入れませんって方針はいいと思います👍👍👍

ニャーニャーとなくぞんび @AoiroAoino

@xuwei_k というか、実はみんなライブラリが提供してるから使ってみてるだけで、そもそもDSL的なカッコイイ(?)書き方が提供されてなきゃ嫌だ！みたいな人って実はとても少数派なのでは？って気がしなくもないです（個人の感想

Kenji Yoshida @xuwei_k

@AoiroAoino あと自分でも忘れてたけど、(あまりないけど)ミスで "foo" in "foo" in と同じテスト名2回書いて衝突したらたぶん実行時エラーだけど、valで定義すればコンパイルエラーにできるとか、sbtのコンソールから直接触れて再利用しやすいなどの利点

病気の美少女 @lyrical_logical

@AoiroAoino @xuwei_k DSL なんて無くて良いなら無い方がいいに決まってるので、言語の文法が十分に表現力がありテストを分かりやすく書ければ問題ないんですが、(特に TDD な)テストが自然に書ける程の表現力あると、普通に書く時困るというもどかしさがありますね

ニャーニャーとなくぞんび @AoiroAoino

@xuwei_k あ〜、確かに。まぁ変数名なので使える名前や記号は限られちゃうと思いますがテスト名を顔文字にするわけでもないし、いいじゃないですか！DSL入れなかったメリット推していきましょう！！（ぉ

Kenji Yoshida @xuwei_k

@AoiroAoino ところがscalaでは 「 ` で囲う 」 という技があることにより、こんな風に変数名だとしても何でも書けるわけです！ (という多少気持ち悪いことをscalazのテストでもガッツリやるつもりでいる・・・) github.com/scalaprops/sca…

病気の美少女 @lyrical_logical

@xuwei_k @AoiroAoino テストで `` 使うの基本じゃないですか割りと。sbt なんかでも artifactID のような - とか普通に入ってくるのに合わせて変数作ってると自然に使わざるを得ないというか

ニャーニャーとなくぞんび @AoiroAoino

@lyrical_logical @xuwei_k あ、あれ？みんな割と使うんですかね？まぁ、使っちゃいけない機能じゃないですし、言われてみれば自然な気がしないでもないですけれど...?（さりげなくscalazの``は見なかった事にしてた人間の感想←

Kenji Yoshida @xuwei_k

@AoiroAoino @lyrical_logical 結果、書き換えといっても、そのうちの6割(?)くらいは、こういうだいぶ単純作業になってます github.com/xuwei-k/scalaz…

病気の美少女 @lyrical_logical

@AoiroAoino @xuwei_k おじさんは type class のインスタンスとかも `hoge is a huga` みたいに書いてますね…implicit value は直接書く機会あんまり無いので、シンボル名を可能な限り可読性に振ってます

病気の美少女 @lyrical_logical

@xuwei_k @AoiroAoino これ手作業じゃないですよねまさか。なんか差分だけじゃなくて使ってる置換スクリプトも出した方が分かってもらえそう

Kenji Yoshida @xuwei_k

@lyrical_logical @AoiroAoino 単純なパターンは置換する程度でいけるけど、今言ったように本当に単純にできるのは6割程度(そもそも全部終わってないので雑な感覚)で、他は色々あるので微妙に難しいんですよね (単に自分に文字列操作スキルが足りてない自覚はある)

病気の美少女 @lyrical_logical

@xuwei_k @AoiroAoino ふーむ、でも全部を一つのコミットにする必要もないし、自動化した分はコミットコメントにスクリプトさらっと書いといて、人間様がやらないとしんどそうなのは別コミット、でもいいのでは。

Kenji Yoshida @xuwei_k

@lyrical_logical @AoiroAoino なるほど、たしかに・・・。コミットを最終的にどうまとめるべきか？は考え中です

Kenji Yoshida @xuwei_k

@lyrical_logical 今回の書き換えで履歴追いづらくなるデメリットはあるけど自分が一回苦労すれば済む話なので、書き換え自体のコストよりは他のコミッターが今後これに慣れる、不便感じないあたりのほうが個人的には重要だと思っている(けどまだ何も説明してないのでそれ以前の段階

ニャーニャーとなくぞんび @AoiroAoino

@xuwei_k @lyrical_logical 単純な置換で出来なさそうなの、例えば github.com/xuwei-k/scalaz… 関連とかですかねぇ...?（なんとなく

Kenji Yoshida @xuwei_k

見た目のDSLのカッコよさ(?)より、内部のデータ構造の適切さやそれをimmutableに素直に実装することを最重視して、shouldやinみたいなモノで階層構造作った際に既存の内部データ構造にうまく変換可能か？などを考えるの面倒になって、一切そういうのやめよう、となったなたぶん