Another layer of testing that we might consider adding to our pipeline, our API tests, API testing
is a type of testing that ensures that the API exposed by an application is working properly.
Our application exposes this API.
It can see here, for example, and point cars will give back this information in an adjacent format
with the list of cars and also provides other endpoints to add a car, to get a single car, to delete
a car, toaster to get some statistic information and so on at the high level.
This is the functionality that this application provides doesn't have a graphical interface.
It only provides this API from a testing point of view.
We need to make sure that API is actually working properly.
Otherwise, we are not sure if the application works or not, because just based on the unit test,
for example, we cannot tell if the application actually works, if these endpoints provide this information,
since we have used Bowsman in order to interact with API, can also use Posman to write some very,
very simple API tests.
And even if you are not familiar with Posman, I'm sure you'll be able to follow along.
You will get the collection with all the tests as a resource from this lecture and you can look at it
and play around with it.
But let me show you a very simple example with a test.
In this case, I'm getting all the cars and the fundamental thing that we can test in this situation
is if the status was 200, for example, if I'm just calling something like a car, I'll get a 404 not
found because this page is doesn't exist.
This API address and point doesn't exist for the cars.
I'm getting at 200.
OK, I'm going here to the test.
Deb, we can look at existing snippets that you can open from the right side here in case they are not
opened and we can test for something like status is 200.
What is does is it's this piece of code here, which is actually a test, very simple test.
This will ensure that the status code is 200.
Guess you want to learn more about API testing with Bowsman, all attach a resource to a video which
introduces you to both men and API testing overall.
What is an API and how to get started?
But not to keep this section as short and as focused as possible, just going to go into the absolute
basics.
We just kind of focus on the fundamentals and not go into many details.
I'm going to save the tests and what I can do then is to go over this collection that I have here and
to export it.
Now to select the latest version that is available and hit export.
Navigated a project path and saved the collection inside the folder of the project.
If you go back to intelligence, you'll be able to see here the Cars API Postmen Collection may also
decide to create another folder within the project and to store their multiple collections or however
you decide to organize your code.
In order to actually execute the tests that are in the collection, we need to use the CIA to implement
itself, does not have a CLIA tool, so we need to use a companion tool that comes from the postmen
project.
It's called Newman.
And you can use Newman from UCLA.
Now, I already have a Docker image that has new one installed so we can just jump and use that Docker
image without worrying too much about it.
But just for you to know what is Neumont and what's the relationship with oarsmen?
So let's go ahead and add the stage of API test.
Now, the idea would be to test an application that has already been deployed to a server in this case,
the only server that we have is actually the production server.
This kind of test will not warn us in advance.
If there's something wrong with our application, it will warn us when it is a bit too late.
But it still important sometimes to have post deployment tests just to ensure that the application is
working properly.
And because we do not have any environment in between.
We do not have a testing or a preproduction environment.
We're going to run this test after a production server has been deployed.
But ideally we would run such tests before we deploy to production on a different environment.
With that being said, let's add another stage.
I'm going to call the state police deployment.
For the play that we know that this happens after the deploy and then we can end a new job, API testing.
These will be passed by.
And we're going to use an image that has been created by me and it also contains some additional reports
that are very useful when using human and Posman death.
This is why the name is the Dasbach.
Slash Newman additionally going to specify an empty entry point.
When it comes to the script itself, that's quite easy to execute, the first idea would be to always
run Newman.
There's desperation and what this will do, it will print in the console.
What is the current version of Newman?
This observation is valid for any tools that we use.
It's always a good idea to put in the console the version that we are using, not necessarily because
it provides value right now, just in case all of the sudden something stops working.
It would know exactly which version has been used because in this case we have not specified a fixed
version of this Docker image.
And you can see that we haven't done that for any of the images that we have used, which means that
if the auteur or if the image itself changes the version of the tools that you are using from a pipeline
to the other also change.
Typically, this will not cause any issues because most of the time these tools are pretty stable and
there are no major changes just in case something changes, you at least would be able to tell.
Nothing is wrong with my pipeline itself or with the test that I'm running.
There's something that has changed in the tool so makes it easier to compare the previous pipeline that
worked used human conversion, I don't know, let's say six.
And now in your pipeline uses Newman in version seven, which is obviously a difference.
It's called to the Newman GitHub repository.
And check if there are any issues or anybody else having the same problem.
The next step is quite easy.
Going to simply use the Newman run.
And then we have to specify the name of the collection because it contains a space.
It is always a good idea to put it between double quotes so that it's clear which is the path to this
collection and nothing comes in between or somehow generates any errors as it stands currently.
It will not work because we have used two different things in Posman.
We have used the collection itself, but we have also used environments and we need to specify here
the environment.
Otherwise that will not work.
So going back to Bowsman, I'm going to click here on Manege Environments.
And as I did with a collection, I can export to the environment as well as a file.
So I'm going to export the production environment this time.
And just as previously, I'm going to put it in the root of the project.
And it's always a good idea to just copy the name because we're going to use it right away.
Now, in this Seelie command, we are also going to specify the environment that will be dishdasha,
environment.
And then the environment name not using double quotes, because there are no spaces here, so there's
no chance of something going wrong.
Finally, I'm going to specify to reporters.
And this will be Thalys and the second report there is extra.
The CNN reporter will ensure that if you look at the console from this job, everything will be written
down there as well during the e-mail extra report will generate, well, an example, a report that
can help us understand what's going on with a request.
So because we are generating an excellent report, we're going to add an additional parameter and we
misconfiguration, we are going to tell where to export this fire and we want to put it inside the Neumann
folder.
In the name of the report should be report that e-mail.
An additional reporter that we will use is also Janet.
For Jean, again, we're going to specify a path where this report should be saved would be pretty similar
to what we have used for the human report just with a different file extension.
The report would be instead of simply sent out.
Finally, we need to tell Gittel as well about this reports that we have generated here.
And the way this works is pretty similar to what we have used before thought.
And you've a copy from unit test the artifacts and quickly adapted.
The rule will stay the same, we always generate this artifact and save them.
It will be inside the Neumann folder, so there's nothing else that we need to add to there.
And additionally, we are generating this GAO unit report and we know the path to the report.
This will be quite easy.
So this will be Newman's last report that them out.
It seems that we have everything in place for API testing on the production system that saves this configuration.
Run the pipeline and see how everything looks like.
Now, the pipeline includes an additional stage post deployment and also API testing that is done on
the server because we have specified the J unit report format that has been picked up by catalepsy.
You can see to here under test.
And now apart from unit tests, we also have API testing.
You will see here.
That's only one test that we have because we have only generated one test.
But this still shows up here and can be scaled without any issues.
Additionally, going back to the pipeline, we can see the API testing and we also have the CLIA report
here where we see that there was one assertion, this is a test that we have written.
It was successful.
Nothing has failed.
All the request work without any issues.
And this is the command that we have executed.
This is the Newman version.
Everything works fine from this point of view.
Additionally, what we can do is to look at the job artifacts here.
We will be able to find each team and report as well.
And this is how the report looks like, it contains a lot of information regarding what has been executed,
what are the total request?
It's a very nice report to have saved in the run of the pipeline.