OK so here we are in Visual Studio and again don't freak out if you don't know Visual Studio
C Sharp.
All of these concepts apply to whatever bindings of web drive what you want to be using or
whatever bindings of any kind of automation tool you want to be using.
These are concepts and ideas for automated software testing not tools specific.
So don't freak out.
Let me quickly give you a little bit of a breakdown of what I did here of the lay out
so you can better follow and then we'll will actually dig into needy greedy of the code.
So what I tried to do was I named my classes in order of staps logical steps that were
going to divide our automation into.
So if you look here in the solution explorer you can see that I divide it into basically
five steps and I'm going to go through each one one by one.
I wouldn't normally name my classes like this but I did so just so that they're perfectly
organized so that you have a easy time of following along with me.
If you're looking at the actual code I'm utilizing and unit here so I'm just creating standard
and unit test classes.
OK.
And then we created our original test and then I copied over our original test.
We just recorded two other times just so that we can per time like we have a test suite.
Not that they're relevant Marge.
But just to have them there for exemplary purposes.
So that's really about it.
That's the organization.
Once we exported out our recording what it produced was a file that looked literally
like this.
I took all of this code right here.
And then I copied it into this method and I called it original recording.
So when I hear you guys can actually see our test take a look at it and ingest it looks
pretty straightforward right just like a normal recording would look.
One thing that you may notice here is I actually put my username and password into environmental
variables of my machine because I don't want to give you guys that username and password
because I don't want to be everybody to be using my test user for my application.
So those are here for me.
If you're utilizing this code you're going to need to supply your own test user and you
can do that by simply just signing up as I showed you before.
So besides that the other thing that you might initially notice is that we have our assertion
here but this assertion actually kind of socks because it's not really an assertion it's
more of a if condition and then if that if condition fails then we're riding out to the
console and that is annoying because if I was to run this overnight or in any kind of
way I wouldn't really have a history of my results.
Rather I'll just have a console outpoured within that console is going to disappear
and after that my tests done.
So the very first thing that we have to do with this test is actually to clean it up
a little bit.
And I just replaced this with a single assertion that does the same thing.
But now this assertion is either going to cause my unit tests to pass or fail I'm going
to have a history and I'm going to have errors that I can look at after I'm done with running
my tests.
And you can see up here that I actually put a war on because I had to take one step on
this automated test in order to be able to fix it immediately after the recording basic
I couldn't really even use this automated test in its original form after the recording
I had to take one initial step to fix it.
And I'm not going to count the user name on the password.
Putting got into environmental variables because technically if you're recording this test
you don't really have to replace that data.
So I'm not counting that stop I'm only counting replacing the assertion.
So now that we replaced our assertion we actually have our test and I'm calling that test test
1 and we're going to follow test 1 through the entire process as it evolves through the
automation testing logic to become better and better.