単体テストでファイルの内容/エンコードをチェックすることは「悪い習慣」と見なされますか？

少しのコンテキスト：今日、私は別の同僚が提供したいくつかのSQLコードを更新する必要がありました。それは非常に大きなスクリプトであるため、別個のファイルとして保存されます（その後、実行時に読み取られて実行されます）。これを行っている間に、数か月前にあった2つのバグを誤って再導入しました。

• 何らかの理由でASCIIファイルがUTF-16でエンコードされていました（同僚がファイルを電子メールで送信したため、ファイルが作成された可能性があります）。
• スクリプトには初期SETステートメントがありませんでした（プロダクションでは一部のドライバーが必要ですが、ローカルでのクリーンインストールでは必要ありません）。

これを約1時間（再び）デバッグした後、これが二度と起こらないことを保証するためにいくつかの単体テストを書くことにしました（そして、将来の開発者に簡単な修正を提供するためにアサーションメッセージに修正する簡単な方法を含めます）。

しかし、このコードをプッシュしたとき、別の同僚（チームリーダーでもある）が近づいてきて、これらのことを二度とするべきではないと言った。

「これらのことは単体テストに属していません」

「ユニットテストは、コードのフローを確認するためにのみ使用してください」

このバグは将来再導入されないので、今やっていることは間違っていないと思うので、今はかなり対立していますが、この同僚は先輩として働いて、結局は何を決めるのですか？私たちは時間を費やしています。私は何をすべきか？このようにするのは間違っていますか？それは悪い習慣と考えられていますか？

ほとんどの場合、作成したテストは、単体テストよりも統合テストまたは回帰テストに近いものです。行は非常に曖昧である場合があり、場合によってはユニットテストであるかそうでないかを詳しく説明しますが、同僚に戻って、コードの正確性を保証する価値を追加するため、書いたテストの場所を尋ねます。

単体テストとは何かにあまり焦点を当てず、統合テストであってもテストに価値があることを認識しています。

技術的には、単体テストではなく、検証ステップの詳細です。適切なアプローチは、ワークフローが必要なものに本当に依存します。チームリーダーは、単体テストの目的について正しいです。私の考えでは、これはまだ実行する必要があるジョブに間違ったツールを使用している場合です。だからこれから始めましょう：

私が解決しようとしている問題は何ですか？

説明により、データベーススクリプトがいくつかの標準に準拠していることを検証する必要があります。

問題を解決するために利用できるツール/プロセスは何ですか？

ソースコードの品質は通常、静的分析ツールによってチェックされます。SQLを検証する静的分析ツールがない場合は、渡されたSQLファイルのチェックを実行する迅速でダーティなツールを作成できます。あなたが話している問題を処理できる静的解析ツールがあるかどうかをチェックすることは害になりません。

Jenkinsなどに組み込むなど、ビルドインフラストラクチャの一部を作成すると、プロジェクト内のすべてのSQLファイルに適用できます。

単体テストは、現在のファイルの問題のみを解決します。

ツールの必要性をどのように伝えますか？

これは非常に簡単です。チームリーダーに相談してください。彼は製品所有者およびあなたと協力して、ツーリングへの投資のリスク/報酬を決定できます。これが1回限りの問題である可能性が高い場合、ツールは多すぎるでしょう。最大の問題をキャッチするためのツールが簡単な場合、健全性チェックのためだけに価値があるかもしれません。

チームリーダーは、あなた（または私）が考慮していないアイデアをいくつか持っている可能性があり、それにより問題をより正確に解決できます。

ファイルにアクセスするテストを「単体テスト」と呼ぶのは悪い習慣です。

彼：「これらのことは単体テストに属していません」

あなた：「理にかなっていますが、私はそれらを置くよりよい場所を見つけることができませんでした。それらはどこに属しますか？」

残念ながら、どのような種類のテストが存在し、どのように構成されているかは、完全に企業固有です。そのため、会社がこれらのテストをどのように処理するかを知る必要があります。

ユニットテスト以外の自動テストを実行する方法がまだない場合、実用的なアプローチは、実際にユニットテストではないユニットテストに、どのような種類を把握できるようになるまでプレフィックスを付けることです。実際に持っている/必要なテスト。その後、整理を開始できます。

マイケルフェザーズは、彼の著書「レガシーコードを効果的に使用する」で次のように述べています。

業界では、特定のテストが単体テストであるかどうかについて頻繁に行き交います。[...] 2つの特性に戻ります。テストは高速に実行されますか？エラーをすばやく特定できますか？

テストはエラーの迅速なローカライズと高速実行に役立ちますか？はいの場合、それを行います！いいえの場合は、しないでください！それはそれと同じくらい簡単です！

そうは言っても、あなたは他の人々と一緒に環境で働いており、彼らと仲良くしなければなりません。あなたが個人的にそれに反対したとしても、あなたはそれを彼のやり方でやらなければならないかもしれません。

ソースコードファイル、構成ファイルなどに対して、ときどき同様のテストを作成しました。（a）ファイルシステムにアクセスしており、超高速ではない可能性があるため、ユニットテストとは呼びません（b）チェックインごとに実行されるかどうかは気にしません（夜間ではなくCIサーバー）。

それらを統合テストと呼ぶかもしれません。確かに、彼らはユニットテストよりもその観点に近い。

それらの私自身の用語はリソーステストです。私見、CIサーバーで毎晩実行される場合、これらは完全に正当化されます：最小限のコストがあり、賢明に使用された場合、明らかに付加価値があります。賢明な定義：テストが問題を引き起こした問題をチェックしている場合（あなたが言及したエンコーディングなど）。

単体テストは、メソッドまたはコードの「ユニット」のテストに関するものです。ソフトウェアのロジックとコードの最小グループをテストしています。

後で、それを他のユニットと結合すると、統合テストが実行されます。

あなたのチームリーダーがあなたのイニシアチブを奨励し、別の提案を提供するべきだったと思います。あなたは間違いなく正しい考えを持っています。

SQLは、C＃やJavaなどの低世代言語とまったく同じコードであるため、そのようにテストする必要があります。そして、検証と検証はすべてのテストレベルに属します。そのため、エンコードとSETステートメントが含まれますが、必ずしも排他的にテストされるわけではありません。行末や囲みなどの一般的なものは、通常、SCMフックまたは機能を使用するだけです。

ベストプラクティスは、過去のバグが再導入されないようにするための回帰テストを実施することです。一般的に、テストはバグの解決とともに作成されます。これらのバグがユニット/統合またはシステムレベルでのリグレッションテストでカバーされず、再導入された場合は、個々の問題ではなく、チームの問題であり、プロセスの問題です。

問題は...構文エラー、欠落したステートメント、または「ユニット」内の論理ブロックは通常テストされません。ユニットの入力と出力をさまざまな組み合わせでテストし、生成される可能性のある多くの可能性をテストしています。

欠落しているSETステートメントに戻る-テストする入力と出力の多くの可能性を知らせるのに役立ちます。選択したSETが欠落している場合、失敗するテストはどのようなものですか？

製品の一部となるファイルがある場合、その内容は正しいものでなければなりません。これを検証しない理由はありません。たとえば、あるフォルダに6つの1024x 1024の画像が必要な場合は、必ずそれを確認する単体テストを作成してください。

しかし、おそらくファイルだけではなく、ファイルを読み取るコードもあります。そのコードの単体テストを書くことができます。上記の例では、6つのイメージの1つを読み取る関数は、メモリ内の1024 x 1024イメージ（または生成されるはずのイメージ）を返します。

とにかく、単体テストではないかもしれませんが、有用なテストです。また、有用なテスト（単体テストではない）を実行できる単体テストフレームワークを使用している場合、単体テストフレームワークを使用してみませんか？

おそらく私はあなたの問題を誤解しているかもしれませんが、私にはこれは何らかの種類の専用のテストではなく、単にバージョン管理システムによって捕捉される必要がある問題のように聞こえます。コードベースへの変更は、コミットする前にパッチごとにレビューする必要があります。gitでこれを行う簡単な方法は、変更を追加することです

git add -p

これにより、テキストファイルの変更ごとに、作業ディレクトリが本当にそれを保持するかどうかを尋ねます。これにより、たとえば、これらの「初期SETステートメント」の削除を確認できます。

ただし、ファイル全体のエンコーディングが変更された場合、異なるものが発生します。アルゴリズムは、古いファイルと新しいファイルを比較できgit add -pないため、何も追加しません。これは、コミットする前に行う他のコマンド、つまり、

git status

ここでは、そこにあることを示し、赤でハイライトされたファイルを参照してくださいねある変化。これらがうまくいかなかった理由を調査git add -pすることで、問題がすぐに明らかになります。

考慮すべき別の角度：これらの2つの条件は、プログラムを実行するための要件であるため、実行ロジックの近くにロジックを埋め込むべきではありませんか？つまり、ファイルを読み取る前にファイルの存在をテストしたり、コンテンツを検証したりします。これはどう違うの？これはコード外部リソースであるため、実際に使用する前に、実行時に検証する必要があると思います。結果：より強力なアプリ、追加のテストを記述する必要はありません。

テストは他のテストと同じコードであり、十分に複雑な場合は、ユニットテストの恩恵も受けます。このような前提条件チェックをテストに直接追加するのが最も簡単なようです。

ほとんどのテストはこれを必要としないほど単純ですが、一部が十分に複雑な場合、これらの前提条件チェックに根本的な問題は見られません。もちろん、それらがなければテストも失敗するはずですが、適切な単体テストはどのユニットが失敗しているかを示します。

テストの一部として使用され、特定のコンテンツとエンコードが必要なスクリプトは、おそらくユニットです。他のテストよりもはるかに多くのコードとロジックが含まれている場合があります。このようなスクリプトを使用したテストは、これまでで最高の設計ではないため、可能であれば、より直接的なものにリファクタリングする必要があります（統合テストでない限り）。

まず、テストの目的の1つは、コード内での問題の再発を防ぐことです。したがって、この種のテストを作成し続ける必要があります。

第二に、命名は難しい。はい、これらは明らかに「ユニットテスト」ではありませんが、明らかな間違いからあなたを守り、エラーについてのフィードバックをより早く提供するため（特に、開発ボックスの結果）。

ですから、実際の問題は、実際の状況よりも、これらのテストをいつ、どのように実行するかということです（あなたのコンテキストにあるべきです）。

私は過去にこの種のテストを広範囲に使用しました-それらは私たちにかなりの痛みを軽減しました。

ユニットテストは、コードのユニットを単独で実行して、正しい入力に対して正しい結果を生成していることを確認することです。分離は、テスト対象のユニットとテスト自体の両方を再現可能にする必要があります。つまり、副作用に依存したり、副作用を導入したりしないでください。

SQLは単独でテストできるものではないため、SQLのテストはユニットテストではないため、SELECTステートメントを除いて、副作用があることはほぼ確実です。単体テストではなく、統合テストと呼ぶことができます。

導入される可能性のある欠陥を開発サイクルのできるだけ早い段階で検出できるようにすることは常に賢明であり、迅速に検出できるように欠陥の原因を簡単に特定できるようにすることは有益です修正しました。

問題のテストは、「ユニットテスト」の本体からより適切に再配置され、別の場所に配置される可能性がありますが、追跡に数時間かかる可能性のある欠陥の導入を防ぐなどの有用なことを行っている場合は、完全に削除しないでくださいダウン。