📺 Develpreneur YouTube Episode

Video + transcript

Rest Assured and Karate - Part 1

2022-03-03 •Youtube

Detailed Notes

Our journey into Restful API Testing Using RestAssured begins by looking at the different ways in which API testing can be done. Next, we look at how to use tools such as the browser developer tool, Swagger, and Postman to test APIs from a browser. Additionally, we look at how to use libraries like RestAssued and Karate to build continuous integration tests for our code projects. Finally, we wrap up our discussion by showing you how to write RestAssured tests against a real-world scenario.

Restful API Testing Using RestAssured Overview:

Overview of Restful API Different Types of HTTP Requests How to Manually Test a Restful API Use Postman and Swagger Write RestAssured Unit Test What is Restful API

REST APIs provide a flexible, lightweight way to integrate applications, and have emerged as the most common method for connecting components in microservices architectures.

-IBM

HTTP Requests

Get - Requests a representation of the specified resource. Requests using GET should only retrieve data. Post -Submits an entity to the specified resource, often causing a change in state or side effects on the server. Put - Replaces all current representations of the target resource with the request payload. Delete - Deletes the specified resource. - Mozilla

RestAssured

REST Assured is a Java DSL for simplifying testing of REST-based services built on top of HTTP Builder. It supports POST, GET, PUT, DELETE, OPTIONS, PATCH, and HEAD requests and can be used to validate and verify the response of these requests.

- RestAssured

Start with a real-world example

To explain the principles of API testing we decided to begin with a real-world exercise and build out our test cases to support the following scenario. For instance, a company that wants to set up a Tutorial center at a university to help students study. Initially, they build a WS application that records the subjects that will be covered.

The current interface supports:

Create A Tutorial Retrieve All Tutorials Retrieve A Tutorial By Id Update A Tutorials By Id Find All Published Tutorials Find By Title Containing String Delete A Tutorial Delete All Tutorials

Restful API Testing Using RestAssured

Additional Resources

RestAssured Karate Postman Swagger Finally, this series comes from our mentoring/mastermind classes.  These classes are virtual meetings that focus on how to improve our technical skills and build our businesses.  After all the goals of each member vary.  However, this diversity makes for great discussions and a ton of educational value every time we meet.  We hope you enjoy viewing this series as much as we enjoy creating it.  As always, this may not be all new to you, but we hope it helps you be a better developer.

Transcript Text
[Music]
welcome today we are going to be looking
at restful api testing we're going to be
looking at using tools such as rest
assured karate
we'll be discussing things like swagger
postman
and generally just talking about web
service in general and how we go about
testing them
so the overview of this particular
course this is going to be a three-part
presentation we're going to focus on
restful apis
wrist assured
karate
the api testing tool not the actual
physical act
and we're going to look at a simple
project using both so we'll kind of do a
side-by-side comparison between
the different libraries that are out
there that we're going to test with
so let's start by talking about what is
restful api
and before i go over this let's first go
over that api is an application
programming interface
that is a set of rules that defines how
the application or device can connect to
and communicate with each other
so when we talk about rest apis we're
talking about providing a flexible
lightweight way to integrate our
applications and have emerge as the most
common method for connecting components
in a microservice architecture
now this definition comes from ibm but
typically if you search rest apis or
restful api you come up with some type
of definition similar to this and it's
essentially a way to
communicate between different
applications across the web so it's just
a
kind of a template way for us to
integrate our applications be it mobile
be it web
backend databases to web servers
in our presentation today we're
primarily going to focus on these four
http methods
now there are others and we'll look at
mozilla briefly to go over the full list
but the ones we're going to focus on are
get post put and delete
get is probably the most common http
method and it is used to request a
representation of a specified resource
so this is kind of like where we get
data or fetch data from a web service it
could be a list it could be a record
post is typically used for submitting an
entity to be a specified resource
this is where we actually have kind of
like web forms where we push a bunch of
information up
to the web servers to the application
we can also use put where we actually
replace the current representations of
the target resource with a different
payload and finally we can use delete to
remove a resource from the remote
machine
so today we're going to focus primarily
on rest assured and looking at our test
application that we're going to
integrate with
so rest assured is a java dsl and dsl
stands for domain specific
language and it's used for simplifying
tests of a rest based service built on
top of an http builder
now rest assured supports post get put
delete option patch and head
now there are other types of requests
that we can use but these are typically
the ones that are generally used to
validate and verify the response of the
requests
next we have karate and karate is
another domain specific language
and karate is an open source tool to
combine api test automation
mocks performance testing and ui
automation into a single unified
framework
one of the things about karate is that
it is built on the bdd syntax
of cucumber so it is a gherkins like
framework
and what's nice about it is
it
well it does have a java hook where you
can actually use java to expand upon
your karate test it doesn't necessarily
need java it can use a javascript and
become a kind of an open standard for
even non-programming and we'll look at
that a little bit throughout this course
finally at the end of this series we
will talk about how karate and recitard
kind of compare with one another how
they match up how they stack up
so throughout this entire presentation
we're going to primarily be doing a demo
and this demo is going to be comprised
of an application
so here is a simple overview of what it
is we're going to be looking at
so we have a company that wants to set
up a tutorial center on a university to
help students study
they have started building a web service
application that records the subjects
that will be covered
currently the interface supports
things like post get delete and put
and we're going to define some tests
that test that implementation so we'll
have things like creating a tutorial
retrieving all the tutorials in the
system retrieve a tutorial by id update
a tutorial by ib
find all published tutorials
find a title containing a string
we want to delete a specific tutorial
and then we want to delete all the
tutorials
we'll walk through how to do it through
postman we'll use swagger we'll look at
using rest assured and we'll also look
at doing this with karate
so let's get started
so to start with let's go out to the
mozilla site that i referenced in the
notes
so here we see all the different types
of http request methods that are
available to us from the web so we have
things like get head post put delete
connect options trace and patch
and a brief definition of each
next i provided and slacked the link to
rest assured so rest assured lives out
on github.com
forward slash rest dash assured forward
slash rest dash
assured
now here on the main page you have a
readme which gives you the basic
overviews of what you can do with the
language
and we'll go over this a little more
detail later
i also provide a link to the query labs
slash karate on github
and a link from the karate that kind of
gives a comparison between the two
now the karate and the comparison will
cover over the next two lessons but i
just want to provide them now if you
want to kind of read ahead before we get
to those
all right so the first thing we want to
do is we have to have some type of web
service application
so as we talked about in our slides we
have a test application already built so
i have this demo application here
that is a spring boot application with
some additional components at it so
let's look at the palm file
so it's also a maven project
so i typically use maven for all of my
web applications because it's so easy to
integrate with third-party libraries
so here in our pom file we have a list
of some dependencies now because i'm
using spring sts and i'm using
the spring framework
i can just outright import the spring
libraries that are already provided
within the spring tool suite
so that gives us access to
our spring boot starter
jpa i'm doing in kind of web driven
database here so we're going to load
things into memory we're using
h2 database and i'm using spring boot
starter web
and by doing this i have access to the
library so we can use spring boot
i also included a parent to the spring
boot library artifact which allows me to
import and set the spring boot starter
parent to 2.6.3
by doing this i do not have to specify
the versions down here it will
automatically pull in the dependencies
from this library that i want to use
all right in order to use rest assured
we have to include these libraries here
so we start with the basics i o rest
assured
and we need the rest assured artifact
if we want to use json we need to
include the json path artifact
if you want xml you want to use the xml
path
and finally if you want to do some json
scheme validations you need to include
the json scheme schema validator
so these four dependencies pretty much
wrap up everything that you need for
rest assured
now if we want to include in our project
wagger we also need to include
spring docks
prior to using spring docks you would
have to include the spring fox
swagger components but spring has now
simplified this into spring docks so for
swagger we need to use spring docks
all right so that's our palm file so
these are our dependencies
so now if we go look at the project
itself
we have
our source main java our source test
java
we also have a source main resources
folder
now because this is a spring boot
application we need to put some of our
configuration settings in the
application properties
since i have a database i need to
configure my h2
so that i can enable
the h2 in memory database and i give it
a console path so i can access this if i
want to access it from a database tool
i also need to set my data source my
class name user and password
since we're also going to use jpa to tie
into our database with our entities so
we're going to use jpa show
jpa properties hibernate dialect and
hibernate dll auto
by doing this this will show our sql in
the console down here when we actually
run
or start up spring boot
and finally to configure spider all we
had to do is add these two property
lines we had to set the spring.swagger
ui path
which is going to be api docs and we had
to do springdocs.swagger
operation sorter so how are we going to
sort our
methods
and because i did this it's going to
sort them alphabetically
the project itself is fairly
straightforward
we have our demo application so this is
our spring application so if you're
doing spring boot you just have to have
a spring boot class with main that
essentially starts
the spring application and that will be
what's down here our little spring boot
it essentially starts a tomcat web
service for us
our configuration file here i'm
pre-loading some data within our
database so i just have a command line
being that will add two tutorial records
to our database in memory every time we
restart
i find this is useful for testing
because it gives us a starting point
our web service itself is composed of a
controller
and we have these methods here we have
get all tutorials get tutorials by id
create tutorials update delete delete
all and find buy published ids
just have some basic logic in here
the interesting one is the get
we use our annotations for
our different http requests so we have
get
we have post
we have put
and delete
now this looks ugly and from a tester's
perspective we really don't need to get
into this level but i'm just kind of
walking through how the project's set up
then we have our model which contains
tutorial
and this is just our entity beam
so we define it as entity we set our
table name to tutorials in memory
and we give it an id
our title our description and our
boolean for published
and this is just a regular pojo
so we have all of our getters and
setters
and then finally we set up the
repository
and we define the repository to give it
some additional lookups we have that
find by published which returns a list
and we have find by titles containing
which also returns a list so we can look
up by
the published boolean or we could look
up by title
otherwise we use the straight up
getters and setters within our lookups
so what's interesting here so if we do
extends jpa this gives us that full kind
of crud functionality that we'll see in
our api with the addition of these two
lookups
so we talked about resources
so now let's go down and let's look at
what we have in our test
so for this particular example
since rest assured is a java library for
testing apis i thought it'd be easier to
just drop it right into our spring boot
project here
because it also gives me the ability to
reuse
our
tutorial application for our tutorial
sorry our tutorial entity beam
so here we have just a
typical spring boot test
which is essentially j unit but it's
going to kick off a spring boot instance
to run rj unit test so we can actually
deploy this test suite
as a separate microservice and run it on
a different
system so you can have your api running
on one and then kick off your test on
another we also want to add test method
order this way we can actually tell it
the order that we want to run our test
in
and then we give it the name
now in our slides we
basically stated that we want to test
these eight different components we want
to create a tutorial test
retrieve all tutorials
retrieve a tutorial by id
update
find
and delete
so the first thing we need to do is we
need to create a test
so let's come in here
so in
java
if you're using junit or test nd or most
test frameworks you have a test
annotation so we start with test
now because i want to run these in a
specific order i also can include the
order annotation
and for that it requires a number
essentially a sequential number
so we'll do one
now since we want our first test to be
create a tutorial we'll come down in
here and we'll do void
create a tutorial and let's make it
camel case
to comply with java naming conventions
so right now we have now added an empty
test to create a tutorial lookup
now before we actually continue writing
this out let's take a moment and
actually start the api look at the
console and then look at the api
structure from swagger
so let me restart spring boot
spring starts up tomcat
we initialize our h2 console for h2ui
for our database lookup
we
run our configuration so he we build our
table we be we build the create sequence
hibernate
and then we call and we insert
our tutorials so we've added we've
pre-loaded the tutorials with calculus
and how to introduce testing into the
development cycle
we have our unique ids and we have our
published boolean flag so
the calculus is published my book is not
so we have our description and we're not
published
so now that it's started if we actually
go out
and look at our browser
we can go to
localhost
whatever port we're running on right now
we're using the default
if i put in swagger dash ui
slash
index.html
i get my api for my tutorial
so our demo application has these api
calls
you
Transcript Segments
0.44

[Music]

27.359

welcome today we are going to be looking

29.439

at restful api testing we're going to be

32.399

looking at using tools such as rest

34.48

assured karate

36.399

we'll be discussing things like swagger

38.399

postman

39.68

and generally just talking about web

41.52

service in general and how we go about

43.84

testing them

47.36

so the overview of this particular

49.52

course this is going to be a three-part

51.36

presentation we're going to focus on

53.36

restful apis

55.199

wrist assured

57.44

karate

58.879

the api testing tool not the actual

61.28

physical act

62.64

and we're going to look at a simple

64.559

project using both so we'll kind of do a

66.56

side-by-side comparison between

69.28

the different libraries that are out

70.96

there that we're going to test with

74.88

so let's start by talking about what is

77.04

restful api

79.439

and before i go over this let's first go

82.08

over that api is an application

85.04

programming interface

86.56

that is a set of rules that defines how

88.799

the application or device can connect to

91.28

and communicate with each other

93.92

so when we talk about rest apis we're

96.72

talking about providing a flexible

98.64

lightweight way to integrate our

100.799

applications and have emerge as the most

103.759

common method for connecting components

105.84

in a microservice architecture

108.24

now this definition comes from ibm but

110.479

typically if you search rest apis or

113.119

restful api you come up with some type

115.52

of definition similar to this and it's

117.92

essentially a way to

120.079

communicate between different

122.479

applications across the web so it's just

125.439

a

126.159

kind of a template way for us to

128.959

integrate our applications be it mobile

131.12

be it web

132.48

backend databases to web servers

136.16

in our presentation today we're

137.84

primarily going to focus on these four

140.8

http methods

142.4

now there are others and we'll look at

144.48

mozilla briefly to go over the full list

147.2

but the ones we're going to focus on are

148.879

get post put and delete

152.16

get is probably the most common http

155.12

method and it is used to request a

158.4

representation of a specified resource

161.04

so this is kind of like where we get

162.959

data or fetch data from a web service it

165.599

could be a list it could be a record

168.64

post is typically used for submitting an

171.84

entity to be a specified resource

175.04

this is where we actually have kind of

177.28

like web forms where we push a bunch of

179.519

information up

181.04

to the web servers to the application

184.72

we can also use put where we actually

187.44

replace the current representations of

189.599

the target resource with a different

191.36

payload and finally we can use delete to

194.239

remove a resource from the remote

196.84

machine

198.4

so today we're going to focus primarily

200.4

on rest assured and looking at our test

203.36

application that we're going to

204.56

integrate with

206.08

so rest assured is a java dsl and dsl

210

stands for domain specific

212.48

language and it's used for simplifying

214.799

tests of a rest based service built on

217.76

top of an http builder

220.08

now rest assured supports post get put

223.04

delete option patch and head

225.36

now there are other types of requests

228.159

that we can use but these are typically

229.84

the ones that are generally used to

231.599

validate and verify the response of the

233.439

requests

235.519

next we have karate and karate is

238

another domain specific language

240.72

and karate is an open source tool to

243.2

combine api test automation

246.159

mocks performance testing and ui

248.64

automation into a single unified

250.72

framework

251.92

one of the things about karate is that

254.239

it is built on the bdd syntax

257.919

of cucumber so it is a gherkins like

261.28

framework

262.56

and what's nice about it is

264.96

it

265.759

well it does have a java hook where you

268

can actually use java to expand upon

271.199

your karate test it doesn't necessarily

273.919

need java it can use a javascript and

277.52

become a kind of an open standard for

279.919

even non-programming and we'll look at

281.84

that a little bit throughout this course

285.12

finally at the end of this series we

287.28

will talk about how karate and recitard

290.08

kind of compare with one another how

291.919

they match up how they stack up

295.12

so throughout this entire presentation

297.04

we're going to primarily be doing a demo

299.84

and this demo is going to be comprised

302.16

of an application

303.919

so here is a simple overview of what it

306.4

is we're going to be looking at

308.08

so we have a company that wants to set

310.24

up a tutorial center on a university to

313.039

help students study

314.8

they have started building a web service

316.88

application that records the subjects

318.88

that will be covered

320.8

currently the interface supports

323.12

things like post get delete and put

326.56

and we're going to define some tests

328.72

that test that implementation so we'll

330.8

have things like creating a tutorial

332.88

retrieving all the tutorials in the

334.88

system retrieve a tutorial by id update

338.32

a tutorial by ib

340.16

find all published tutorials

342.32

find a title containing a string

345.36

we want to delete a specific tutorial

348.08

and then we want to delete all the

349.759

tutorials

351.12

we'll walk through how to do it through

352.32

postman we'll use swagger we'll look at

354.96

using rest assured and we'll also look

357.52

at doing this with karate

359.759

so let's get started

361.84

so to start with let's go out to the

363.84

mozilla site that i referenced in the

365.68

notes

366.56

so here we see all the different types

369.28

of http request methods that are

371.759

available to us from the web so we have

374.24

things like get head post put delete

378.24

connect options trace and patch

381.52

and a brief definition of each

384.88

next i provided and slacked the link to

387.84

rest assured so rest assured lives out

390.88

on github.com

392.88

forward slash rest dash assured forward

396.16

slash rest dash

398.319

assured

400.4

now here on the main page you have a

402.88

readme which gives you the basic

404.56

overviews of what you can do with the

406.4

language

408.319

and we'll go over this a little more

409.68

detail later

411.199

i also provide a link to the query labs

414.8

slash karate on github

417.199

and a link from the karate that kind of

419.36

gives a comparison between the two

421.52

now the karate and the comparison will

424.16

cover over the next two lessons but i

426.16

just want to provide them now if you

427.759

want to kind of read ahead before we get

429.28

to those

430.96

all right so the first thing we want to

432.88

do is we have to have some type of web

435.039

service application

437.199

so as we talked about in our slides we

439.919

have a test application already built so

443.12

i have this demo application here

446.16

that is a spring boot application with

450.96

some additional components at it so

453.36

let's look at the palm file

455.12

so it's also a maven project

457.52

so i typically use maven for all of my

460

web applications because it's so easy to

462.08

integrate with third-party libraries

464.639

so here in our pom file we have a list

467.199

of some dependencies now because i'm

469.759

using spring sts and i'm using

472.879

the spring framework

474.8

i can just outright import the spring

477.84

libraries that are already provided

479.759

within the spring tool suite

482.16

so that gives us access to

484.319

our spring boot starter

486.8

jpa i'm doing in kind of web driven

489.919

database here so we're going to load

491.599

things into memory we're using

494.4

h2 database and i'm using spring boot

497.36

starter web

499.12

and by doing this i have access to the

502.479

library so we can use spring boot

505.599

i also included a parent to the spring

508.639

boot library artifact which allows me to

512.56

import and set the spring boot starter

514.88

parent to 2.6.3

517.36

by doing this i do not have to specify

520.08

the versions down here it will

521.519

automatically pull in the dependencies

524.08

from this library that i want to use

526.88

all right in order to use rest assured

529.44

we have to include these libraries here

532.48

so we start with the basics i o rest

535.36

assured

536.56

and we need the rest assured artifact

540

if we want to use json we need to

542

include the json path artifact

544.88

if you want xml you want to use the xml

547.68

path

548.64

and finally if you want to do some json

551.2

scheme validations you need to include

553.44

the json scheme schema validator

557.12

so these four dependencies pretty much

559.92

wrap up everything that you need for

562.72

rest assured

564.72

now if we want to include in our project

567.44

wagger we also need to include

570.48

spring docks

572.48

prior to using spring docks you would

574.56

have to include the spring fox

577.2

swagger components but spring has now

579.68

simplified this into spring docks so for

582.24

swagger we need to use spring docks

585.68

all right so that's our palm file so

587.2

these are our dependencies

589.04

so now if we go look at the project

591.279

itself

592.32

we have

593.6

our source main java our source test

596.16

java

597.12

we also have a source main resources

599.12

folder

600.24

now because this is a spring boot

602.079

application we need to put some of our

604.32

configuration settings in the

605.92

application properties

608.8

since i have a database i need to

610.8

configure my h2

613.44

so that i can enable

615.2

the h2 in memory database and i give it

618.16

a console path so i can access this if i

620.88

want to access it from a database tool

624.24

i also need to set my data source my

626.399

class name user and password

630.56

since we're also going to use jpa to tie

633.36

into our database with our entities so

636.399

we're going to use jpa show

638.88

jpa properties hibernate dialect and

641.36

hibernate dll auto

643.76

by doing this this will show our sql in

647.279

the console down here when we actually

649.279

run

650.16

or start up spring boot

653.12

and finally to configure spider all we

655.44

had to do is add these two property

657.279

lines we had to set the spring.swagger

660.399

ui path

662.16

which is going to be api docs and we had

665.36

to do springdocs.swagger

667.36

operation sorter so how are we going to

670.24

sort our

671.92

methods

672.959

and because i did this it's going to

674.64

sort them alphabetically

676.72

the project itself is fairly

678.64

straightforward

680.24

we have our demo application so this is

682.88

our spring application so if you're

684.88

doing spring boot you just have to have

687.2

a spring boot class with main that

689.68

essentially starts

691.279

the spring application and that will be

693.519

what's down here our little spring boot

696.079

it essentially starts a tomcat web

698.24

service for us

700.24

our configuration file here i'm

702.399

pre-loading some data within our

704.56

database so i just have a command line

707.519

being that will add two tutorial records

710.959

to our database in memory every time we

713.12

restart

715.6

i find this is useful for testing

717.279

because it gives us a starting point

721.36

our web service itself is composed of a

724.639

controller

726.24

and we have these methods here we have

729.279

get all tutorials get tutorials by id

732.399

create tutorials update delete delete

735.12

all and find buy published ids

738.079

just have some basic logic in here

740.72

the interesting one is the get

743.68

we use our annotations for

746

our different http requests so we have

748.639

get

749.6

we have post

751.12

we have put

752.639

and delete

754.079

now this looks ugly and from a tester's

756.48

perspective we really don't need to get

758.48

into this level but i'm just kind of

760

walking through how the project's set up

762.72

then we have our model which contains

764.72

tutorial

766.079

and this is just our entity beam

768.8

so we define it as entity we set our

771.279

table name to tutorials in memory

774.16

and we give it an id

776.079

our title our description and our

779.04

boolean for published

781.92

and this is just a regular pojo

784.88

so we have all of our getters and

786.32

setters

788.48

and then finally we set up the

789.839

repository

791.44

and we define the repository to give it

793.76

some additional lookups we have that

795.6

find by published which returns a list

798.079

and we have find by titles containing

800.72

which also returns a list so we can look

803.2

up by

804.32

the published boolean or we could look

806.48

up by title

808.32

otherwise we use the straight up

811.2

getters and setters within our lookups

815.04

so what's interesting here so if we do

817.12

extends jpa this gives us that full kind

819.6

of crud functionality that we'll see in

821.6

our api with the addition of these two

824.72

lookups

826.8

so we talked about resources

829.92

so now let's go down and let's look at

833.199

what we have in our test

836.079

so for this particular example

838.72

since rest assured is a java library for

842.24

testing apis i thought it'd be easier to

844.959

just drop it right into our spring boot

847.44

project here

848.959

because it also gives me the ability to

851.76

reuse

853.199

our

854

tutorial application for our tutorial

856.88

sorry our tutorial entity beam

859.76

so here we have just a

862.639

typical spring boot test

865.12

which is essentially j unit but it's

867.68

going to kick off a spring boot instance

870.72

to run rj unit test so we can actually

873.04

deploy this test suite

875.279

as a separate microservice and run it on

877.839

a different

879.04

system so you can have your api running

880.88

on one and then kick off your test on

882.959

another we also want to add test method

887.04

order this way we can actually tell it

889.279

the order that we want to run our test

891.12

in

891.92

and then we give it the name

894.24

now in our slides we

896.72

basically stated that we want to test

899.199

these eight different components we want

901.92

to create a tutorial test

904.32

retrieve all tutorials

906.639

retrieve a tutorial by id

908.88

update

909.92

find

910.959

and delete

912.959

so the first thing we need to do is we

915.199

need to create a test

917.199

so let's come in here

918.88

so in

920.639

java

921.76

if you're using junit or test nd or most

925.199

test frameworks you have a test

928.24

annotation so we start with test

932.639

now because i want to run these in a

935.12

specific order i also can include the

938.56

order annotation

940.72

and for that it requires a number

944.399

essentially a sequential number

946.399

so we'll do one

948.88

now since we want our first test to be

951.36

create a tutorial we'll come down in

953.92

here and we'll do void

957.519

create a tutorial and let's make it

960.079

camel case

961.6

to comply with java naming conventions

964.72

so right now we have now added an empty

967.199

test to create a tutorial lookup

972.24

now before we actually continue writing

974.079

this out let's take a moment and

975.759

actually start the api look at the

978.639

console and then look at the api

981.12

structure from swagger

982.959

so let me restart spring boot

986.959

spring starts up tomcat

989.44

we initialize our h2 console for h2ui

992.8

for our database lookup

995.36

we

996.399

run our configuration so he we build our

999.68

table we be we build the create sequence

1002.72

hibernate

1004

and then we call and we insert

1007.36

our tutorials so we've added we've

1009.839

pre-loaded the tutorials with calculus

1012.48

and how to introduce testing into the

1015.04

development cycle

1016.72

we have our unique ids and we have our

1019.199

published boolean flag so

1021.6

the calculus is published my book is not

1025.12

so we have our description and we're not

1027.039

published

1028.559

so now that it's started if we actually

1030.72

go out

1032.559

and look at our browser

1035.039

we can go to

1036.839

localhost

1038.48

whatever port we're running on right now

1040

we're using the default

1041.679

if i put in swagger dash ui

1045.36

slash

1046.28

index.html

1048

i get my api for my tutorial

1051.76

so our demo application has these api

1054.96

calls

1070.559

you