>> [MUSIC] Hi. I'm Kendra and I want to share with you
a few tips on the Visual Studio test tools,
so let's dive right in.
Here I am in Visual Studio 2022 and
the first tip I want to show is show in Test Explorer.
This is a brand new feature,
so this is available if I just
right-click in any test method and it
pops open the Test Explorer to show
exactly the test that I was just editing and the editor.
It keeps your context very in-sync.
Even if I had all of these collapsed,
I could also do the same thing.
Show a Test Explorer,
I can use Control ES,
that's a keyboard shortcut,
and it'll expand all the parent nodes and everything,
so it makes it really easy to find tests.
This is a lot like sync in active document.
If you've used this in the Solution Explorer,
it'll highlight the file that you
have open in the code editor as well.
Trying to use some consistent tooling across
these is a very highly requested feature,
and we're awfully excited about it.
Oh, one thing I should also call out
is they have to Expand All button now.
Very helpful. We had a Collapse All.
We were limiting it for a little bit because we
are worried for people with hundreds of
thousands of tests spaces,
it would have some performance concerns,
but now we got it in,
and super easy to expand all of your tests.
The next thing I want to show off is test audio cues.
I'll go ahead and run this test,
and you might have heard a subtle little chime
in the background. Let me do that again.
Let's run a failing test this time.
This is a test audio cue that plays at the end of test runs.
We have two sounds. One for if
the test one contained all passing tests,
and another for if there is at least one failing test.
It started as an accessibility feature,
but obviously, it's in,
and now we can all benefit from it whenever we are multitasking,
or we got disconnected,
it'll bring you back.
You kicked off a test run,
and now it's completed and ready for you.
Yes, you can absolutely configure the sounds on these.
Just go to Tools options,
and click "Configure Sounds".
It'll open the Windows 10 dialogue,
and we have a few sound points
already that you can configure for
Visual Studio and these are the two new ones,
and you can have a lot of fun with this.
Any wave file that you want to use,
we can actually support,
so something you can really have a lot of fun with
this if you want to, just a suggestion.
That was test audio cues.
Another thing I want to call out is the Test Explorer also now
captures Console.WriteLine and the test detail summary pane.
That's this pane over here.
We didn't it always capture Console.WriteLine,
but a lot of people would use it for
logs when they're translating code.
All the standard output and standard error captured now,
and we have some really helpful wrapping functions.
If it's ever scrolling off the pane,
or you want to use on fixed-width font
or something like that to compare two lanes, you can unwrap,
and you can wrap it again just to make sure that you see all of
the useful dialogue or messages that you want to see.
We also changed how we truncate output.
We now show a much larger preview
in the pane as well before we decide,
hey, we need to truncate this,
just opened this additional log,
and you can still get all of your logs.
That is log output appearing in the Test Explorer, very useful.
Now one of the major things that I want to talk about.
This is remote testing,
which is very new and Visual Studio 2022.
This is the idea of connecting
your Visual Studio Test Explorer to a remote environment.
It could be a Linux container,
WSL, or even over SSH,
like an entirely separate VM and this
is useful because normally I would have to push to CIT,
get feedback from my Linux tests,
but now I can get it all inside of my inner Dev loop.
Let me show you a little bit of how that works.
This feature is bring your own computer,
so you need to have your own Docker file.
I'll go ahead and build my Docker image,
with my developer power shell.
I'll run a quick Docker build pair,
and I'll take a look at my test.
I have two tests here.
One is running on Linux and one is running on Windows,
and I'm using the SkippableFact attribute.
If my Linux test is on Windows,
I'll skip it depending on what
operating system is and vice versa for Windows.
If my Windows test is trying to execute on Linux,
it'll go ahead and skip that as well.
Now that I have my Docker image built,
I can take a look at what environments I have
about available in my Test Explorer drop-down,
and I'll go ahead and select
the container that I want to connect to.
Now, this is determined
by my test environment thought JSON file up
here that declares all of the connections that
my Test Explorer connect to.
I've container, and it asked for what Docker image I have running
on my machine or what WSL distribution for example,
and my SSH credentials,
and that's how you get all of that setup.
When I select it to run in the Linux container here,
it's going ahead and starting up that container for me,
and it's going to rediscover my tests.
There you go. It started up a container,
and it's now rediscovered my tests.
I'm going to go ahead and rerun these
and now my Windows tests should be
skipped and my Linux test is now passing.
It's bringing that modern
cross-platform development into your inner loop,
and you can debug these on Linux
and get that feedback
from your Linux environments right here in Visual Studio.
Speaking of more modern development,
I also want to talk a little bit about Playwright.
That is the new web UI testing framework
that Microsoft has released.
It's entirely open source.
It is built with asynchronous and cross-platform code in line.
It works with all modern browsers,
and it works for multiple languages including TypeScript,
Python,.NET, and Java.
With any web UI testing technology,
the first question, where is the recorder?
Do we have a recorder?
Yes, we absolutely have a recorder for Playwright.
Let me show you a little bit of what that looks like.
I'll go ahead and launch the Playwright recorder.
This is a cross-platform tool,
so I'm going to use this CLI to
do it from the developer PowerShell,
and it'll go ahead and launch an edge browser for me,
and it'll be blank right now because they didn't
input any web address to go to.
Here on the side, it starts up this Playwright Inspector.
Now, when I navigate anywhere,
let's take a gander at the playwright dox.
It starts logging things as I do them,
and you can see as I'm hovering in my browser,
it's telling me what elements are going to be
called and logging them as they click.
Let's take a look at supported languages.
I can click on.NET,
and it generates all of this for me and I can easily copy out of
here and put it in another test wherever I need to in my code.
Let's take a look at one of those.
You can see it said, hey,
you can start either headlessly or not.
I'm keeping this headless right now,
so I can debug through this with Visual Studio.
It also gave me helpful assert,
so I can actually check what
the expected values are at certain parts when
I was recording it, just super helpful,
so if I go ahead and run this,
since I am running with a head not headlessly,
I'm going to see in the browser actually pop up,
and I could set breakpoints and step through it if I wanted to,
but now it's just going to replay those actions that
I just recorded and the test passed.
Let's see. There we go. The test passed.
That's a little bit of Playwright development that helps bring
your modern apps all into your inner Dev loop.
Thanks so much for taking a look at the Visual Studio test tools.
Take a look at our other videos on Visual Studio 2022.
They're pretty cool. Thanks for watching.