Need some information regarding "Mark Method as static"
hi,
i am implementing a singleton pattern in one of my classes. when another class method is using this singleton class instance then FxCop shows me an error to mark this class as static too as i am accessing a static property.
if i mark this method as static then any other method which is calling this method also need to be marked as static as per FxCop.
can anybody help me out with this problem.
Thanks in advance
-Rajesh.
[471 byte] By [
Rajeshsv] at [2007-12-20]
Rajesh,
That's the expected behavior of FxCop. If a method doesn't touch instance state (fields, methods, events, etc), then FxCop will flag the method.
If you post the class that is causing the violation, we could suggest a better way of going about this.
Regards
David
hi david,
sorry for not replying back. reagarding the mark method as static the rule gets violated when i run FxCop on my unit test cases and if i mark this methods as static then the NUnit ignores these test method from being executed.
And more over the test methods use the instance of another class. Even then i get the error. just see the sample code that is causing the rule to get violated.
[Test]
[ExpectedException(typeof(System.Exception))]
public
void InvalidMSMQNotifierThreadTC3062() {
MSMQNotifierThread msmqNotifierThread =new MSMQNotifierThread(MockConstants.EmptyInputXml, MockConstants.SleepTime); }
The above method is a test case i have written. An instance of another class is created and i am checking for an Exception by passing some null parameter.
Can you tell me how can i fix the error on this method.
Thanks in advance.
-Rajesh
Rajesh,
FxCop is designed to run over shipping reusable libraries, that is, code that given to the customer to program against. Unit tests do not fall under that category. Simply don't run FxCop over your binaries that contain test code.
If your test code lives in the same binary you have a couple of choices:
- Move your test code to another binary and make use of the InternalsVisibleToAttribute to access the internal details of the assembly that it is testing
- Compile your test code conditionly, for example:
#if TEST
// Test Code
#endif
This allows you to build a version of the assembly that doesn't contain the test code, but can be run under FxCop
- Using an FxCop project, uncheck the classes/namespaces in the targets tab that contain your test code. FxCop will no longer check these
David,
I appreciate the ideas that you've listed; they help me to decide what I'll do re: violations that FxCop is reporting for the unit tests on my current project.
I realize that FxCop is not intended to be run against test code, but I like to do so anyway. Here's why: I treat my test code as a first-class citizen. It's simply another client of my libraries; one of its purposes just happens to be to prove that my libraries behave as I expect when all of their other clients use them. If I do something dumb in my test code, I want to know about it. By keeping ALL of my code clean, I keep the overall quality of my work higher than it would be if I focused only on "production" code in this regard.
Regards,
Craig Demyanovich
Craig,
I wholeheartly agree with respect to the usage rules (which fire to indicate bugs), however, it does not make any sense to run design, performance and other rules against test code. If you attempt to please FxCop with regards to these, you end up doing work for not a lot of benefit (as no one consumes your tests).
Regards
David
