►
Description
Although WebdriverIO is an extremely powerful and simple tool to use, most of the folks find it extremely difficult to create test framework with WebdriverIO and eventually dropout using the same. Through this presentation and the demo's, Soumya will show quick cool tweaks that you can perform on the tool to successfully build a test framework with WebdriverIO. He will show how WebdriverIO is actually a very simple tool to use. He will also talk about how you can scale thousand's of your tests in no time and perform multiple browser testing with ease with centralised reporting with Allure where you can preserve the historical information of the runs.
A
Hey
there,
my
name
is
sammy
mukherjee
and
I
head
product
at
apt.io.
We
are
in
a
digital
adoption
space
and
I
will
talk
about
more
of
the
things
in
in
our
in
this
particular
session.
But,
first
of
all
I
would
like
to
welcome
all
of
you
to
the
open
gs,
world
201
conference
and
hope
you
all
are
doing
fantastically
well
and
hope.
Your
loved
ones
are
healthy
during
this
pandemic.
A
I
hope
you
are
having
a
great
time
listening
to
all
these
great
speakers
that
we
have
today
and-
and
I'm
sure
that
you
know
everyone
is
so
fantastic
all
right.
So
let's
go
ahead
and
see
what
I
have.
A
First
of
all,
I
would
like
the
organizers
to
giving
me
the
op
for
giving
me
the
opportunity
to
speak
in
this
conference
today,
I'm
going
to
speak
on
a
topic,
which
is
how
we
can
wrap
webdriver
io
and
create
your
own
framework.
A
When
I
started
with
this
tool,
I
faced
a
lot
of
issues
getting
started
with
the
poc,
as
there
are
where
there
was
less
documentation,
mostly
to
customize
things
and
write
things
over
top
of
the
framework.
A
Another
challenge
was
that
nobody
was
discussing
use
case
around
this
rule
and
everyone
was
only
discussing
their
issues
in
the
channel
and
of
which
only
a
handful
will
answer
my
queries.
Another
challenge
was
that
anyone
whom
I
have
asked
about
using
this
tool-
everybody
prefer
to
use
either
cypress
or
protractor,
and
not
webdriver,
io
and
yeah.
A
You
know
how
to
do
your
framework
development
on
this
tool
and
talk
about
integrations,
customizations
and
what
all
and
whatnot,
just
to
give
you
a
background
how
I
started
with
this
poc
that
when
I
joined
my
organization,
we
had
a
challenge
because
we
had
three
set
of
applications.
One
is
on
the
electron.
A
A
You
know
of
this
of
a
tool
you
know
who
can
who
I
can
leverage
and
and
automate
all
the
three
sets
anyways.
So
let's
go
ahead
and
talk
about
the
agenda.
We'll
talk
about
I'll
talk
about.
You
know
why
I
chose
webdriver
over
other
tools.
This
is
because
that
people
should
know
that
what
are
the
intentions
behind
this
behind
choosing
this
tool
and
why
we
should
use
this
particular
tool.
A
Second,
I
will
talk
about
the
shippable
framework
wrapper,
which
I
have
created
over
webdriver
io,
and
you
would
see
that
how
simple
webdriver
tool
is
that
it
gives
us
so
much
flexibility
to
work
with
and
and
how
easily
we
could
have
built
this
particular
framework
for
our
company
last,
but
not
the
least.
I
will
will
show
a
demo
where
I
will
go
through
some
code
snippets
and
we'll
talk
about.
A
I
will
run
a
use
case
and
then
it's
in
a
live
use
case
on
my
on
my
company's
app
as
to
how
we
are
automating
the
things
all
right.
Okay,
so
now,
let's
see
how
why
I
have
actually
chosen
this
tool
and
why
I'm
saying
that
this
tool
is
so
flexible
and
easy
to
use,
and
quite
also
quite
flexible,
on
customizations,
etc.
A
A
A
How
is
our
pipeline
looks
like
we
will
also
push
we'll,
also
push
it
to
the
standard
documentation
at
the
end
of
this
particular
conference,
so
that
people
can
go
ahead
and
and
look
into
the
customizations
that
that
we
have
done,
and
we
have
contributed
to
web
driver
io
and
on
june
2nd.
While
you
are
listening
to
this
particular
cast,
you
would
basically
also
see
that
this
this
this
is
being
open
sourced
as
well,
so
that
people
can
go
and
try
use
to
use
this
wrapper.
A
You
know
and
and
see
how
flexible
it
is
to
work
with
web
driver
io
all
right
all
right.
So
why
why
I
chose
vipre.
However,
the
tools
is
one
of
the
things
that
we
had
to
look
is
is
that
our
developers
and
our
technology
is
based
on
javascript,
so
native
development
technologies
in
javascript.
So
we
wanted
a
tool
which
can
support
this
particular
thing
and
as
a
best
practice
in
automation.
You
know
we
always
need
to
merge
our
automation
code
in
the
dev
branch.
A
You
know
so
that
you
can
build
your
code
along
with,
along
with
the
test
code,
and
then
those
tests
can
be
triggered
most
of
the
companies.
I've
seen
is
that
they
will
create
their
framework
in
some
different
technology
and
their
basic
launch
is
something
different
and
then
there
it's
not
much
flexibility
that
you
can
merge
them
together
and
run
it
as
a
package
kind
of
thing,
but
but
we
did
do
not
want
to
make
that
mistake.
A
The
second
thing
is
that
why
we
chose
web
driver,
I
o
is
it's
because
that
our
main
component
are
is,
is
it
the
desktop?
App
is
based
on
electron
js
and
we
used
a
framework
called
a
spectron
which
is
written
over
web
driver
io,
and
since
these
two
goes
hand
in
hand
and
with
fantastic
integrations
in
place,
we
could
basically
achieve
the
electron,
js
automation
as
well.
A
That
is
also
a
a
requirement
that
we
may
have
in
the
future,
wherein
the
developers
can
also
write
and
contribute
to
this
javascript,
since
it
is
based
on
javascript.
Third
thing
is
that
you
know
we
extensively
use
react.js
in
angular
4
libraries,
and
that
is
where
we
would
need
some
tool
to
basically
help
us.
A
One
more
thing
which
is
which
is
important
for
us,
is
to
achieve
end-to-end
automation
because,
as
I
said,
that
we
have
electron
js
and
react
web,
and
we
also
have
browser
extension,
so
we
want
to
run
end-to-end
test
cases
and
we
wanted
one
tool,
one
single
tool
which
can
support
all
this.
So
this
is
why
we
have
chose
web
driver.
I
o
we
majorly
use
course
react
and
angular
components,
as
I
already
said,
and-
and
that
is
why
we
we
wanted
to
use
the
web
driver.
I
o.
A
If
we
go
next
okay,
we
want
some
tool
which
can
seamlessly
have
integrations
with
the
reporting
tools
cross
browser
on
demand,
platforms
and
various
others.
So
if,
if
you
look
at
web
driver
ios
architecture,
it
is
mostly
service
based
or
plugin
based,
I
would
say
when
you
can
just
hook
in
a
plugin
and
you'll,
get
get
to
go,
nothing,
fancy
it's
very
easy
to
use,
and,
and
and
since
that
drivo
is
web,
driver
io
is
based
on
plugins,
and
each
component
is
a
plugin
which
makes
it
extremely
flexible.
A
We
also
want
a
tool
to
basically
which
can
run
on
web
driver
io
web
driver
protocol.
Why
is
that
so?
Because
webdriver
is
evolving
and
we
don't
want
to
use
a
tool
which
can
say
after
a
new
year
that
we
are
a.
We
are
end
of
life
cycle
like
for
an
example
protractor
now,
whoever
was
using
protractor
has
now
may
been
fixed
what
to
do
and
how
we
can
migrate
and
what
all
and
whatnot.
So
we
want
to
use
a
tool
which
can
be
driven
on
the
webdriver
protocol
and
supports
it.
A
The
final
aspects
that
we
have
thought
about
is
that
the
tool
needs
to
be
fast,
and
we
have
seen
this
it's
extremely
fast.
A
You
know,
and
and
that's
our
philosophy,
because
we
also
work
with
open
source
and
contribute
open
source
and
since
the
philosophy
matches
with
creator
of
this
tool,
you
know
we
have
chosen
this
the
last.
Not,
but
not
not
least,
you
know
it's
extremely
customizable,
I
would
say:
okay,
if
you
go
next
I'll
talk
about
the
shippable
framework
wrapper
that
we
have.
Why
do
we
say
that
you
know
we
want
to
ship?
A
We
also
want
consistency
in
what
we
do
at
apt
and
hence
we
splitted
the
framework
into
two
components,
which
is
a
shippable
based
framework.
That
means
any
project
that
we
start
here
can
can
can
basically
consume
the
shippable
base
based
framework
and
then
can
implement
their
project
related
stuff
so
which
can
later
be
consumed
by
any
implementation
project,
and
can
there
be
only
minimalistic
changes
that
are
required
for
that
project
implementation
perspective?
A
We
have
a
team
who
basically
contribute
to
the
shippable
based
framework.
So
we
keep
on
writing
our
libraries
and
everything.
So
the
shipper
based
framework
consists
of
an
engine
so
that
engine
is
responsible
to
gather
the
configurations,
understand
what
spec
to
run,
which
environment,
what
browser
versions,
what
cloud
platform,
whether
it
is
device,
whether
it
is
web,
so
all
sort
of
comp,
permutation
combination
that
engine
would
decide.
So
that's
basically
a
runner.
A
Secondly,
there
are
base
configurations
which
are
being
stored
in
an
enamel
file.
That
means
like
for
an
example.
A
simple
example
would
be
would
be
delay
right.
So
across
the
framework.
How
much
is
the
deal
and
then
you
can
override
it
in
your
implementation,
and
you
can
you
can
see
you
know
how
much
do
you
do
you
want,
or
the
shippable
based
framework
has
got
all
the
integrations
in
place.
That
means
it
has
integrations
to
central,
centralized
logging,
which
we
do
it
in
elasticsearch,
and
then
we
have
cus.
A
We
have
standard
reporting,
which
is
also
centralized,
and
we
basically
sends
all
our
data
to
kafka
queue
and
then
later
on,
a
beautiful
you
know,
report
generates
and-
and
we
keep
centralizing
our
data
each
time,
because
we
run
our
ml
models
and
so
we'll
in
in
in
the
future.
Slides
I'll
show
what
we
do
and
the
finally,
in
the
space
shippable
framework,
what
we
have
is
the
brace
framework
library,
which
is
nothing
but
your
getter
setters.
Your
selects
your
sets
and
everything.
A
A
What
goes
into
the
project
implementation
is
is
the
pro
it's
the
team
who
is
consuming
the
shipping
waste
framework?
They
just
have
to
create
their
tests,
they
need
to
run,
they
need
to
create
their
own
business
libraries
and
they
need
to
also
make
those
customize
the
custom
configurations,
which
is
nothing
but
environment,
browsers
versions,
specs
and
what
all
and
and
cloud
platforms
and
etc.
A
Let's
talk
about
the
framework
wrapper
stack,
and
why
is
this
important?
So
engine
is
nothing
but
an
integrator
or
an
orchestrator.
The
engine
responsibility
is
to
drive
the
test
by
looking
into
the
base
configurations
and
then
go
through
the
custom
configurations
and
plug
in
the
right
set
of
plugins
in
the
test
execution
process.
A
It
is
the
one
which
will
make
sure
whatever
you
have
written
in
the
custom
configurations,
it
will
take
care
of
it
will
initialize
the
web
driver
config
file
and
then
instruct
it
to
execute.
This
in
turn,
runs
the
automation
pack.
The
spec
then
use
the
base
framework
libraries
to
call
the
reusable
methods
which
are
common
throughout
the
framework
and
also
call
the
business
libraries
which
consist
of
the
application
flows
and
the
logic
pertaining
to
the
application.
A
So
we
define
different
components
in
the
business
libraries
and
then
we
call
those
components
into
our
automation
script.
So
all
those
dark
ones
here
are
all
shippable
framework
components.
The
blue
ones
are
all
the
project
implementations
we
used
to
test
framework,
the
favorites
webdriver
ion
spectron
and
then
application
under
test
components
are
the
browsers
in
the
electron
app.
But,
interestingly,
we
have
extensions
and
we
have
an
injected
script
and
you
will
see
in
my
particular
screen.
A
You
know
when
the
things
would
pop
up
that
how
the
extensions
are
being
loaded
and
all
so
web
driver.
I
o
and
spectron
is
underlying
tool
integrated
in
the
same
framework
to
support
automation
on
browsers
and
electron
app
and
here
through
web
drawer
extensions,
which
are
installed
on
the
go
and
seamlessly
as
well.
Javascript
is
injected
in
the
application
you
know
under
test.
A
Unfortunately,
I
cannot
show
it
running
on
the
live
environment,
but
I
will
discuss
about
how
the
customizations
are
done
with
web
driver
io
going
forward
in
the
demo
and
run
through
the
sample
report
execution
executed
against
the
live
product.
I
will
also
execute
the
framework
on
the
the
live
application
that
we
have
and
to
make.
You
understand
how
the
configurations
can
be
made
and
the
automations
can
be
achieved.
A
Okay,
now
just
wanted
to
go
through
our
execution
pipeline
so
that
you
have
an
understanding
of
what
we
do
in
apti.
Let's
quickly
talk
about
how
the
execution
pipeline
looks
like
we
have
get
github
actions
as
a
primary
ci
tool,
and
you
know,
as
a
pull
request,
is
machine
master
the
pipeline
guest
record.
A
We
always
make
sure
that
when
we
run
our
test
on
a
clean
environment,
as
always,
the
data
issues
are
really
really
painful
to
fix.
A
We
wanted
to
have
a
clean
environment,
so
while
we
do
deployment
we,
the
next
step
is
that
we,
if
we
load
our
master
data
and
then
you
know,
attach
and
and
and
then
the
engine
gets
attached
with,
the
configurations
and
the
specs
the
engine
knows
what's
to
pick
up
and
where
to
put
and
what
to
run.
A
But
key
here
is
that
we
always
run
it
on
the
clean
environment
so
that
we're
absolutely
sure
that
the
issues
that
are
coming
are
with
respect
to
the
scripts
or
with
respect
to
the
or
with
respect
to
to
the
environment
and
what
all,
what
the
tests
are
then
executed
across
various
browser
versions,
platforms,
multiple
browser
extensions.
A
So
that's
a
small
caveat
there
and
then
the
results
are
locked
and
then
pushed
into
a
centralized
location
and
we
basic
extensively
mine
our
results.
A
We
specifically
pick
up
the
data
of
results
and
logs
and
pass
it
through
the
ml
model
to
tag
the
most
important
tests
that
executed
for
the
build,
do
productive,
analytics
to
fetch
and
perform
analysis
on
the
runs
and
failure
results.
We
also
determine
if
the
builds
are
stable
enough
to
continue
testing
on
the
same.
A
The
logs
from
both
environments
and
and
the
production
is
then
correlated
to
identify
new
tests
and
on
the
basis
of
test
runs.
The
ci
is
then
continued
or
being
stopped
to
do
further
running
of
the
pipeline.
So
ml
model
has
got
huge
influence
of
what
we
do
and
and
and
based
on
the
decision
being
made
by
the
the
algorithm
we
basically
mark
or
build
green,
amber
and
red
and
and
and
and
believe
me,
we
are
96
percent
accurate
on
what
we
do
right
now
in
our
automation.
A
A
Video
studio,
let
me
quickly
show
you
what
we
have
so
so
this
is
the
this
is
the
framework
project,
and
if
you
look
at
it,
we
have
appd
framework,
which
is
nothing
but
the
the
shippable
wrapper.
That's
that's
what
I
was
telling
you.
You
can
see
hello
report
here.
Why
is
because
I
executed
in
local,
but
but
actually
it's
get
centralized.
So
we
have
library
here
which
is
a
base
library,
which
is
nothing
but
our
the
custom
functions
or
the
reusable
functions
which
we
can.
A
We
call
it
in
our
in
all
in
our
scripts
we
have
props,
which
we
are
with,
which
basically
holds
our
credentials
and
and
some
framework
related
properties.
We
have
source.
So
what
we
do
is
we
basically
define
all
our
components
in
in
in
the
separate
file,
and
then
we
have
configurations
now
what
we
have
done
is
we
have
split
these
configurations
into
two
part,
one
being
the
application
level
configurations,
and
one
is
the
framework
level
configuration.
These
are
project
level.
A
We
have
basically
defined
different
variables
here,
so
what
our
master
script
does
master
scripts
looks
into
this
particular
file
first
and
see
whether
they
need
to
open
up
an
extension,
whether
what
environment
to
run
whether
they
need
to
run
it
on
local
or
lambda
test
or
browser
stack
or
local
or
in
any
of
the
cloud
platform,
and
then.
A
And
then
you
know
the
run
configurations,
which
is
nothing
but
what
platform,
what
version?
What
browser
you
need
to
run
and
then
what
spec
to
run?
What
are
the
base?
Urls
that
we
have
and
then
the
extensions
that
are
being
will
be
used?
Okay,
we
will
not
run
it
on
lambda
test
right
now
or
source
labs,
but
what
this
is
just
for
the
demo
purpose
interesting.
So
now
we
have
extensions
which
holds
extensions
for
us.
We
have
project
library
and
this
project
library
consists
of
our
business
functions.
A
We
have
pages
which
holds
our
objects,
and
then
we
have
specs,
which
is
our
cases.
A
So
what
we
do
is
we
basically
write
our
cases
which
basically
calls
our
components
and
then
which
calls
out
the
pages
for
the
objects
and
and
likewise
so
now,
anyone
who
is
actually
implementing
our
base
shippable
framework,
they
just
need
to
create
a
source
directory
and
all
those
things
and
and
that's
about
it
and
and
then
it
seamlessly
can
connect
with
the
updates
framework
or
the
shipping
framework.
A
A
So
if
I
go
to
the
apt
master,
you
would
see
that
we
have
written
a
merge
feature
here
which
can
basically
take
the
web
driver,
io
config
and
then
merge
it
with
our
configurations
which
we
have
set
above
and
read
through
our
config
file,
and
obviously
these
are
different
runners
that
we
have
used
and,
and
likewise
so
we
have
browser,
stack,
lambda
test
and
source
labs.
A
We
also
have
this
web
drive.
I
o
config,
which
is
the
base
configurations.
We
just
have
some
hooks
written
here
which
is
after
test
and,
and
you
know,
after
sweet
sweet
wherein
what
we
do
is
we
basically
picks
up
the
results
and
push
everything
up
in
the
in
the
in
the
back
end
for
an
analysis.
A
So
this
is
very
clean.
This
is,
there
is
nothing
in
it,
but
what
we
do
is
since
web
driver.
I
o
only
understand
this
particular
file.
We
basically
create
our
own
configurations
and
then
watch
it
with
this
particular
file
and
then
execute
it.
So
that's
how
we
basically
wrapped
web
driver
io
configurations
with
our
configuration,
which
are
custom
configurations
so
when
you
would
start
using
this,
you
can
create
your
own
set
of
attributes
and
the
the
master
script
will
take
it
over
from
there
okay.
So
this
is
our
project
structure.
A
A
A
A
So
it's
passed
and
now
what
what
would
have
happened
is
it
would
have
pushed
in
all
our
results
into
the
back
end,
but
so
it's
generating
the
results
and
I'm
I'm
running
this
on
local,
and
that
is
the
reason
I
can't
show
you
the
back
end
because
of
ip.
A
A
Once
the
report
is
done,
we
we
then
analyze
and
then
our
machine
learning
model
takes
care.
Now
coming
back
to
the
particular
framework,
if
you
see
it's
quite
clean,
it's
easy
to
use
and
if
I
go
to
package.json
and
one
of
the
things
that
I
that
I
wanted
to
show
is,
these
are
all
the
dependencies.
A
So
what
you
do
is
you
just
need
to
do
an
npm,
install
and
install
all
the
packages
that
are
required
and
that's
about
it
and
if
you
look
at
it,
these
are
individual
services
that
we
are
using
and
and
how
easy
it
is
like
you
know.
If,
if
I
want
to
now
use
a
service
of
web
driver,
I
would
just
need
to
hook
into
package.json,
that's
about
it
and
then
and
then
put
it
into
our
onto
our
framework.
A
So
this
is
what
I
have
for
today
and
thank
you
very
much
for
giving
me
the
opportunity
to
to
speak
in
the
open,
js
con
conference
and
and
if
you
guys
have
any
questions
going
forward.