6

BehaviorsおよびBehaves_likeフィールドを使用して慣用的な MSpec 仕様を作成しています

[Subject(typeof(IUnitMaskConverter))]
public class When_converting_unit_masks_by_lookup
{
    Behaves_like<UnitMaskConverterBehaviors> a_unit_mask_converter;
    protected static LookupUnitMaskConverter _converter = new LookupUnitMaskConverter();
}

Visual Studio にビルドの警告が表示される

The field 'Specs.UnitMask.When_converting_unit_masks_by_lookup.a_unit_mask_converter' is never used

私はすでに MSpec の ReSharper コード注釈に精通しており、MSpec のサブジェクトとフィールドの命名規則を持っています。未使用のフィールドに対するこの警告を制御する方法がわかりません。通常の状況では実際に役立つため、プロジェクトレベルで警告を抑制することは避けたいと思います。

4

3 に答える 3

5

これはほぼ 2 年前の質問です。しかし、元の質問のコンテキストを見ると、@Anthony は実際にテスト プロジェクトで MSpec を使用したいと考えているようです。

@bitbonk と @mtijn による 2 つの回答は、プロジェクト レベルでこれらを無視してはならない大きな理由を示しています。しかし、これらの2つの回答は、@ Anthonyの当初の意図、つまり彼がMSpecを使用しようとしているということを無視しています。

おわかりのように、MSpec は仕様を定義するために大量のデリゲートとフィールド定義を使用する BDD フレームワークです。多くの場合、割り当てられていないフィールドとデリゲートがあります。これらにより、特に StyleCop やその他の自動化ツールを使用して開発者をチェックしている場合、VS で警告が狂ったように飛び交います。

[Subject(typeof(PostService), "when_calling_Save()"]
class with_a_valid_Post_object
{
  It should_save_to_repository;

  It should_update_post_counter;

  Behaves_like<Normal_Behaviors> a_PostService;
}

発生した警告の数を推測したいですか? 実際には、コードとプロジェクトをかなり前もって仕様化するのはまったく普通のことです。設計を BDD で仕様化するときに、大量の警告に悩まされる必要はありません。MSpec の要点は、構文ノイズが最小限のコンテキストで全体的なストーリーを仕様化することです。警告、それぞれが十数個の仕様を持つ十数個のストーリーを作成した後は、非常にうるさくしてください!

今では、「まだテストはありません。スタブされているだけです。警告によって、実装する必要があることが明らかになります」と言って、警告を正当化しようとしている人がいます。実際には、MSpec は実行時にこれらの「スタブ化された」仕様を別の方法で出力ウィンドウに表示し、テストの合計では「スキップ」と表示され、HTML 出力レポートでも非常に美しいものになっています。言い換えれば、実装されていない仕様があることを警告する必要はありません。ランナーはすでにそれを行っているからです。

もうBehaves_like<T>ちょっと変です。しかし、これで終わりであることに注意してください。これ以上の実装はありませんBehaves_like<T> behaviors。MSpec のランナーが (すべてのフィールド デリゲート) を使用して実行するのは、割り当てられていないフィールドです。

ただし、解決策は簡単です。Machine.Specifications プロジェクト専用の MSpec "Specs" テスト プロジェクトの場合、私はしばしばプロジェクトの設定を右クリックし、これらを [抑制] ボックスに追加します。

0169;0649

繰り返しますが、これは MSpec テスト プロジェクト (または、重いデリゲートと割り当てられていないフィールドを使用するため、実際には他の BDD C# フレームワーク) のみを対象としています。通常のプロジェクトでは、これを行うべきではありません。

あるいは、チーム リーダーがテスト プロジェクト用に編集する権利を拒否した場合は、仕様を実装して、MSpec を使用して最初に回避しようとしていたシナキシャル ノイズを追加することができます (チームのせいにします)。 「コンテキスト切り替え」であなたの人生をより困難にするためのリード！）。

[Subject(typeof(PostService), "when_calling_Save()"]
class with_a_valid_Post_object
{
  It should_save_to_repository =()=> { };

  It should_update_post_counter =()=> { };

  Behaves_like<Normal_Behaviors> a_PostService =()=> { };
}

それははるかに醜く、仕様を明らかにしようとしている全体的な BDD ストーリーの焦点から実際に離れてしまいます。言うまでもなく、あなたのすべての仕様は、何も実装されていなくても合格します (ハードフェイルにするためにさらに追加できますがthrow new NotImplementedException()、真剣に?)。ただし、プロジェクト レベルでそれらを無視したくない場合は、各フィールドを「実装」する方法です。

于 2013-07-24T20:40:53.620 に答える
2

#pragma warning disable 0169ReSharper を使用する場合、通常、コードをノイズで乱雑にする必要はありません。さらに悪いことに、プロジェクトのこの警告をグローバルに無効にします。MSpec は、結局のところ、ノイズとセレモニーの削減がすべてです。

ReSharper には、このコード注釈の概念があります。そして、MSpec はそのタイプにいくつかを提供します。クラスにSubjectAttributeがある場合、ReSharper は、未使用のフィールドについて不平を言ってはならないことを自動的に認識します。

残念ながら、ReSharper 6にはこれに関するバグがあり、既に修正されています。

于 2011-09-28T18:59:50.870 に答える
1

警告に警告番号がある場合は、プラグマdisable / enableを追加することで、クラスごと、またはコード行ごとに警告を抑制することができます。

「フィールドXYZは使用されません」の警告を抑制するには、次のようにします。

#pragma warning disable 0169
... field declaration
#pragma warning restore 0169
于 2011-08-05T15:27:04.623 に答える