一部のプログラマーは、静的分析について聞いたとき、すべてのコードが単体テストでカバーされており、これがすべてのエラーをキャッチするのに十分であるため、静的分析を必要としないと言います。 ユニットテストの助けを借りて理論的に見つけることができるエラーに遭遇しましたが、それについて知らなければ、そのようなテストを書くことはほとんど不可能です。
はじめに
Lucene.Netは、JavaからC＃に移植された人気のある全文検索ライブラリです。 ソースコードは公開されており、プロジェクトのWebサイトhttps://lucenenet.apache.org/で入手できます 。
このプロジェクトはゆっくりと開発されており、多くのコードが含まれておらず、他の多くのプロジェクトで全文検索に使用されているため、アナライザーは5つの疑わしい場所のみを検出しました[ 1 ]。 私はこれ以上期待していませんでした。 しかし、これらのポジティブな点の1つは特に興味深く思えたので、ブログの読者にそれについて話すことにしました。
見つかったエラーについて
+ =の代わりに、誤って= +と書くことができるV3035診断があります。ここで、+は単項プラスになります。 C ++言語向けの同じV588診断で類推してやったとき、C＃でそのような間違いを犯すことは本当に可能だと思いましたか？ C ++では、OK-誰かがIDEの代わりに異なるテキストエディタを使用します。このエディタでは、エラーに気付かずに自分を封印できます。 しかし、セミコロンを入れた後にコードを自動的に整列させるVisual Studioで入力すると、どうすればこれをスキップできますか？ それができることがわかりました。 Lucene.Netでこのようなエラーを見つけました。 また、静的分析以外の方法で検出することは非常に難しいため、より興味深いものです。 コードを考慮してください：
protected virtual void Substitute( StringBuilder buffer ) { substCount = 0; for ( int c = 0; c < buffer.Length; c++ ) { .... // Take care that at least one character // is left left side from the current one if ( c < buffer.Length - 1 ) { // Masking several common character combinations // with an token if ( ( c < buffer.Length - 2 ) && buffer[c] == 's' && buffer[c + 1] == 'c' && buffer[c + 2] == 'h' ) { buffer[c] = '$'; buffer.Remove(c + 1, 2); substCount =+ 2; } .... else if ( buffer[c] == 's' && buffer[c + 1] == 't' ) { buffer[c] = '!'; buffer.Remove(c + 1, 1); substCount++; } .... } } }
ドイツ語の接尾辞を切り捨てて共通のルートを強調するGermanStemmerクラスがあります。 次のように機能します。まず、Substituteメソッドは、さまざまな文字の組み合わせを他の文字に置き換えて、サフィックスと混同しないようにします。 置換：「sch」は「$」、「st」は「！」 など（サンプルコードから確認できます）。 さらに、このような置換によって語長が短縮される文字数は、変数substCountに蓄積されます。 さらに、Stripメソッドは余分なサフィックスを切り捨て、最後にResubstituteメソッドが逆置換を実行します。「$」を「sch」、「！」で置き換えます。 「st」に。 つまり、たとえば、kapitalistischen（資本家）という単語があった場合、 ステマーは次のように機能します：kapitalistischen => kapitali！I $ en（Substitute）=> kapitali！I $（Strip）=> kapitalistisch（Resubstitute）。
コードのこのタイプミスにより、「sch」を「$」に置き換えると、substCount変数に値2が割り当てられ、substCountは2ずつ増加します。また、静的解析以外の方法を使用してこのエラーを見つけるのは非常に困難です。 開発者の中には、「ユニットテストがある場合に静的アナライザーが必要なのはなぜですか？」 したがって、テストでこのようなエラーをキャッチするには、GermanStemmerを使用してドイツ語のテキストでLucene.Netをテストする必要があります。テストでは、「sch」と置換が実行される別の文字の組み合わせを含む単語にインデックスを付ける必要があります。 'sch'の前の単語に存在して、substCount = + 2式が実行されるまでにsubstCountがゼロ以外になるようにします特にエラーが表示されない場合は、テストのかなり重要な組み合わせ。
おわりに
単体テストと静的分析は排他的ではありませんが、補完的なソフトウェア開発手法[ 2 ]。 PVS-Studio静的アナライザーをダウンロードし、プロジェクトをチェックし、単体テストでは検出されなかったエラーを見つけることをお勧めします 。
サイトリンク
- アンドレイ・カルポフ。 なぜ小さなプログラムではエラーの密度が低いのか 。
- アンドレイ・カルポフ。 静的分析がTDDを補完する方法 。
この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：イリヤイワノフ。 Lucene.Netの異常なバグ 。
記事を読んで質問がありますか？