テストの作成

何をテストするか

理想的な世界では、Sailsユーザーとしてプログラムで実行できるあらゆる操作、またはコマンドラインツールを介して実行できるあらゆる操作には、テストが存在するでしょう。しかし、Sailsには多数の設定バリエーションがあり、また、ユーザーランドコードがほぼすべてのコア部分をオーバーライドできるという事実から、この状態に完全に到達することはありません。そして、それはそれで構いません。

そうではなく、Sailsプロジェクトの目標は、プログラムによるかコマンドラインツールによるかにかかわらず、使用する可能性のあるSailsの機能にテストが存在することです。これらの機能が依存関係内で実装されている場合、その機能のテストはその依存関係内にのみ存在します（例：Waterline、Skipper、およびCaptains Log）。ただし、これらの場合でも、Sailsでのテストは必然的に、Sailsの依存関係によってすでに検証されている特定の機能を再テストすることになりますが、それは何も問題ありません。

何をテストしないか

排他的なものを検証するテストは避けるべきです。それは開発を迅速に行う能力を損ないます。言い換えれば、テストは追加機能の導入によって失敗するべきではありません。

たとえば、sails newで適切なファイルが作成されたことを確認するテストを作成する場合、それらのファイルがあることを確認するのは理にかなっていますが、それらのファイルのみが作成されたことを保証することは理にかなっていません（つまり、新しいファイルを追加してもテストが失敗するべきではありません）。

別の例として、ブループリント設定の正確性を検証するテスト、たとえばsails.config.blueprints.restがあります。テストでは、rest設定が有効および無効な状態でブループリントが適切に動作することを確認する必要があります。設定を変更したり、コントローラー固有のオプションを追加したりできますが、必要なのは新しいテストを作成することだけです。

一方、ブループリントの動作をテストする戦略が、動作を評価してから、構成が「どうあるべきか」を判断することである場合、新しいオプションを追加する際にテストを修正する必要が出てきます。これは大したことではないように聞こえるかもしれませんが、すぐに手に負えなくなる可能性があります。