Develop Reference

How to hide my test framework code and give the posibility for other testers to only be able to write features?

I have a test framework written in C#, I am using Selenium, nUnit and Specflow.
Visual Studio is the tool and I have the normal project folder structure (pages, hooks, steps, features).
Testcases are associated with AzureDevOps and the code is pushed to the repo and pipilines are working great.
My issue is that I want to hide the code under the level of the features.
The idea is that other people could create new feature files and create tests within them, but I do not want them to be able to see the code that is under those Gherkin sentences.
So they should be only able to create and write new features, but not seeing the code below.
Could you please give me some ideas how this can be achieved?

You can import bindings from external assemblies. In SpecFlow.json, add:
{
"stepAssemblies": [
{
"assembly": "Name.Of.Your.StepDefinitions.dll"
}
]
}
While this is typically used as a means to reuse step definitions in multiple projects, you could use this to "hide" the step definitions from test writers. The step definitions would be a pre-compiled DLL file that they can import into a different Visual Studio solution.
This requires two different solutions in Visual Studio:
A regular class library that holds step definition classes. You will probably need to choose .NET Core or .NET Framework 5+, since it must integrate with a unit testing framework. I don't believe .NET Standard would work (but you can certainly try).
Another Visual Studio solution that testers can use, which contains the feature files. This project would reference a DLL file you would create from project #1.
The challenge is disseminating this DLL file. Any update you make would need to be given to the testers' Visual Studio solution. A couple of options come to mind:
Manually update solution #2.
Create a NuGet package for solution #1. Set up a build pipeline in Azure DevOps to build, package, and push this NuGet package to your project's "Artifacts" feed whenever you make code changes. Someone (you or a tester) would need to update that NuGet package in solution #2.
As an alternative, give everyone access to the features and step definitions, but enforce a pull request policy on the repository requiring you as a reviewer. That way you can protect the main branch as the gatekeeper. Testers can submit changes to step definitions, and you are free to reject their pull requests if the changes are not satisfactory.
This, of course, depends on the team structure. If you have outside contractors, sharing the step definition code might not be desirable. Just don't limit people's abilities simply because you don't trust their skill level. Use pull request policies requiring you as a reviewer if they change step definition files. This allows you to benefit from someone else's labor while still giving you control.

Is it possible to reference feature files from external folders in Specflow like we use glue in Java with Cucumber

I been working on creating tests for API's. I wanted to write tests in both Java and .Net and I started of with Java using Cucumber and Rest Assured Library. Now when I am trying to write the same tests with .Net using Specflow, But I want to reuse the same feature files that the Java Project is using and write step definitions for it.
Is it possible that I can define the location of the feature files for a Specflow project? Something like Glue with Cucumber wherein I can specify my feature files location?
My Project has the following three folders,
JavaTestCases
FeatureFiles
DotnetTestCases
Tests in the JavaTestCases are able to refer to the feature files from FeatureFiles folder using glue but I am unable to do so for the DotnetTestCases.
Tried researching for alternatives on Google but seems like I did not find anything as an equivalent of glue in Specflow

Yes you can, but SpecFlow requires entries in the .csproj file for your test project. It will likely be a manual copy and paste operation in Visual Studio.
Being that you have multiple APIs or applications, I find it hard to believe that the feature files are truly reusable. If they are, how can the other components be justified?
The fact you can reuse feature files now may be coincidence only. I think this is one of the cases where copy and paste might actually prevent headaches later on.

How can I run SpecFlow tests outside of visual studio

I have a suite of SpecFlow tests written in C# using MSTest as the framework. I understand its possible to upload the DLL to MTM and run them through there.
However I was wondering if it was possible for me to execute these tests outside of Visual Studio. For example via a dashboard. I wouldn't want the results uploaded to MTM or TFS as we have a few projects that are not connected to them.
My framework uploads results to a database so thats good enough for me in terms of logging.
I gather I would have to do something with the DLL thats generated from building the project that contains SpecFlow, but I want to avoid using reflection if at all possible.
Does anyone have any ideas on how I could go about this?

Tests written using Specflow are simply tests in selected testing framework (MSTest in your case) so you can run them using test runner for that framework.
In case of MSTest you can use MSTest.exe (located in Visual Studio directory, probably also part of TFS installation). Take a look here http://msdn.microsoft.com/en-US/library/ms182489.aspx on how to run tests (easiest way is to use /testcontainer option).
Please note that MSTest is not the best test framework and running outside of Visual Studio is not the same as running them inside of it. There are problems with config file and separate files needed by tests. If you hit these problems, you can switch to other test framework (I use NUnit).

Using Nunit without creating separate project

I am creating one web application which has structure as shown in following image:
I have all entities and datastore files in the App_Code folder. i.e no separate project layer is created. I want to use Nunit for unit testing. But as for NUnit testing I need projectname.dll and my web application will not create dll I don't know how to test my methods.
If I create a separate project for unit tests, I can not reference datastore and other files in that project. Kindly suggest how can I use Nunit in this case.

Please, check this: Unit Testing ASP.net Web Site Project code stored in App_Code.
You can also create another project, just for unit testing purposes. When you create it, just include all the required files (in App_Code) As a Link. That way you will be creating shortcuts, so if you modify one file in your project, the other project you created will reflect the changes.

How to use NUnit GUI with a C#/ASP.NET website?

I have a C#/ASP.NET website that has some code (*.cs) files in the App_Code directory. I would like to test them using NUnit. I have written a test file with the proper [TestFixture] and [Test] annotations and have put it here: App_Code/Test/TestClassName.cs.
I load up the NUnit GUI to run it but it wants me to select a .exe or .dll file. There is none in the bin folder of my project. My project does successfully run and is built and everything, but still no exe or dll file. How can I get the NUnit Gui to just run the test in that class?

I don't recommend putting test code in the same package you'll be deploying to production.
You may want to move the test classes to a library project, something like Business.UnitTest(there may be a built in way to create an nUnit specific project, if there is, use that). Then move the business classes that are in your App_Code directory into another project called Business. Have Business.UnitTest reference the Business library. That should get nUnit to run(I don't believe that nUnit runs against websites, only libraries, but I'm not 100% sure).
For your website add a reference to the business library you just created so your production code can access the business objects in the business library. You may have to work out some namespace issues, but that shouldn't be too bad.

The trick with .NET Website projects is that the code files are not normally compiled up front, they are compiled on execution of the respective pages. This presents a challenge where testing is concerned, since as you mentioned NUnit wants to run a .exe or .dll for testing.
One way to deal with the issue is to convert the website project to a web application; they sound similar, but work in different ways. In contrast to a website not requiring up-front compilation, a web application requires it. So you would have one or more projects that compile to assemblies (.dll) or executables (.exe). NUnit could then hook into those to run the tests.
To make this work, you would want to separate testable code into another project; your front-end web application can refer to this other project to make use of the code within. Ideally, the front-end would be a thin layer of logic and user interaction, and the real work can be sent to the second project. Therefore, the second project is what you will want to test.
You'll want to have one more project to contain the tests - general wisdom is to not have your tests in the same project as the code being tested. This project refers to the project being tested, and to NUnit, and contains the tests themselves. This assembly is what you would direct NUnit to run for testing.

First, you want to create a new project for your tests. If you happen to have any internal classes or attributes, you should use InternalsVisibleToAttribute in order to be able to test these from within your testing project, outside your "real" project.
This attribute is suitable for the entire assembly, so I recommend putting it into your Assembly.info file of your "real" assembly.
From within your tests project, add a reference to your "real" assembly.
Make sure to exactly know the path to your binary (assembly.dll);
Open your TestsProjectAssembly.dll from within your NUnit GUI, makeing sure you are browsing to the right folder;
You might also want NUnit GUI to reload your assembly on each tests run (there is an option for doing so in the options properties);
Run your tests.
Absolutely make sure your path or browsable folder is the one in which your testing project is generated.