Good suggestions, thanks. You might want to change the title of this issue to something more meaningful since this repo is for all of the .NET Core documentation. I would do it, but I don't have edit rights in this repository.

Hi Rob, I've just done that now - I hope its not too wordy ? Happy to take a suggestion.

Rather/as well as than using shell commands, which may be confusing to those new to Visual Studio (like myself), I'd recommend including in-GUI ways to do the same thing.

dotnet new -i NUnit3.DotNetNew.Template can be avoided by installing the NUnit VS Packages from the Marketplace within Visual Studio, for example, and adding new solutions and linking references are fairly simple to do from within the Visual Studio UI.

Thanks for your feedback @rstannard. I'm adding this to our backlog. We usually start the topics with the CLI version since it's cross-platform, but indeed topics using VS would also be useful.

/cc @BillWagner

I strongly discourage using VS or Code as long as they are not helpful. I suggest .NET core for Linux and the bash CLI in conjunction with gedit, atom, vim or some other Linux editor available.

@Thraka recommend closing this issue. VS is fine as the editor. This tutorial is consistent with all the rest of the unit testing tutorials.

Unit testing is generally not the onboarding/most beginning tutorial.

@mairaw owns this article so I would let her make the call, but I agree. It will all be rewritten anyhow when these get remade.

@Rick-Anderson yeah but someone who is skilled with VS and familiar with unit testing cant actually follow these instructions and get a working result. at least not without monkeying and web searching a bit. For example I would never think to choose a console application as the project type, but Nunit seems to need that. The doc page even says

You've built a small library and a set of unit tests for that library

Then again I wouldnt bother typing most of the stuff in these "tutorials" when I can hit 3 or 4 keys in a VS shortcut. It may be a GUI but its still only 3 or 4 keys compared to typing "dotnet ".

This issue has been closed as part of the issue backlog grooming process outlined in #22351.

That automated process may have closed some issues that should be addressed. If you think this is one of them, reopen it with a comment explaining why. Tag the @dotnet/docs team for visibility.

@BillWagner @IEvangelist I think this one should be reopened. We really should have parity on these unit test articles for cli, visual studio, visual studio for mac.

Thoughts?

@BillWagner Bill Wagner FTE @IEvangelist David Pine FTE I think this one should be reopened. We really should have parity on these unit test articles for cli, visual studio, visual studio for mac.

Thoughts?

I think that we have consistent and uniform coverage so far. The articles require the SDK and your IDE of choice. I think that is sufficient, otherwise it becomes too repetitive. I believe that is the advantage to using the SDK, it is agnostic to IDE preference. If our instructions did not work, however; on a specific OS or IDE choice then we should fix it. I'm good with this one being closed. @BillWagner thoughts?

Since a bot closed this and a user requested it be reopened, I'll do so now. Note that it may be closed again by a human per #6218 (comment).

@IEvangelist - try following them with VS 2019 and assume you have only used MSFT's flagship unit testing platform before (since it has always been able to meet the need) and that you are not familiar with nunit or xunit.