00:00:17.760
hi railscomp uh today we're going to be
00:00:20.400
talking about testing your services
00:00:22.960
but before we get into that i want to
00:00:24.480
introduce myself
00:00:26.240
my name's neil i'm originally from iowa
00:00:29.039
so i feel at home here in the midwest
00:00:32.160
now i live in california in la
00:00:33.920
specifically and i'm a software
00:00:36.000
developer and independent consultant who
00:00:38.320
does rails javascript html css basically
00:00:42.399
if you name an acronym i probably coded
00:00:44.320
in it at some point
00:00:46.480
so
00:00:47.360
today's talk is going to be the what the
00:00:49.840
why and the how of testing your services
00:00:54.559
this is not a talk about building
00:00:56.559
testable services i could do an entire
00:00:58.719
talk about that on its own
00:01:01.440
it's also not necessarily a talk about
00:01:03.920
test driven development
00:01:05.840
while i'm a practitioner i don't think
00:01:08.080
that the principles applied here
00:01:10.320
correspond directly to test driven or
00:01:12.720
not test driven development
00:01:16.720
so
00:01:19.280
got that one good uh
00:01:21.439
so first we're gonna talk about the what
00:01:23.520
so we have to ask ourselves what is a
00:01:25.200
service so i break it down into two main
00:01:27.840
categories first of all we have external
00:01:30.320
services like the twitter api
00:01:33.200
facebook's api or amazon web services
00:01:37.280
and the other category is internal
00:01:39.680
software oriented architecture a
00:01:41.680
buzzword we all know and love
00:01:44.399
so
00:01:45.439
basically for the purpose of this talk
00:01:47.520
it means anytime you're making an http
00:01:51.439
request to an endpoint in another
00:01:54.079
repository
00:01:55.520
so basically any network request you're
00:01:57.520
making outside of your application
00:02:00.960
so now we're going to talk about why
00:02:03.600
because we need some justification
00:02:05.360
before we go ahead and test all of our
00:02:07.360
services without question
00:02:10.080
so first we have to ask ourselves why
00:02:11.840
are services themselves important i
00:02:13.599
think a lot of these are pretty
00:02:14.640
self-evident it allows us to build
00:02:17.280
things faster it allows us to scale more
00:02:19.440
easily
00:02:20.640
and we use them on basically every
00:02:22.800
application i don't think i can
00:02:24.800
personally think of an app i've built in
00:02:27.360
the past few years that hasn't glued on
00:02:29.520
multiple services and i'm also noticing
00:02:32.160
that we're using more and more services
00:02:34.239
for every application
00:02:37.360
so i would argue that services are
00:02:39.200
critical to modern rails development
00:02:42.160
so we have to ask ourselves then why is
00:02:44.080
testing those services important
00:02:46.480
well first of all you should be testing
00:02:48.239
everything else so why would it be
00:02:50.319
different for services
00:02:52.239
and services often compose critical
00:02:54.400
features of your application for example
00:02:56.720
a stripe integration if your billing's
00:02:59.040
down you're going to have a lot of
00:03:00.159
issues
00:03:02.159
you know if you have an api request to
00:03:05.040
s3 you're not going to be able to serve
00:03:06.560
images if that's down and you might also
00:03:09.440
encounter problems with these apis i
00:03:11.440
know i sure have
00:03:12.879
uh
00:03:13.680
basically anytime i've worked with an
00:03:15.360
api there's been some unexpected results
00:03:18.319
so the first example i'm going to take
00:03:20.000
you through is
00:03:21.760
you know an internal api built by
00:03:23.840
consultants in another part of the
00:03:25.280
company so this is the software oriented
00:03:27.760
architecture we're talking about
00:03:29.760
and they were exposing this api for our
00:03:32.080
rails app to consume
00:03:34.000
and but we had issues all along the way
00:03:36.560
and it served to
00:03:38.400
increase the project length
00:03:39.680
significantly sometimes we'd have random
00:03:42.159
null responses when we're supposed to
00:03:43.840
get objects there was random
00:03:45.720
inconsistencies where we'd get weird
00:03:48.159
symbols being printed out and
00:03:50.799
different formatting and in general is a
00:03:52.799
catastrophe
00:03:54.560
so it definitely lengthened the time to
00:03:56.319
completion and this was a lot due to a
00:03:59.760
failure on our part to you know test the
00:04:02.319
api thoroughly so we couldn't express to
00:04:05.040
them you know the problems we were
00:04:06.239
having until we put it into production
00:04:08.560
so this is one problem that could have
00:04:10.239
been solved by testing first
00:04:14.239
now we're going to talk about a few
00:04:15.599
problems i've had with external apis and
00:04:17.600
i'm sure all of you
00:04:19.120
have encountered similar issues with
00:04:21.199
apis in the past
00:04:22.960
uh so do we have any nhl fans in in the
00:04:25.600
house here
00:04:26.639
yeah chicago blackhawks doing pretty
00:04:28.720
well in the playoffs so far
00:04:30.639
we'll see how they go i mean obviously
00:04:32.479
they're going to get crushed by the
00:04:33.600
kings in a few rounds here are the
00:04:35.520
sharks possibly
00:04:37.199
but we'll see i don't want to start a
00:04:38.880
sports rivalry today
00:04:41.120
so you know this basically ranged from
00:04:44.400
small annoyances to
00:04:46.400
you know
00:04:47.360
major issues with this api so we'd have
00:04:49.840
annoyances like this where some
00:04:51.919
responses would come back with an id for
00:04:54.560
the team and others would come back with
00:04:56.080
a code and in this case both of them
00:04:58.080
refer to anaheim so this is a minor
00:05:00.160
annoyance you can code around that
00:05:02.160
here we have
00:05:03.680
an undocumented bug where basically the
00:05:06.080
goals were all supposed to be as a part
00:05:07.840
of an array but if you only had one goal
00:05:10.080
it would be an object and sadly we
00:05:11.840
discovered this one in production
00:05:14.000
during a game so that wasn't ideal
00:05:17.440
but
00:05:18.400
worst of all after we had gone through
00:05:21.360
all of the trouble of fixing these we
00:05:23.680
realize that there is no versioning on
00:05:25.520
this api so
00:05:27.039
even if we fixed it we might be fixing
00:05:30.240
it again a week later
00:05:33.919
so this is basically what it felt like
00:05:36.160
to work with their api
00:05:39.440
so another project i worked on this is
00:05:41.440
just kind of a fun side project was a
00:05:43.600
snapchat api client
00:05:45.600
so i could uh you know work with the
00:05:47.600
snapchat private api
00:05:49.840
and while
00:05:51.120
one of these examples is extreme
00:05:53.680
in that there was haphazard
00:05:55.039
documentation or no documentation in
00:05:57.759
this case i think we've all worked with
00:05:59.759
apis that have
00:06:01.280
improper documentation
00:06:03.360
and but in this case we didn't even know
00:06:05.120
what the requests were so we had to
00:06:06.479
figure that out there's also bizarre
00:06:08.560
obfuscation
00:06:10.000
implanted inside of the app itself
00:06:12.400
that basically encrypted
00:06:14.400
on their iphone so people like me
00:06:16.479
couldn't go in and build things like
00:06:19.199
this and there's a github link if you're
00:06:21.360
curious
00:06:22.639
so now that we've talked a little bit
00:06:25.280
about why it's important and outlined
00:06:27.120
some of the problems you might encounter
00:06:29.600
we're going to talk about how you're
00:06:31.360
actually going to test these
00:06:36.000
so first we need to ask ourselves what
00:06:38.080
is different about services
00:06:40.639
than regular code that we're testing
00:06:43.280
well first of all
00:06:44.800
we have external network requests that
00:06:47.280
are being made
00:06:48.720
and second of all you don't own the code
00:06:50.880
so you can't really do unit testing on
00:06:52.960
it it all has to be done from an
00:06:54.639
integration test perspective
00:06:58.000
so what i propose for your tests in
00:07:00.639
general
00:07:01.680
is that you turn airplane mode on
00:07:04.960
this i find is the best way to think
00:07:07.440
about your test because first of all
00:07:09.759
failure is really bad in testing
00:07:12.800
and you shouldn't be making any network
00:07:14.960
requests
00:07:16.560
so i think of this kind of in two ways
00:07:18.880
first of all so it's airplane mode in
00:07:20.800
the test mode so you can't do these
00:07:22.560
things but also it should be a test that
00:07:24.479
you can run on an airplane
00:07:26.800
basically meaning that if you're you
00:07:28.639
know on a long transatlantic flight or
00:07:31.039
in the railsconf lobby you can still
00:07:32.960
make your tests
00:07:35.680
and
00:07:37.039
and they won't fail because of network
00:07:39.599
issues
00:07:42.000
so this means you should not interact
00:07:44.319
with your services
00:07:46.080
from your testing environment
00:07:48.400
and we have a few caveats which i'll get
00:07:50.479
into now
00:07:51.840
so this includes dummy apis so there's
00:07:55.440
some api makers that have their real api
00:07:58.479
and then they have a fake api which you
00:08:00.560
can hit with requests but it doesn't
00:08:02.800
make any changes to your data
00:08:05.520
so you can't hit those because those are
00:08:07.360
somewhere else on the network
00:08:10.160
but i do allow you to make pre-recorded
00:08:13.280
responses to those endpoints and that
00:08:16.160
means you can record them within your
00:08:17.680
test suite which we'll get into in a bit
00:08:19.759
more detail later
00:08:22.800
so for these examples i'm going to be
00:08:24.800
assuming that you're using rails
00:08:26.720
obviously
00:08:28.319
and that you're using r spec for
00:08:30.319
simplicity's sake
00:08:33.760
so it's time to stub out these requests
00:08:36.880
so
00:08:37.839
when you're stubbing an object
00:08:39.680
you're basically for those who don't
00:08:41.360
know it's basically putting like a fake
00:08:43.599
object in front of that object so you're
00:08:46.160
hitting that object instead of hitting
00:08:47.760
the real one and you know saving time
00:08:49.839
with like setup processes and stuff like
00:08:52.240
that
00:08:53.200
and we're doing a similar thing when
00:08:54.959
you're stubbing a request to an endpoint
00:08:57.120
except we're saving a lot more time when
00:08:59.200
we're doing so because we don't have to
00:09:00.800
make that additional network request
00:09:04.240
so there's some libraries that include
00:09:06.399
built-in stubbing so type phoeus if i
00:09:09.440
pronounce that correctly faraday and
00:09:11.920
x-con are three examples of pretty
00:09:14.880
widely used http libraries built on top
00:09:18.000
of net http i think
00:09:20.480
that have built-in stubbing
00:09:22.480
functionality
00:09:23.760
but we can simplify this a little bit
00:09:26.240
and use something called webmock which
00:09:28.640
i'm sure many of you have worked with in
00:09:30.240
the past
00:09:31.360
which is a general purpose stubbing
00:09:33.680
library for your test suite so you don't
00:09:36.160
have to learn each
00:09:38.000
individual library's
00:09:39.839
stubbing methods
00:09:42.480
so we'll take you through a quick
00:09:43.920
example here's a basic spec helper
00:09:46.880
nothing really interesting about this
00:09:48.480
except you have to include disable net
00:09:51.279
connect at the bottom the rest is
00:09:52.880
boilerplate so i've highlighted that
00:09:55.360
and obviously uh with all these examples
00:09:58.000
you should be putting the gem in your
00:09:59.600
gem file and bundle installing before
00:10:02.800
you start
00:10:04.640
so when you put this in your code for
00:10:06.880
the first time you'll get a really great
00:10:09.120
error with this and i really like
00:10:10.720
getting these errors because it tells me
00:10:12.640
exactly in my code where i'm making
00:10:14.800
network requests so if you're not
00:10:16.560
already doing uh airplane mode tests
00:10:20.079
you should just plug
00:10:22.000
this disable net connect in and then
00:10:23.920
you'll get this error which will tell
00:10:25.920
you where you're making these network
00:10:27.600
requests
00:10:28.720
and it also is really handy and it gives
00:10:31.200
you actually the request you're making
00:10:32.800
at the bottom so you can copy and paste
00:10:34.959
that into
00:10:36.480
your test in order to stub it
00:10:38.959
automatically and obviously you'll have
00:10:40.959
to collect the body and the headers
00:10:42.720
yourself if you need to use those as
00:10:44.880
well
00:10:48.320
so for the following examples we're
00:10:50.480
going to use probably the most face
00:10:53.040
sorry most simple facebook wrapper ever
00:10:56.000
invented basically all we're doing here
00:10:58.880
is sending a get request to
00:11:02.399
facebook graph the public api for a user
00:11:06.000
and what this does is it just returns
00:11:07.680
like very basic facebook information
00:11:10.079
about you it has your facebook username
00:11:13.120
your name and an id and a few other
00:11:15.519
fields
00:11:16.800
and then what we're doing with user id
00:11:18.720
up at the top
00:11:20.320
is we are just pulling out the value
00:11:23.839
for key id so this
00:11:26.079
all it does is return your facebook id
00:11:29.680
super super simple
00:11:32.399
and make sure since we're putting in a
00:11:34.160
lib that you required at some point and
00:11:36.320
you're loading
00:11:38.079
so now we're going to look at a test for
00:11:40.720
this
00:11:41.519
so this is a test where we're not making
00:11:43.279
a network request but we're stubbing it
00:11:45.279
out with webmock
00:11:46.959
so at the bottom you can see we're doing
00:11:50.000
our testing case and we're setting up an
00:11:53.519
expectation that our user id is equal to
00:11:57.120
arjun's user id and i'm using arjun
00:12:00.079
because he was the maker of the facebook
00:12:01.760
graph api wrapper
00:12:03.680
and you can see now above we are
00:12:06.639
stubbing the request just like you'd
00:12:08.720
stub an object we're setting the method
00:12:10.880
of the http request and then we're send
00:12:13.920
putting the link
00:12:15.440
as the second argument
00:12:19.440
next we have to set up what it returns
00:12:22.800
and this is just an http response that
00:12:25.920
we're returning so we want to put a
00:12:27.760
status
00:12:28.800
you can set headers which i generally
00:12:31.120
don't do
00:12:32.160
but if you're doing any operations with
00:12:34.480
the headers you should definitely set up
00:12:37.839
these in your responses
00:12:40.639
and the body we have a really simple
00:12:42.880
json string i've cut out a few fields
00:12:45.360
for brevity but you can see it has an id
00:12:48.399
a first name and a username
00:12:51.600
so this test will pass
00:12:53.519
and we're also making no net reque work
00:12:55.920
requests so
00:12:57.519
the reasons it's better is it first of
00:12:59.839
all it's faster
00:13:01.200
and we also aren't getting this
00:13:02.720
intermittent failure that we were
00:13:04.079
talking about earlier from the network
00:13:06.800
requests
00:13:10.000
so
00:13:10.720
that's a good general way but there's
00:13:12.639
ways we can also save time with this so
00:13:14.959
a lot of the really popular libraries
00:13:17.839
for api wrappers also include mock
00:13:20.720
services within themselves or as an
00:13:23.760
additional library on the side and they
00:13:25.920
use that for you know internal testing
00:13:28.320
with their gems so i recommend if if you
00:13:31.279
can find one to use this before you go
00:13:33.519
and use webmock because it'll save you a
00:13:35.279
lot of time
00:13:36.399
we'll take you through a quick example
00:13:38.240
so we're going to use facebook graph
00:13:40.320
mock here
00:13:43.760
and all we are doing is putting it into
00:13:46.959
spec helper we're just including the
00:13:48.880
methods and requiring it pretty
00:13:51.040
straightforward
00:13:52.639
and now we're going to look at a
00:13:55.680
spec so
00:13:57.600
basically all we're doing is we're
00:13:59.440
wrapping the test case within a
00:14:03.360
wrapper that mocks out the request so
00:14:05.360
basically all this one's doing is saying
00:14:07.760
we're sending a get request to
00:14:10.079
facebook graph backslash arjun
00:14:13.040
and then the third argument in this case
00:14:14.959
is users arjun public which is
00:14:18.320
where the json file of this response is
00:14:21.279
located in the gem
00:14:23.440
so you can also specify your own
00:14:25.920
responses and i'd recommend you do that
00:14:28.560
because i found actually some issues
00:14:30.160
with the facebook graph mock
00:14:32.399
uh
00:14:33.279
mocking like responses have some
00:14:36.399
outdatedness in them
00:14:38.160
so
00:14:39.760
but this you know example i'm not going
00:14:41.839
to take you through all of the gems that
00:14:43.199
have this but this can go to show that
00:14:46.000
there are some benefits that you get
00:14:48.000
from using this it's already stubbed for
00:14:50.480
you you don't have to learn the api
00:14:52.959
endpoints in order to use it
00:14:55.120
and some of these provide pre-recorded
00:14:57.680
responses for your use so you don't have
00:14:59.760
to go out and collect these so it's just
00:15:02.720
a good way of saving time if you're
00:15:04.160
using some popular libraries
00:15:07.839
next i'm going to take you through
00:15:09.600
shamrack which is one of my more
00:15:12.800
favorite ways of doing this i kind of
00:15:15.199
find this to be a fun way basically what
00:15:17.279
shamrock does sorry shamrack does
00:15:20.480
is it allows you to mount rack based
00:15:22.639
apps which include rails and sinatra and
00:15:26.240
others
00:15:27.680
and it allows you to make requests
00:15:30.000
against these
00:15:31.360
fake
00:15:32.560
apps
00:15:34.160
so
00:15:34.880
in this case we're going to get a little
00:15:36.639
help from sinatra
00:15:38.320
in order to stub out these endpoints
00:15:42.880
so
00:15:43.680
spec helper the only thing interesting
00:15:45.360
is that we leave in webmock pretty
00:15:47.680
boring there
00:15:49.839
but then we get to our fake so i usually
00:15:52.959
just put this in spec support and then
00:15:55.440
fake whatever it is in this case fake
00:15:57.839
facebook and this just means it'll be
00:16:00.240
loaded when you run your specs
00:16:02.720
automatically
00:16:04.480
but it won't be obviously loaded into
00:16:06.160
your production or staging environments
00:16:08.079
or development
00:16:09.600
so in this case at the top we can see
00:16:12.320
we're calling shamrack and we're setting
00:16:14.079
up the endpoint which we're hitting
00:16:16.000
against which in this case is
00:16:17.279
graph.facebook.com
00:16:19.120
and 433 is just specifying that we're
00:16:21.279
using the https ssl link
00:16:24.639
and dot sinatra just means we're going
00:16:26.720
to be passing it in a sinatra app so
00:16:29.839
basically contained within this block
00:16:32.399
is a sinatra app and you can do
00:16:34.959
virtually anything you can do with a
00:16:36.320
regular sinatra app which is really cool
00:16:38.639
so you can just you're just basically
00:16:40.560
mounting this and testing against it
00:16:43.759
so
00:16:44.720
for those of you who don't use sinatra
00:16:46.959
very much all we're doing here is
00:16:49.600
specifying with the get keyword that
00:16:51.680
we're making a get request
00:16:53.600
to
00:16:54.480
backslash something and just like rails
00:16:57.199
when you run rake routes you'll see the
00:16:59.360
parameterization of things with the
00:17:01.040
colon before it we're doing the exact
00:17:02.639
same thing here with username
00:17:05.120
so you'll see in the middle
00:17:07.360
in the link we interpolate params
00:17:09.439
username and that's how you pull that
00:17:10.880
out
00:17:11.919
so this is essentially just returning a
00:17:14.240
string that is this response you can
00:17:17.120
obviously spice this up by setting
00:17:18.959
status codes adding conditionals in here
00:17:21.600
if you need some more dynamic power
00:17:24.559
and also setting up the headers and you
00:17:27.760
can also which i sometimes do this in my
00:17:30.160
testing is back it with like a small
00:17:32.400
yaml database so you can get some more
00:17:34.559
realistic data than just a simple
00:17:37.760
string
00:17:40.160
so
00:17:41.440
that's the response and
00:17:45.440
now when we're writing our spec for
00:17:47.600
shamrack
00:17:48.799
all we're doing
00:17:50.320
is
00:17:51.760
keeping it on this base level we don't
00:17:53.520
have to wrap it with anything because it
00:17:55.520
will automatically in your tests
00:17:57.760
pick up the fact that you have shamrack
00:17:59.679
mounted
00:18:00.720
and it will automatically hit against
00:18:02.480
that end point rather than hitting
00:18:04.960
against the network
00:18:09.440
so
00:18:10.240
you might ask why is this better
00:18:12.640
i think there are a few reasons first i
00:18:14.640
find it more dynamic
00:18:16.480
i find it more expressive as well and
00:18:18.400
you can really you know add as much
00:18:20.960
functionality you need to test your
00:18:23.280
integrations as you want and you can
00:18:25.039
also back it with yaml if you need you
00:18:27.200
know some pre-population of you know
00:18:29.280
real data
00:18:30.640
and it's also more readable let's go
00:18:32.640
back to this for a second and you can
00:18:34.880
see like
00:18:36.480
reading through this is a lot easier to
00:18:38.080
parse through and you know where the api
00:18:39.840
requests are being made to versus the
00:18:41.760
stubbing we showed in the first example
00:18:44.000
with webmock is a little bit hard to
00:18:45.600
read so that's why i prefer to use
00:18:48.080
this
00:18:49.919
so next we're going to talk about vcr
00:18:52.559
which is a pretty widely used gem and
00:18:54.720
this one has some other benefits
00:18:57.120
that i think are really important to use
00:18:59.280
basically it pre-records your responses
00:19:02.720
and we'll take you through an example
00:19:05.600
so
00:19:06.880
spec helper only thing interesting here
00:19:09.039
we have the vcr configuration block and
00:19:12.160
all we're doing is setting a cassette
00:19:14.320
library so that's basically where these
00:19:18.000
responses will be saved and then we're
00:19:20.480
hooking into webmock because that's a
00:19:22.480
stubbing library we're using
00:19:25.840
so here's a spec
00:19:27.919
and
00:19:28.880
as you can see it's
00:19:30.559
really really similar to the facebook
00:19:32.960
graph mock so basically what this does
00:19:35.600
is you're wrapping it in a block with
00:19:37.200
vcr
00:19:38.480
so
00:19:39.280
vcr what it does is it goes out to the
00:19:41.679
network and makes a request for you in
00:19:43.919
your testing environment
00:19:45.600
and it pulls that response back and
00:19:48.000
saves it in this case at facebook
00:19:50.480
user arjun
00:19:52.640
and the nice thing about this is you
00:19:54.160
don't have to go out and collect your
00:19:56.400
own responses which i find to be pretty
00:19:58.880
tedious and also error prone
00:20:01.280
but it also means you don't have to
00:20:05.679
break airplane mode with your test
00:20:07.840
because you can run this before and you
00:20:10.240
can cache all of the
00:20:12.080
json responses and play them back in
00:20:14.640
your build so when you're running it on
00:20:16.960
travis ci or circle or whatever you
00:20:19.120
happen to use you're not going to break
00:20:20.799
your build
00:20:21.919
because of network failure you're going
00:20:24.400
to be using these cache responses
00:20:27.520
and it also
00:20:29.200
just allows you to verify the responses
00:20:31.280
so
00:20:32.080
like i mentioned it's a little error
00:20:33.360
prone i've tried collecting these
00:20:34.880
responses on my own and you know
00:20:37.200
sometimes i copy and paste them wrong
00:20:39.440
and come up with an issue so this kind
00:20:41.600
of allows you to like have a nice
00:20:43.600
programmatic way of pulling those in
00:20:48.320
so there's also an additional build
00:20:50.240
process you can add so for the nhl
00:20:52.640
example i talked about uh the problem
00:20:54.960
was there was no versioning so what you
00:20:56.799
can do is if you want bonus points and
00:21:00.000
you're really dependent on an api that
00:21:02.880
doesn't have versioning you can do some
00:21:04.799
kind of build process
00:21:06.400
or you know test setup where you're
00:21:08.559
basically running it outside of your
00:21:10.080
normal test mode and you check the
00:21:11.760
cassettes for diffs and verify that the
00:21:14.159
responses are not changed from before so
00:21:16.960
this can help you avoid versioning
00:21:18.480
issues so i recommend that if you're
00:21:19.840
using something like nhl api
00:21:24.640
so the next one we're going to briefly
00:21:26.400
talk about is puffing billy
00:21:28.640
and uh aside from having a really cool
00:21:31.200
name and a nice logo on their github
00:21:34.640
this is uh an interesting gem to use
00:21:37.440
we're not going to use an example here
00:21:38.880
but basically what it is is for
00:21:41.440
in-browser requests so basically if
00:21:44.159
you're having integrations that are
00:21:45.679
browser-based you can record and reuse
00:21:49.440
just like vcr
00:21:51.120
and use those responses again
00:21:55.039
so
00:21:56.320
i don't want you guys to think that all
00:21:58.799
of this has to be done in a ruby and
00:22:00.559
that you have to
00:22:02.480
use vcr to first record your responses
00:22:05.200
there's a lot of tools out there
00:22:07.280
that will help you
00:22:09.120
to collect these responses test api
00:22:11.919
endpoints faster and i want to share
00:22:14.000
some of those with you
00:22:17.840
so
00:22:19.120
chrome dev tools has anyone heard of
00:22:21.120
this in here yeah probably probably all
00:22:23.760
of you but uh this is the first one i'm
00:22:25.440
mentioning because i use it probably
00:22:27.760
every day uh obviously it gives you a
00:22:29.919
really nice way of you know viewing
00:22:32.000
responses and requests and resending
00:22:34.000
them so super useful i'm not going to
00:22:36.400
get too far in depth in that one because
00:22:38.080
i'm assuming most people worked with it
00:22:40.640
but it doesn't hurt to mention
00:22:43.120
so next postman if you want to stay
00:22:45.039
within chrome this is an extension you
00:22:47.360
can use
00:22:48.480
and it basically gives you a user
00:22:50.400
interface around running these requests
00:22:53.440
so that
00:22:54.400
you can have kind of an easier way to
00:22:56.080
play with
00:22:57.039
requests and responses it allows you to
00:22:58.960
save them it gives you you know
00:23:01.440
a time in milliseconds of completion
00:23:04.559
and this one i think is i was working on
00:23:07.679
a
00:23:08.480
tinder api client for fun so um
00:23:12.240
that's what these requests are for so
00:23:14.640
that one's actually up on my github too
00:23:16.080
if you're curious uh
00:23:17.840
so i use that a lot
00:23:19.919
but if you like to stay a command line
00:23:21.600
based i would recommend httpi
00:23:25.200
it's basically an easier to use version
00:23:27.760
of curl
00:23:29.039
and it doesn't have like quite the
00:23:30.799
archaic syntax curl has
00:23:32.880
so i think it's you know worthy worthy
00:23:35.280
of use and you know be easier obviously
00:23:37.840
to run a script around this than it
00:23:39.760
would be to run around postman so if you
00:23:42.159
need to do something more programmatic
00:23:44.080
this is probably your best option
00:23:47.200
and one last tool i really like to use
00:23:50.159
is called charles
00:23:52.240
and charles does a lot of the same
00:23:54.640
things as chrome dev tools does but it
00:23:57.360
acts as a proxy so it basically captures
00:24:00.640
you know requests between you and your
00:24:02.480
network so you can set this up to
00:24:04.960
capture any requests from your
00:24:08.000
mac machine or you can
00:24:10.480
proxy in your phone as well
00:24:12.640
so i found this really valuable when i
00:24:14.799
was testing out the requests from the
00:24:17.279
snapchat client
00:24:19.039
because it allowed me to see what my
00:24:20.960
phone was making for requests and record
00:24:22.960
those and especially when we didn't know
00:24:24.799
what the requests were it was it was
00:24:26.320
very helpful in that case
00:24:28.159
and uh it's it's also cool because
00:24:31.120
you know when you're building an api on
00:24:33.840
ruby and you want to build an ios client
00:24:36.799
with it and you're not really sure how
00:24:38.799
often to poll and stuff i sometimes pull
00:24:40.960
this up and i'll just see what other
00:24:42.640
apps are doing so it's a good way of
00:24:44.720
debugging other people's work and you
00:24:46.880
know seeing how they're doing it well
00:24:49.039
so
00:24:50.320
i highly recommend you check it out it's
00:24:52.320
pretty easy to use
00:24:53.919
and you can use it with ssl requests as
00:24:56.480
well
00:24:58.400
so here's some additional reading i know
00:25:00.480
you won't have time to write this all
00:25:01.679
down i'll post the slides on my twitter
00:25:05.440
but next up uh let's bring it all
00:25:08.320
together
00:25:09.520
so
00:25:10.799
we went over the what the why and the
00:25:12.720
how of testing services
00:25:14.960
so
00:25:15.840
we've shown that testing services is
00:25:17.440
crucial
00:25:18.559
they make up really important parts of
00:25:20.159
your app so skipping tests is pretty
00:25:22.159
dangerous
00:25:23.600
i'd have to say if you're in doubt stub
00:25:25.440
it out
00:25:26.960
determine
00:25:28.480
when you're making choices between you
00:25:30.240
know webmock shamrack
00:25:32.880
or puffingbilly even you want to
00:25:35.120
determine the amount of flexibility you
00:25:36.880
need and the amount of extra work you're
00:25:38.799
going to have
00:25:40.000
for example it probably takes more time
00:25:42.400
to make a shamrack server and have
00:25:45.039
dynamic responses than copying and
00:25:47.440
pasting the request you get from
00:25:51.520
the webmock error so you kind of just
00:25:54.159
need to look at the project you have and
00:25:55.760
determine what use case
00:25:58.400
best fits these options
00:26:01.200
and also record responses to save time i
00:26:04.320
wish i would have started doing this
00:26:05.520
sooner it's like super useful i would
00:26:08.240
highly recommend you do that
00:26:10.960
and next up after me
00:26:13.279
i'd recommend you stick around i had a
00:26:15.360
pleasure of uh pairing with austin
00:26:17.520
yesterday and i think his talk plays off
00:26:20.640
my talk a lot in that it
00:26:23.200
talks a lot about inconsistent test
00:26:24.880
failures and he goes a lot more in depth
00:26:26.880
on
00:26:27.760
you know other kinds of inconsistent
00:26:29.520
test failures and you just should
00:26:32.159
definitely stick around if you have the
00:26:33.600
time
00:26:35.039
so that's it for today thank you for
00:26:37.600
taking the time to listen to my talk
00:26:40.080
and if i don't get to your question feel
00:26:42.240
free to shoot me an email or if you just
00:26:43.840
want to chat and you can also find me on
00:26:45.840
twitter so thanks a lot guys
00:27:14.159
you