Shift From UI to API Testing
Key Points
- Continuous testing drives rapid feedback to developers, aligning with DevOps and continuous delivery principles.
- Over‑reliance on automated UI tests often fails because UI changes repeatedly break the tests, creating a tension between testing and market responsiveness.
- A more effective strategy emphasizes extensive unit testing—aiming for high code‑coverage metrics—so that each new piece of code ships with its own tests.
- Placing strong emphasis on API testing captures business logic at runtime, verifies inter‑service interactions, and safeguards microservice stability as APIs evolve.
- While UI automation is still faster than manual testing, balancing it with robust unit and API tests yields a healthier, more agile development pipeline.
Full Transcript
# Shift From UI to API Testing **Source:** [https://www.youtube.com/watch?v=RYQbmjLgubM](https://www.youtube.com/watch?v=RYQbmjLgubM) **Duration:** 00:07:18 ## Summary - Continuous testing drives rapid feedback to developers, aligning with DevOps and continuous delivery principles. - Over‑reliance on automated UI tests often fails because UI changes repeatedly break the tests, creating a tension between testing and market responsiveness. - A more effective strategy emphasizes extensive unit testing—aiming for high code‑coverage metrics—so that each new piece of code ships with its own tests. - Placing strong emphasis on API testing captures business logic at runtime, verifies inter‑service interactions, and safeguards microservice stability as APIs evolve. - While UI automation is still faster than manual testing, balancing it with robust unit and API tests yields a healthier, more agile development pipeline. ## Sections - [00:00:00](https://www.youtube.com/watch?v=RYQbmjLgubM&t=0s) **Pitfalls of UI‑Centric Test Automation** - Eric Minich explains that while continuous testing seeks fast feedback for DevOps, over‑reliance on UI‑level automated tests makes the test suite fragile and prone to frequent breakage as the user interface evolves. ## Full Transcript
hi I'm Eric Minich with IBM cloud I want
to talk a little bit about continuous
testing this is a practice where we're
trying to drive really rapid feedback to
development as changes come in how
quickly can we identify that there's a
problem
let development know get it fixed this
really supports DevOps principles it
really supports continuous delivery now
the way we see this done most often
leads to some trouble because we think
all right how are we gonna do it fast we
need to automate some stuff how are we
gonna automate it well our manual
processes well we're working at the UI
level so we should grab functional test
automation or either write some scripts
or do some playback and record and we're
going to test a lot of the UI level and
then we might also say well part of our
product is the public API right so we
should test those API I guess as part of
that we'll do a little bit of API
testing and I guess good code quality
probably helps from some unit testing
we'll do a little unit testing - I'm so
we see this sort of approach this is
also the approach that probably leads to
more test automation programs kind of
failing than any other and the problem
is that the UI is relatively malleable
it changes a lot and so when you start
moving buttons around and renaming it
and changing elements your UI tests just
keep breaking and so as you start out
you have a few UI tests and they're
going well and you start getting more
and more and more and everything keeps
breaking and you end up with this
tension between can I test it and can I
you know actually change things and be
responsive to the market and that's all
kind of anti DevOps so that that's sad
when you're weighted too heavily towards
automated UI testing but even that
that's way
better than manually UI testing is much
faster and better it's the only way we
can do it so we know we need automation
here but we want to flip this approach
right we want to say the bulk should be
unit testing every interesting piece of
code that we write should have unit
tests along with it right this is where
we see principles like code coverage
let's make sure we get 90% code
hundred-percent code coverage on our
unit testing so the code the developer
writes comes with unit tests but then
the real key here and what I find most
interesting is to put a lot of weight on
the API testing particularly in a world
where we're moving to more micro
services but even very true as we were
looking at service-oriented
architectures and and things like that
API testing does a couple of things one
it captures our business logic at
runtime in some of the interconnection
between various pieces and parts of our
applications the next thing is the
easiest way to break all of our micro
services is to have api's start changing
and then a different micro service
breaks if we're putting our api's live
and calling those api's and making sure
they're steady all right or at least
backwards compatible that helps us have
healthier micro service architectures
and so this is a level where things
aren't supposed to change a lot whereas
at the UI level and we're still going to
have our automated UI tests things are
supposed to change a lot they are
supposed to be more reactive to the
market so let's do less testing less
automated testing perhaps that kind of
that most dynamic level more at the most
predictable levels the code levels this
is really powerful this is stable these
are where we see the most successful
transformations towards continuous
testing now if we were to stop here
have nice automated testing story we
would have left out the people and
people are absolutely critical to
testing manual testing absolutely still
has a role in how we deliver high
quality software and so there's a couple
of key pieces here all right we're gonna
want exploratory tests and this is where
we have see if I can spell exploratory
so where we have our smartest you know
good testers going in exploring the
software trying to break things right
looking for things we might have
overlooked and our other tests this is
also a place where you often have
product managers and other people like
that I'm working on the user experience
all right making sure that as they go in
and they see the new features that all
works and it feels good right you'll get
your designers involved here so you've
got these elements and then typically
you're gonna have some real users
actually try the software and I'm just
gonna call this a beta this could still
be you know what's normally called user
acceptance testing it could be in a more
consumer-oriented app it could be
something like rolling it out to 5% of
your users and seeing if they like it or
not you're not gonna do that in a
medical app most of the time because you
don't want to have bugs hurt people so
manual testing still has a role it is
not following a test script right if it
can be written down in a test script
then it could be a UI test but more
likely the things underlying that are
all API calls and you want to put your
testing here at the API level so what I
challenge you to do is make sure that
you're building out your unit tests
making it look less like this more like
that and that you're looking at all of
your UI level tests and saying could we
test the same thing at the API level
then reserve your functional
testing or your UI level testing for
real end-to-end validation that
everything actually works together you
need some of it don't overdo it and make
sure it's the end end sort of capability
it's not small feature function that
could be handled by the api's so I hope
that's a useful introduction to continue
as testing and the biggest gotcha that
we see out there thank you if you have
questions please drop us a line and if
you want to see more videos like this in
the future be sure to LIKE and subscribe