We just saw all of our tests get executed whenever we create this new request.
Now, one has tried to add in an additional commit to this bold request.
And in this additional comment, we're going to make a breaking change to one of our tests.
Again, this is just so you can see what would happen if we make a change that's going to break our
test.
And I would be assigned to us that we should probably fix up our code before we merged into the master
branch.
The back inside my editor.
I'm going to find the roots directory inside the old service.
I'll find the test folder inside there.
I'll open up the current user test file.
And I'm going to make a change to this test to forcibly break it.
In particular, I'll change the expectation right here from 200 to 400.
That should definitely cause my test suite to fail.
I'm gonna save that and we're going to imagine that maybe along with this failing test, we also wrote
out some other code inside of our project that we would want you would eventually deploy.
So we would want to go again.
Go through this kind of process right here.
We're going to commit our changes to that same branch.
Well, then push that up to get home, because we have already prete created a plot request for this
branch.
We do not have to create a pull request a second time instead because we are making these changes to
the same branch.
They will be added in it as additional changes to the pilot cost.
We had just created.
They will go back over to my terminal.
We'll do a get status.
There's the test change I just made.
Go at it, admit it, and I'll call us about last minute change.
And I'll push it up to the same branch.
The dead branch.
Well, do I get push origin?
Deb?
All right.
Once we push that, we should be able to go back or to get up and take a look at that play request.
So there's the last minute change.
And after a moment or two, I should see this little box down here.
Update and say that it's running an additional set of tests.
The tests that are now being executed include that latest change.
And so we should have a test inside there that is going to fail.
I can once again click on details and take a look at the running tests so I can expand that little bullet
point right here.
If you'll let me know, it's not going to let me.
Well, there we go.
OK.
So are installing dependencies once again, we're going to run the tests in this case.
They should fail horribly.
So I'm going to let it do a thing for a moment here.
It looks like a test we just started up.
There's are a couple of passes and eventually we get that failure because our test failed.
Now this over all little workflow right here should have failed as well.
So if I now go back over to my conversation tab.
I'll be told that some of our checks are in this case.
All of our checks have failed.
And so we can't technically merge our code into master, but GitHub is going to as strongly discourage
you to do so, can say, hey, look, you are trying to run some tests here.
It is clear that there is something wrong inside of your code base right now.
And it's kind of encouraging us to fix up our code base before we merge these changes into master.
I bet you guess I would do that.
We just go into our code base, make the fixes, make sure our test pass locally and they eventually
commit those changes and push them back up to the same PR and do that right now.
We're going to essentially undo the change we just made.
Back over inside my editor, I'll find that current user test file and I'll change that response right
there back over to 200.
Once I've got that updated, I'm then going to run my tests locally just to make sure that that actually
fixed it up because this is what you really would do in the real world.
We'll change into off, then do an NPM run test.
Ohlin S.I.
I'm running the S.I. script because I really just want to run the tests one time and immediately exit
as opposed to start at my test and I kind of watch our mode.
It looks like everything is now passing.
Now we can commit that change and push it back up to get Hub once again.
So I'll add that change.
I'll give a commit message of something like fixed nest.
We should probably provide a better description than that.
I'll leave that up to you.
And push that to origin.
Deb.
Now, once again, after that change has been made.
I smell a flip back over.
We're going to either see another test run right here.
Yep, looks like there it starts.
And once again, we're going to have to wait for these tests to be completed.
So I bet you can guess what's going to happen now.
Those tests are going to run in about 30 seconds or so.
We're going to see a little green checkmark that says, hey, everything looks good.
You can merge these changes into the master branch.
All right.
So that is pretty much it.
That is kind of step number one in this entire workflow.
Again, it's going to go something like this diagram right here.
Remember, this diagram is really all about the first time that you create a particular branch or really
a particular pull request after you create that pull request.
You do not have to create a pull request again.
You can continue.
Making changes on the same branch, pushing them up to get hub every time you push those changes to
that same branch.
The tests are going to rerun and update people request.
It's only when you merge that pull request or otherwise close it, you're going to have to create a
pull request again at some point in the future.
All right.
So at this point, we have successfully shown that we can run tests around our suite whenever we push
up code and we can get some output from those tests visible on our play request itself.
Now we're going to expand the GitHub action we put together.
We're going to make sure that we run tests from all of our different services, not just the service.
So quick pause right here.
And we're going to expand that little script in just a moment.