複雑な正規表現の単体テストが必要ですか？

アプリケーションで複雑な正規表現の単体テストを作成する必要がありますか？

• 一方では、入力と出力の形式は単純で明確に定義されていることが多いため、テストが容易であり、非常に複雑になることが多いため、テストは特に価値があります。
• 一方、それら自体は、あるユニットのインターフェースの一部ではありません。インターフェイスのみをテストし、暗黙的に正規表現をテストする方法でテストする方が良い場合があります。

編集：

私は、これが内部コンポーネントの単体テストの特殊なケースであるとコメントしているDoc Brownに同意します。

しかし、内部コンポーネントの正規表現にはいくつかの特別な特性があります。

1. 単一行の正規表現は、実際には独立したモジュールではなく、非常に複雑になる可能性があります。
2. 正規表現は、副作用なしで入力を出力にマップするため、個別にテストするのは非常に簡単です。

独断論は別として、本当の問題は、複雑な正規表現の単体テストに価値を提供するかどうかです。正規表現が十分に複雑な場合は、（正規表現がパブリックインターフェイスの一部であるかどうかに関係なく）バグを見つけて再現し、リグレッションを防ぐことができるため、（正規表現がパブリックインターフェイスの一部であるかどうかに関係なく）値を提供することは非常に明らかです。

正規表現は強力なツールになる可能性がありますが、複雑な正規表現にわずかな変更を加えた場合でも、正常に機能するという信頼できるツールではありません。

そのため、カバーすべきケースを文書化する多くのテストを作成します。また、検証に使用する場合、失敗するケースを文書化する多くのテストを作成します。

正規表現を変更する必要があるときはいつでも、新しいケースをテストとして追加し、正規表現を変更して、最善を期待します。

一般に単体テストを使用しない組織にいた場合、使用する正規表現をテストするテストプログラムを作成します。必要に応じて、自分の時間にそれを行うこともあります。髪の色を失う必要はありません。

正規表現は、アプリケーションの他の部分とともにコードです。コード全体が期待どおりに動作することをテストする必要があります。これにはいくつかの目的があります。

• テストは実行可能なドキュメントです。コードを実行するために必要なことを明確に示しています。テストされている場合は重要です。
• 将来のメンテナーは、変更した場合、テストにより動作が変更されないことを確認できます。

残りの言語に別の言語のコードを組み込むことで克服する必要がある追加のハードルがあるため、メンテナンスの利点のためにこの特別な注意を払う必要があります。

要するに、アプリケーションをテストする必要があります、期間。大きなブラックボックスの一部として、単独で実行する自動テストで正規表現をテストするか、手動でそれをいじるだけであるかは、確実に機能するために必要なポイントに次ぐものです。

単体テストの主な利点は、時間を節約できることです。現在または将来の任意の時点で、何度でもテストできます。正規表現がいつでもリファクタリング、微調整、より多くの制約を取得するなどと信じる理由がある場合あなたはそれを壊さなかったので、すべてのエッジケースを熟考するのに1時間かかりました。または、コードを怖がって生きて、決して変更しないことを学びます。

一方、それら自体は、あるユニットのインターフェースの一部ではありません。インターフェイスのみをテストし、暗黙的に正規表現をテストする方法でテストする方が良い場合があります。

これで自分で答えたと思います。ユニット内の正規表現は、おそらく実装の詳細です。

SQLのテストに使用するものは、おそらく正規表現にも使用します。SQLの一部を変更するときは、おそらくSQLクライアントを介して手動で実行し、期待どおりの結果が得られるかどうかを確認します。同じことは、正規表現を変更するときにも当てはまります。いくつかの正規表現ツールをサンプル入力とともに使用して、期待どおりに動作するかどうかを確認します。

私が有用だと思うのは、正規表現の近くにあるコメントと、一致すべきテキストのサンプルです。

質問する必要がある場合、答えはイエスです。

いくつかのFNGが登場し、正規表現を「改善」できると考えているとします。今、彼はFNGなので、自動的にばかです。どんな状況でもあなたの貴重なコードに触れてはいけないまさにそのような人！しかし、多分彼はPHBに関連しているか何かにので、あなたにできることは何もありません。

PHBがあなたを蹴って叫んでこのプロジェクトに引きずり込み、すべてがうまくいかなくなったときに、「この混乱をどのようにしたかについてのヒントを与えるかもしれません」ということを知っている場合を除きます。慎重に検討したすべてのケースを書き留めます、美しい表現の傑作を構築する際にます。

そして、それらをすべて書き留めているので、一連のテストケースを作成する方法の3分の2になります。フレームワークを構築したら、正規表現のテストケースは簡単に実行できます。

これで、一連のエッジ条件、代替案、および期待される結果が得られました。そして、突然、テストケースは、これらすべてのあまりにもアジャイルなブログ投稿で約束されたドキュメントです。彼の「改善」が既存のテストケースに合格しない場合、それはあまり改善ではない、とFNGに指摘します。そして、元のコード、といくつかの問題を示す彼の提案された新しいテスト・ケースであるところ、それは彼が今までに、変更する必要はありません動作しますので、!!!