How do I suppress or fix Visual Studio warnings that MSpec Behaves_like fields are unused?

Question

I am writing idiomatic MSpec specs using Behaviors and Behaves_like fields

[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 displays a build warning

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

I am already familiar with the ReSharper code annotations for MSpec and I have naming rules for MSpec subjects and fields. I do not know how to control this warning for unused fields. I would like to avoid suppressing the warning at the project level, because it's actually useful in regular circumstances.

Answer 1

I know this is nearly a two year old question; but, looking at the original question's context, it looks like @Anthony actually wants to use MSpec in his test projects.

The two answers by @bitbonk and @mtijn give great reasons of why you should never ignore these at the project level. But, these two answers ignored @Anthony's original intent, which is he is trying to use MSpec.

You see, MSpec is a BDD framework that uses heavy delegate and field definitions in order to define your specs. Often times, you have unassigned fields and delegates. These cause Warnings to fly like crazy in VS, especially if you have StyleCop and other automation tools to keep developers in check.

[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;
}

Want to take a guess how many warnings that just caused? When in fact, it's perfectly normal to spec our your code and projects well ahead of time. You shouldn't be annoyed by a butt-load of warnings when BDD-spec-ing your design: the whole point of MSpec is to spec your overall story in a context with the least amount of syntax noise. Warnings, make it extremely noisy after you create a dozen or so stories with a dozen or so specs each!

Now, I can see people trying to justify the warnings by saying, "Hey, there's no test yet, it is just stubbed! Warnings make it visible that we need to implement them." Well actually, MSpec already presents these "stubbed" specs in a different manner in the Output window when running, noted as "Skipped" in the test totals, and also quite lovely in their HTML output reports. In other words, you don't need Warnings to yell at you that there are specs unimplemented, cause the runners already do that.

The Behaves_like<T> is a little weird already. But notice that this is it, there's no more implementation to Behaves_like<T> behaviors to that. It's just an unassigned field that MSpec's runner makes use of (all field delegates) and runs them.

So the solution is simple though: For MSpec "Specs" test projects, dedicated solely to Machine.Specifications projects, I often right-click the project's settings and add these to the Supress box:

0169;0649

Again, this is only for MSpec test projects (or really any other BDD C# framework as they use heavy delegates and unassigned fields). You should never do this for any normal project.

Alternatively, if your team lead denies you that right to edit it for your test project, you can just go ahead and implement your specs, adding to the synaxial noise that you were trying to avoid in the first place by using MSpec (blame your team lead for making your life more difficult with "context-switching"!).

[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 =()=> { };
}

That is much more ugly, and really takes you off the focus of the overall BDD story you are trying to spec out. Not to mention, all of your specs will pass now with nothing implemented (you can add even more to make it a hard fail, with throw new NotImplementedException() - but seriously?). But, it's a way to "implement" each field if you don't want to ignore them at the project level.

Answer 2

If you use ReSharper, usually, it is not necessary to clutter your code with #pragma warning disable 0169 noise or even worse, globally disable this warning for the project. MSpec is all about less noise and ceremony after all.

ReSharper has this concept of code annotations. And MSpec provides some for its types. In case you have the SubjectAttribute over your classes, ReSharper will automatically know that it must not complain about unused fields.

Unfortunately there is a bug about this in ReSharper 6 which has already been fixed.