I'm working with .feature files for BDD testing of a C# app with Specflow (and Playwright for front-end). I'm having an issue where it doesn't recognize seem to the step definitions. The auto-formatter etc. works fine (indents properly etc.)
One thing to note is that there was a recent refactoring - but shouldn't Rider be able to pick up on these updates? Especially when Visual Studio Code is able to color the text correctly.
Actual:
Definitions are not recognized
Actual - not good
Expected:
Rider recognizes definitions, declarations etc. and colors them orange:
Expected - good
Extension: SpecFlow for Rider
Also tried Gherkin 222.4459.16 by Jetbrains (already tried disabling each extension)
Editor settings
Related
Having just switched to VS2019 I’m exploring whether to use code analysis. In the project properties, “code analysis” tab, there are numerous built-in Microsoft rule sets, and I can see the editor squiggles when my code violates one of these rules. I can customise these rule sets and “save as” to create my own.
I have also seen code analyser NuGet packages such as “Roslynator” and “StyleCop.Analyzers”. What’s the difference between these and the built-in MS rules? Is it really just down to more comprehensive sets of rules/more choice?
If I wanted to stick with the built-in MS rules, are there any limitations? E.g. will they still get run and be reported on during a TFS/Azure DevOps build?
What's the difference between legacy FxCop and FxCop analyzers?
Legacy FxCop runs post-build analysis on a compiled assembly. It runs as a separate executable called FxCopCmd.exe. FxCopCmd.exe loads the compiled assembly, runs code analysis, and then reports the results (or diagnostics).
FxCop analyzers are based on the .NET Compiler Platform ("Roslyn"). You install them as a NuGet package that's referenced by the project or solution. FxCop analyzers run source-code based analysis during compiler execution. FxCop analyzers are hosted within the compiler process, either csc.exe or vbc.exe, and run analysis when the project is built. Analyzer results are reported along with compiler results.
Note
You can also install FxCop analyzers as a Visual Studio extension. In this case, the analyzers execute as you type in the code editor, but they don't execute at build time. If you want to run FxCop analyzers as part of continuous integration (CI), install them as a NuGet package instead.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019
So, the built-in legacy FxCop and NuGet analyzers only run at build time while the extension analyzers can run at the same time the JIT compiler does as you type. Also, you have to specifically say to run legacy code analysis on build, whereas the NuGet analyzers will run on build just because they are installed. And analyzers installed as NuGet or extensions won't run when you go to the menu option "Run Code Analysis".
At least, that's what I get out of that page.
There's a link near the bottom of that page that takes you to what code analysis rules have moved over to the new analyzers, including rules that are now deprecated.
https://learn.microsoft.com/en-us/visualstudio/code-quality/fxcop-rule-port-status?view=vs-2019
The different analyzers attempt to cover different coding styles and things Microsoft didn't cover when they built FxCop. With the little research I just did on this, there's a whole rabbit hole to follow, Alice, that would take more time than I have right now to devote to it. And it seems to be filled with lots of arcane knowledge and OCD style code nitpicks that make Wonderland seem normal. But that's just my opinion.
There's lots of personal and professional opinion about various rules in these and basic Microsoft rules, so there's plenty of room to use what you want and disable what you don't. For a beginner, I'd suggest turning on only a few rules at a time. That way you aren't inundated with more warnings and errors than lines of code you might have. Ok, so that might be a bit of an exaggeration, but there's so many rules that really are nitpicks, especially on legacy code, that they aren't really worth it to have enabled, since you likely won't have time to fix it all. You will also want to do basic research and use "common sense" when you decide what to enable. ("Do I really need to worry about variable capitalization coding style consistency on an app that's been ported into 4 different languages over 15+ years and has 10k files?") This is both personal and professional opinion here, so follow it or not.
And don't forget the rules that contradict each other. Those are fun to deal with.......
I have gone through the Opencover wiki documentation and tried a lot to figure out what would be the filter criteria for not to include test assembly as part of code coverage. Here is the problem
for eg I have many assemblies starts with sample name like sample.submodule.assembly1.dll, sample.submodule.assembly2.dll, my tests assembly also starts with sample like sample.submodule.tests.dll, here I applied the filter criteria for openCover
1.-filter: "+[sample*]* -[*tests]*"
it didn't work, not generating report file.
-filter: "+[sample*]* -[sample.submodule.tests]*" didn't work, not generating report file,
-filter: "+[sample*]* -[*]*tests*" didn't work, not generating report file too,
can somebody please advise what can be the filter criteria here to exclude all the test files from code coverage
First run OpenCover without any filters.
Now you can look at the XML report produced (or you can use ReportGenerator to turn it into HTML) and identify assemblies/modules that you wish to exclude.
now you can apply filters using the filter switch e.g.
-filter:"+[*]* -[*.tests]* -[*.Tests]*"
NOTE: no space between : and first "
or
"-filter:+[*]* -[*.tests]* -[*.Tests]*"
if you are talking about writing unit test using visual studio nunit adaptor then you have open cover UI visual studio extension available for all such purpose. it is wonderful.
Step 1) Install open cover from latest relese build https://github.com/opencover/opencover/releases
Step 2) Usuall it will install C:\Users\goma1940\AppData\Local\Apps\OpenCover (%localappdata%\Apps\OpenCover)
Steo 3) Install VS Extn from gallery https://visualstudiogallery.msdn.microsoft.com/6950a046-8919-4935-8542-c6f37956f688
Step 4) you have open cover test explorer and open cover coverage result pane as below…
Currently we are using Silk4Net to implement classic regressions GUI tests for a C# WinForms application. We gathered the Code Coverage of those tests via NCover 4.3 and everything worked fine.
Last week we updated NCover to the newest Version (4.5.x) and now it seems that Silk4Net is not able to identify the GUI objects (the Explorer of Silk4Net only finds generic "Control" objects) and not the "real" object type like a Button or so.
Has anybody encountered the same problem like we do currently and did you find a proper solution to get it running again?
Thanks!
I've recently started playing around with Specflow, and generating test cases based on the examples on their website[1]. However, the generated code doesn't compile. For example, the "Given a new bowling game" line, generates the following:
testRunner.Given("a new bowling game");
But, the signature for ITestRunner.Given() is:
Given(string text, string multilineTextArg, Table tableArg);
The same applies for When(), And() and Then(). It also seems that the binding step definitions require a string parameter as well, which does not appear to be documented.
Is anyone else having these same issues? I downloaded Specflow 1.6.1, and am using VS2005.
Thanks,
Daniel B.
[1] http://specflow.org/specflow/workflow.aspx
The "overloads" are done through extension methods, that are not supported in .NET 2.0 used by VS2005. So i think you have to upgrade to VS2008 at least to be able to use SpecFlow.
See also SpecFlow forum entry related to VS2005
I haven't yet installed my license of NCover 3, and am still running 1.5.8 on my build server. I am trying to exclude full assemblies and specific classes that I don't want included in the report, because they are artificially lowering the coverage results.
In NCoverExplorer, I was playing around with the options because there is a coverage exclusions section in the Options tab where you can specify full namespaces. I've entered the fully qualified classes, and for some reason, only a handful of them get excluded, and I cannot figure out why. For example, when I add System.ComponentModel.Composition to the list, it never gets excluded!
Is this just a bug in 1.5.8 that I have to live with for now, since it is a beta and also no longer supported? Although I do have a new license for the server, I'd like to be able to do some coverage at home on my personal computer.
I found a really great article on using a CoverageExcludeAttribute to make NCover automatically skip those classes / methods that are marked with this attribute. Is this the best option?
Did you try using regular expressions to include/exclude the assemblies -
//ias AuctionSniper([.\w]*?)(?<!Tests)
includes all assemblies that begin with AuctionSniper but don't end with Tests e.g. AuctionSniper.Main.exe
You can specify multiple patterns separated by semicolons.
or //ias .*vendorsupplied.*;.*tests
This works with NCover 3 - you can give it a try if it works for the free/community edition.
One way to get part way there is to also use the "assemblies to include in coverage" option. This allowed me to ignore System.ComponentModel.Composition. However, exlcuding most of the other classes and namespaces still doesn't work. It's a little odd how when I exclude an entire class, it only excludes the methods, but not any of the contained classes.