►
From YouTube: YUI Open Roundtable with Reid Burke on yo/tests and YUI
Description
YUI Open Roundtables cover topics of interest to the front end community.
A
A
B
Cool,
hey
guys,
so
yeah
I've
been
working
for
a
good
long,
while
I'm
testing
stuff
for
yahoo
for
yui,
and
lately
I've
been
working
on
bringing
no
tests
to
more
projects
besides
yui
at
yahoo,
so
yotes
has
been
really
successful
for
yui
and
we
continue
to
use
it
daily
for
checking
the
status
of
of
our
project
for
understanding
the
health
of
each
commit
and
or
making
decisions
to
release
or
to
integrate
features
or
not.
And
it's
it's
been
working
really
well.
B
B
So
this
is
going
to
be
useful
for
a
lot
more
than
just
yui
and
a
lot
of
people
want
it,
and
so
we're
bringing
this
to
other
projects
at
yahoo
right
now,
we're
building
out
a
version
of
yotest
that
actually
will
work
with
more
than
just
yui
and
yeah.
I'm
really
excited
to
be
building
that
and
to
have,
and
the
ultimate
goal
is
to
have
all
of
yahoo's
open
source
projects.
B
A
B
A
B
Yeah,
so
we
have
tools
that
we
use
internally
for
building
projects
that
are
built
on
top
of
jenkins,
so
we
leverage
jenkins
as
internally
for
for
building
most
projects,
most
most
things
that
yahoo
use,
jinkins
and
folks
at
yahoo
have
built
things
on
top
of
jenkins.
That
help
us
understand
the
data
that
comes
from
jenkins
and
helps
scale
change,
and
so
I'm
working
with
the
folks
who
are
developing
these,
like
the
the
super
set
of
jenkins
or
this,
this
thing
that
that
controls
jenkins
to
integrate.
B
You
know
your
tests
with
that
internally,
but
our
of
course.
Our
goal,
though,
is
for
yo
tests
to
work
with
any
ci
system,
and
so
yo
test
does
not
say,
go
out
and
query
a
ci
system.
Instead,
it
expects
the
ci
system
to
be
have
its
results
pushed
to
it,
so
that
isn't
how
the
yo
test
that
we're
looking
at
here
on
the
screen
works
today.
A
And
part
of
the
benefits
of
this
just
to
click
through
just
to
give
a
bit
of
an
example.
If
you
look
on
say
dev3x
right
now,
we
have
three
of
these
stable
unit
failures:
they're,
not
real
figures,
they're
sort
of
flaky,
but
just
to
show
a
little
bit
about
what
that
looks
like.
Can
you
talk
a
little
bit
about
how
this
how
this
works?
B
B
We
wanted
to
distinguish
between
unit
tests
that
are
unstable
and
our
unit
tests
that
are
stable,
so
we
have
some
unit
tests
that
are
known
to
fail
because
of
legacy
reasons
they
just
weren't
written
well.
In
the
first
place,
the
only
really
worked
well
on
the
environments
that
were
tested
back
then,
but
now
that
we're
testing
on
multiple
environments.
We
want
to
understand
if
code
got
worse
and
it's
very
hard
to
do
that
when
you
have
hundreds
of
failures,
every
build
and
some
of
them
sometimes
fail.
B
Some
of
them
don't,
and
so,
when
you
see
things
fluctuate
so
much,
it's
very
difficult
to
understand
the
health
of
the
project,
and
so
what
we
did
to
address
that
is
inside
of
your
test
is
have
a
notion
of
a
stable
and
unstable
unit
test,
for
example,
and
each
of
these
can
be
classified
as
stable
or
unstable.
How
that
works
in
our
new
system.
That's
being
built
right
now
is
that
the
ci
like
this,
like,
however,
you
integrate
with
the
ci
system,
you
can
determine
your
own
rules
and
your
own
logic
for
determining.
B
A
B
A
Who's
who
changed
something
or
what
happened
and
also
having
to
cut
down
on
the
number
of
manual
tests,
has
really
improved,
like
the
fact
that
we
can
just
do
this
so
quickly
like
we
don't
have
to
wait
several
days
to
wait
for
the
the
manual
test
to
be
back.
So
I
think
that's
another
huge
benefit
of
this.
I'm
trying
to
actually
go
to
one
of
the
tests
themselves
in
jenkins,
but
network's,
not
working
too
well
yeah.
A
B
We're
yeah
so,
like
I
said
before,
are
something
that
we
really
want
is
to
have
the
status
of
all
of
our
projects
that
are
built
internally
to
be
shown
to
the
public.
And
so
that's
that's
our
our
goal
to
have
by
the
end
of
the
year,
but
I
think
yeah
that
we
could
probably
get
that
done
sooner.
But
I
don't
have
anything
specific
to
share
right
now.
B
Yeah,
that's
we're
building
this
from
the
start,
with
the
intention
of
open
sourcing,
and
so
so
yeah
it'll
be
under
a
different
name.
But
that's
that's
our
goal
so,
and
this
is,
is
this
tied
at
all
to
yeti
or
not?
Is
it
this?
Has
you
know
you
could
use
yeti
to
run
tests,
but
this
doesn't
depend
on
anything
any
particular
test
framework
or
ci
system.
It
is
really
up
to
anyone
can
write
something
that
would
deliver
test
results
to
the
system.
B
What
I
mean
by
delivered
test
results
is
simply
that
there
is
a
api
for
for
everything.
That's
that's
over
the
web
over
restful,
calls
that
you
make
and
that
are
authenticated
with
say
you
know
github
or
github
enterprise.
If
you
want
to
run
this
on
your
own
inside
of
your
own
organization
and
so
yeah
there's
really.
This
can.
A
B
So
yeah
I
mean
there's
pretty
standard
stuff,
just
the
name
duration
and
what
what
kind
of
test
it
is
unit
functional.
You
know
if
it
passed
or
failed,
there's
a
failure.
You
know
stack
trace
or
some
more
information,
so
it
doesn't
probably
store
every
every
bit
of
information
that
everyone
would
like
to
have.
But
it's
right
now,
it's
enough
for
you
to
get
real
work
done
so,
additionally,
there's
also
a
facility
for
monitoring
performance
aspects
of
builds.
That
is
not
in
the
version
you're
looking
at
now
right.
B
So
there
is
a
way
for
builds
to
communicate,
say
how
long
they
they
took
or
or
how
long
certain
parts
of
it
took
and
those
things
can
then
be
say
graft.
So
so
that's
it's
pretty
it's
pretty
simple,
but
I
think
it's
it'll
still
be
very
powerful
when
you
get
to
organize
it
based
around
code
revisions
and
environments,.
B
I
don't
have
anything
to
share
about
code
coverage
at
the
moment
so
but
code
coverage
could
be
a
metric
city
but
yeah
code.
Coverages
is
a
pretty
difficult
problem
to
have
in
a
standard
way
across
many
different
projects
or
I'm
sorry,
many
different
kinds
of
languages
which
can
which
determine
code
coverage
in
different
ways,
and
so
our
focus
is
on
testing
and
and
also
reporting,
say,
aggregate
code
coverage
information,
but
also
I
mean
it's
yeah,
that's
that's,
basically,
where
we
are
right
now.
B
Code
coverage
is
important,
but
I
think
a
lot
of
folks
are
gonna,
get
a
lot
of
value
out
of
just
the
testing
side
and
also
some
aggregate
code
coverage
information.
But
I
look
forward
to
yeah
adding
more
helpful
features
around
code
coverage
at
some
point
so
or
with
the
help
of
the
community
there.
Any
potential.
B
A
B
A
B
Yeah
yeah,
so
so
yeah
we
built
this
with
the
with
intending
you
know
for
it
to
really
be
useful
for
multiple
different
browser
environments.
But
really
you
can
imagine
say
if
you
have
your
own,
you
know
if
you,
even
if
you
use
say
travis,
you
know
you
can
run,
say:
node
travis
tests
on
many
different
versions
of
node
and
those
could
show
up
as
environments
or
you
could
have
your
own
ci
system
that
supplements
travis
like
we
do,
and
so
we
could
show
travis
results
alongside
your
own
ci
system.
A
B
Yeah,
so
that's
something
I'm
working
on
right
now
actually
is
building
out
well
building
the
integration
integration
with
jenkins,
that's
just
baseline!
So
like
no
matter
you
know
so
there,
but
there
can
be
any
you
know.
So
what
I
mean
by
baseline
is
that
when
you,
if
you
have
anything
in
jenkins,
you
can
you're
guaranteed
to
get
some
basic
information
about
tests,
because
jenkins
does
a
lot
of
work
for
parsing
different
kinds
of
test
types
to
show
it
in
its
own
ui.
B
So
if
you're
already
using
that,
then
you
know
this
can
read
off
that
and
that's
the
lowest
common
denominator
inside
of
yahoo.
For
for
almost
everything-
and
so
you
know,
winds
up,
reporting
the
jenkins
in
some
way,
and
so
that's
what
we're
going
to
leverage
so
yeah,
but
going
forward
really
you
could
I
mean
we're
going
to
have
more
fine-grained
importers
that
could
understand
more
about
things
like
code
coverage
or
can
actually
supply
test
results
as
they
finish
inside
of
a
job.
So,
as
you
know,
you
know
so
like.
B
You
know
once
once
test
frameworks
catch
up
with
that
kind
of
concept,
but
we
definitely
are
excited
about
having
test
results
available,
the
instant
that
they
are
done
and
that's
really
just
a
function
of
support
inside
of
your
own
test
framework.
So
so
as
soon
as
your
test
framework
can
or
the
thing
that
you
know
this,
the
whatever
client
reports
to
you
a
test
can
support
that,
and
it's
ready
to
go.
We
can
you
can
do
that
so.
B
So
this
doesn't
really
depend
on
you,
you'd
kind
of
I
mean
once
you
have
sauce
labs
running
in
any
ci
environment
that
you
like,
that
it
just
shows
up
as
test
results,
and
so
really
we
love
sauce
labs
but
yeah.
It's
really
just
we're.
Looking
at
integrations,
perhaps
with
say
you
know,
services
that
are
like
travis
so
or
you
know
things
that
you'd
run
in
you
know
that
are
like
traffic
save.
A
A
A
As
you
can
see,
all
the
tests
are
passing.
There's
no
unit
test
failures.
I've
been
monitoring
github
to
see
if
there's
been
any
any
new
issues
coming
up
since
the
release,
candidates
out
and
so
far
so
good
we've
also
got
a
number
of
tests
that
are
a
number
of
issues
that
this
release
fixes.
So
if
you
have
a
test
environment
out
there,
I
encourage
you
to
get
this
release.
A
Branch
get
an
instance
of
this
and
test
it
out
before
for
the
end
of
this
week,
and
if
you
run
into
something
please
let
us
know
right
away
with
the
issue.
I'm
gonna
get
him
outside
that.
I
think
we're
good
to
go
so
we're
gonna
close
out
our
round
table
early
this
week,
thanks
a
lot
reid
for
coming
and
talking
with
us
about
your
tests.
Sure.
B
B
B
A
968
145
45,
of
course,
and
that
number's
probably
gone
up
since
then,
but
nice
to
have
like
an
odometer
or
something
you
could.
You
could
run
yeah
for
sure
all
right
thanks
everybody
for
coming
tonight
today
see
you
next
week
next
week,
we'll
have
some
stead
talking
about
es6
modules
that
he's
converted
all
of
his
y
components
over
to
so
see.