I am using Visual Studio 2010 and would like to exclude the generated service reference code from my code coverage statistics.
I found an article pre 2010 that mentions using DebuggerNonUserCode and DebuggerHidden attributes. I have tried this an it works as advertised. DebuggerNonUserCode is set at the class level, but with 50+ classes generated in each of the generated service reference code files, this is not an attractive option.
Does anyone have any alternative solutions?
The generated classes are partial. If you create a new class in your project with the same namespace and class declaration you can add the [ExcludeFromCodeCoverage] attribute to your partial class. That way you don't have to go back and edit the Reference.cs file whenever you refresh your reference.
In Reference.cs, you can find an existing attribute, like [System.Diagnostics.DebuggerStepThroughAttribute()] and do a search and replace with [System.Diagnostics.DebuggerStepThroughAttribute()][System.Diagnostics.DebuggerNonUserCode()].
The major drawback is that you have to redo this each time you update the reference.
I don't understand why MS does not make the code coverage tool smart enough to skip service reference generated code.
System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage can be used on top of the class. This is a poor option since you need to redo this anytime you regenerate your code. Maybe Microsoft could do this for us automagically when creating service references, entity framework types, etc...
You could create a code generator that emits partial classes with the DebuggerNonUserCode attribute.
Related
I'm trying to figure out how to unit test a basic MS Bot Framework dialog and cannot get it to work the way everything on the internet says it should work.
Everything I find basically says follow this:
https://github.com/Microsoft/BotBuilder/blob/master/CSharp/Tests/Microsoft.Bot.Sample.Tests/EchoBotTests.cs
Well, here's the problem with that:
await Conversation.SendAsync(scope, toBot);
That is defined as internal so it is not accessible outside of the bot.builder code. So it is totally useless unless you are programming tests for internal bot.builder stuff.
Is there a new way to get around this?
Bot Framework is an open source project, you can download the code and modify it as you need. In your case removing the internal keyword. Another option would be to create a new class that inherits from the class you are trying to use and making your own access levels on the methods you need to override. This blog post describes how to use the code locally.
I had written some custom code using java . I want to add the code to the User defined java class in Kettle in the code snippets section. Is there a way to add the custom code snippets in the Classes and code fragment in UDJC so that it can be reusable.
Thanks.
For the moment there is no ability to add code snippets using ui at runtime. You can submit issue with pentaho jira if you want this functionality. Or just as workaround you can edit codeSnippits.xml (situated under lib/kettle-ui-*.jar/org/pentaho/di/ui/trans/steps/userdefinedjavaclass/) and re-zip this file back to the jar.
I would not recommend going down this path.
The reason is very simple, UDJC in PDI is Janino, a rather minified (but super fast) Java compiler, and I quote the Pentaho wiki for User Defined Java Class:
Not 100% Java... The first thing to know is that Janino and as a
consequence this step doesn't need the complete Java class... the
most apparent limitation is the absence of generics
What happened if we'd been able to add code snippets on the fly? Probably not good things.
However, and this is very useful, consider wrapping your code in a JAR package as suggested in the comments, include it in the lib-ext folder of your PDI environment and import it to User Defined Java Classes at will. IMHO, this is the right way.
I hope this helps a bit.
I am trying to modify the PartCover source code to exclude coverage by method. However,it looks like the main logic is in the c++ code. Since it is not possible to step into the cpp code while debugging,can someone please guide me as to which files I would need to modify? I am thinking it should be rules.cpp and instrumentator.cpp...and some refactoring needed in other .cpp .h and .cs files due to changes made in these. But If I am wrong, or if there are other places that I should also be looking at, please let me know. Any other hint to proceed would also be appreciated.
Thanks,
Thanks for your reply.
However, uncommenting the DebugBreak is causing the nunit-console-86.exe to stop working. I changed the NUnit version to 2.5.7 to match it with the version of nunit-framework.dll inside the PartCover bin folder, but the problem still exists. Any idea what could be causing this?
We have our own console app that runs coverage check method wise. It makes sure if any new method is added, or code in existing methods refactored, the coverage still should be at least more than our decided percentage. Sometimes there are methods for which testing cannot be done completely for whatsoever reason. For those, it doesn't make sense to exclude the entire class.
The files you have mentioned are probably the best places in the C++ code to apply your extra filter. I assume you have a way of extending the syntax currently used for include and exclude filters of modules and classes.
You can debug the code if you uncomment the DebugBreak in CorProfiler::Initialize (when you .NET process runs and the profiler is loaded this will allow you to attach a C++ debugger to the profiler)
May I ask why you need to exclude specific methods? I can see the need to exclude classes i.e. Test Classes and the like but not specific methods, this seems like something that could be easier done if necessary be just ignoring the results in any reports.
If you take a look at the library I've been working on for dependency injection in C++, I recently added an example that mimics something I created for a real project: the ability to inject application configuration directly.
This all works fine as the constructor just asks for a ConfigItem<ConfigTag> type and that is magically delivered.
A problem occurs when I need to access all of them at the same time (say for a configuration dialog).
The stupid solution I came up with was to generate, using the preprocessor, a class that gets all the configuration items in the constructor as shown here.
This problem would be "nicely" solved if I could inject the injector as I would then only have to generate the code to collect all the ConfigItem instances as shown here.
Note that all the ConfigItems are within a singleton scope.
Hope this question makes sense: how would you do this?
Sounds like you have re-invented the Service Locator Pattern
We may start converting an old VS2003 MFC project to use the fancy new features provided by the MFC Feature Pack and VS2008. Several of the new UI controls would be very nice except for one thing - they automatically save their information to the registry. I don't have a problem with the registry, but for the multiple environments the users use out program from, it's much easier to save user data to the database.
So, I'm hoping that there is one main "access the registry" function that could be overloaded to point the database. But brief investigation hasn't turned up anything. Has anyone else had any success doing something similar?
It seems like it should be possible to do what you're suggesting, according to the information on this page in MSDN. I haven't tried this myself, so I don't know how difficult it will be in practice.
According to the documentation, you should create a class that inherits CSettingsStore to read and write the settings, and call CSettingsStoreSP::SetRuntimeClass so that the framework uses your class instead of the default.
The MFC feature pack uses code supplied by BCGSoft and they added this feature (so you can save state to an XML file, database, etc.) way back in 2001. I don't have the feature pack on this PC but try looking for a class called something like CMFCRegistrySP.
I will check myself tomorrow.
Does the StateCollection sample do this?
http://msdn.microsoft.com/en-us/library/bb983406.aspx