前回までのあらすじ

追加コードなしにこだわる理由

RaaPでは基本的な姿勢として、テストコードを書かなくても動くことを目指しています。(もちろんRBSは書く) その理由を言語化してみます。

そもそもここで言うコードとは

プロパティベーステストはプロパティというルールをコードで記述して、このルールがどんな入力でも成立するかを検証するテスト手法です。 QuickCheckやproper・propcheckを読んだなら、当然以下のようなコードを思いつくでしょう。

it "2回reverseしたら元に戻るはず" do
  forall(list(integer())) do |ary|
    expect(ary.reverse.reverse).to eq(ary)
  end
end

RaaPではこういうことをできなくはない(内部のテストでは使用している)のですが、あえてファーストサポートとしないように意識しており、あくまでCLIツールとしての利用をファーストサポートとして考えています。

利用しやすさ

利用に関して、障壁は少なければ少ないほど良いです。コード書かなくていいなら最も利用しやすく、lsコマンドやtopコマンドのようにカジュアルに使うことができます。

利用される数が多ければ多いほど、良いフィードバックも増えてプロダクトの成長にもつながります。

互換性の問題からの解放

rspecではv2からv3で大きな非互換性があったことが記憶に新しいと思いますが、、、10年以上前(2013年)のことでした……。まじか。

ともかく、コードあるところに互換性の問題は常にあります。一度決めたAPIはなかなか変えれません。

しかしながらコードがなければ互換性に気を揉まなくても良くなります。よりより設計を思いついたらすぐに取り入れることができます。これはプロダクトの成長スピードに関わってくると思います。

CLIの挙動の非互換はもちろんありえますが、コードの非互換よりは小さな問題でしょう。

縛り

縛りを設けることで呪力の総量を上げるのはプログラマーの基本中の基本です。

目的を絞りコンセプトを一貫させることによって、より深いプロダクトになるはずです。

ほんとに何とかなるの？

当然全てのパターンでは成立しません。例えばArray.newはマイナスの値を入れるとエラーになるし、RBSとしてパースできる文字列しか::RBS::Parser.parse_typeは受け付けません。このような場合ではカスタムコードを書かざるをえないでしょう。なんならRaaP本体ではRubyの基本的なclassに対して結構カスタムコードを書いてしまっています。

しかしながら、書いてしまうとこれまで否定してきた問題に直面することになります。

この辺の問題とどうバランスを取っていくのかが、今後の見どころです。

スペクトラム

RBSがテストになるとおもしろいんじゃないか日記6