Great original post: Future proofing test suites.

2017年 11月 12日 Michael Snoyman

まず、最近何回か見た具体的なケースから話を始めましょう。そしてそれを元に一般的な話をします。もしもあなたがパッケージの作者で、この問題に直面してきたのなら、ちょっと聞いてくださいよ。私がこの情報をブログの記事にしているのは、いくつものバグトラッカーで同じ説明を何回もするよりも、ここに一回だけ書いて、そのリンクを貼ればいいと考えたからです。

hlint は Haskell のコードをより良くするためのアドバイスをくれる、素晴らしいツールです (Neil Mitchell のもう一つの素晴らしいプロダクト)。その別のプロダクトのように、hlint もまた新しいバージョンで、より良いアドバイスをくれるような進化を遂げています。まぁこれは、昔の hlint では出なかった警告が、新しいバージョンで突然出るようになるかもしれない、という意味でもあります。

最近、Stackage のキュレーション中に 2回、コードを全く変えていないのに、何個もテストが失敗するのを見ています。この、以前通っていたテストが失敗するようになる現象は、hlint のバージョンを新しくしたのが原因でした。これは明らかに、hlint のバージョンを新しくしたからコードがいきなりぶっ壊れたのではありません。テストの失敗の診断が関係しているので、hlint の警告のせいでしょうね (意訳)。

推奨するやり方

hlint を使ってプロジェクトのコードを改善するのは、すごくおすすめです。Stack などの CI のプロセスでこいつを使って、素晴らしい結果を返してくれるのを何回か見ています。(ちなみにこれは私のアイディアではなくて、実際に使ったりもしていませんでした。ただスタイルエラーがある PR を投げてしまって、それが失敗するのに気づいて、嬉しい驚きだった、というだけです)。でも、hlint のバージョンを新しくしたせいで、パッケージ全体としてのテストが失敗する現象。これは起こりすぎです。なので、

  • 警告が出る PR をブロックしたいのなら、CI から hlint を呼び出すようにしてください。私が思いつく方法は 2つあります:
    • Stack のやり方をまねる。Stack にはスタイルエラー専用の、Travis CI のビルドマトリックスがあります。プロジェクトの cabal ファイルは、hlint について何も知りません。
    • cabalファイルのテストを使うが、デフォルトで無効にしておく。CI の設定から、フラグを使ってそのテストを有効にします。 
  • Hackage にアップロードされ、Stackage でビルドされた際に、スタイルに関連するエラーによってテストが失敗するようなパッケージのセットアップはやめましょう。

一般的に推奨するやり方

ここから考察される一般論は、CI でコードをビルドするときは、やりたいだけ厳密にやる、ということです。標準を高く保ち、PR をブロックし、master がぶっ壊れた! と叫んでください。ささいな問題でもそうでなくても、重要だと思う問題全てに対してです。-Wall -Werror をオンにし、タブや文末のスペースに対してエラーを吐くようにしてください。これらは全て良いものです (タブかスペースかなどの、必要な議論はしてください)。

しかし、他の場所でコードをリリースするときは、メインではない機能に対しては、テストを緩くしましょう。コードがビルドに失敗するのなら、それは問題です。ビルドに成功しても、実行時に正しくない結果を返すようなら、それは問題です。これらの問題が存在すると、Stackage などのビルドシステムは、そのようなパッケージを受け入れてくれません。でも、スタイルの問題や新しく追加されたコンパイラの警告のようなものなら、あなたのパッケージを使うより下流の利用者に対して、失敗させるべきではないでしょうね。