How to disable or fix Visual Studio warnings that MSpec Behaves_like fields are not used?

Question

I am writing idiomatic MSpec specs using the Behaviors and Behaves_like

 [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 assembly warning

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

I am already familiar with ReSharper code annotations for MSpec, and I have naming conventions for MSpec objects 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 is really useful in normal circumstances.

Answer 1

If warnings contain a warning number, you can suppress these warnings for each class or even line of code by adding pragma disable / enable .

To suppress warnings for “XYZ Field is Never Used,” you this :

 #pragma warning disable 0169 ... field declaration #pragma warning restore 0169 

Answer 2

I know this is almost a two year question; but looking at the original context of the question, it looks like @Anthony really wants to use MSpec in their test projects.

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

You see that MSpec is a BDD base that uses heavy delegate and field definitions to define your specifications. Often you have unallocated fields and delegates. This makes Warnings 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 guess how many warnings just triggered? When in fact, it is perfectly normal to check our code and projects well in advance. You should not be annoyed by the warning butt when the BDD specification of your design: the whole point of MSpec is to specify a common history in a context with the least amount of syntax noise. Warnings, make it extremely noisy after you create a dozen stories with a dozen or so specifications each!

Now I see people trying to justify the warnings, saying: "Hey, there is no test yet, it is just stunned!" The warnings show that we need to implement them. "In fact, MSpec already presents these" muffled "specifications differently in the Output window at startup, marked as" Missed "in the test results, and are also very beautiful in their output reports. HTML: In other words, you don't need Warnings to shout at you that the specs aren't implemented, because runners are already doing this.

Behaves_like<T> already a little strange. But note that there is no implementation for Behaves_like<T> behaviors . This is just an unattached field in which the MSpec runner uses (all field delegates) and runs them.

So, the solution is simple: for MSpec "Specs" test projects dedicated exclusively to Machine.Specifications projects, I often right-click on the project settings and add them to the Supress field:

0169; 0649

Again, this is only for MSpec test projects (or, indeed, 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 leader denies this editing right for your test project, you can simply implement your specifications by adding to the synaxial noise that you tried to avoid primarily with MSpec (blame your team for what you do your life is 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 =()=> { }; } 

This is much more ugly, and you are actually diverting attention from the general BDD story you are trying to describe. Not to mention that all your specifications will pass now without any changes (you can add even more to make it unsuccessful, with throw new NotImplementedException() - but seriously?). But this is a way to “implement” each field if you do not want to ignore them at the project level.

Answer 3

If you use ReSharper, there is usually no need 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 annotation . And MSpec provides some for its types. If you have a SubjectAttribute , ReSharper will automatically know that it should not complain about unused fields.

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