►
Description
Pester is normally used for testing PowerShell code, but did you know you can use it to test your infrastructure as well? Infrastructure as Code is becoming a popular way to describe your environment. Knowing that, doesn’t it make sense to test your infrastructure as though it were code as well?
Resources:
Find more of Brandon's Projects at: https://github.com/devblackops
Content from presentations can also be found at our github:
https://github.com/rtpsug/Meetups
Watch our previous meeting on PSGraph:
https://www.youtube.com/watch?v=Mmzm31QacDA
SUBSCRIBE to learn about PowerShell!
https://www.youtube.com/channel/UCiTuB6HZiupE8CJ71vkMFnA/example?sub_confirmation=1
LET'S CONNECT!
-- https://twitter.com/rtpsug
-- https://www.meetup.com/Research-Triangle-PowerShell-Users-Group/
A
Awesome,
can
you
see
my
screen
now?
Yes,
okay,
awesome!
So
thanks
thanks,
Mike
and
Phil
for
having
me
I
am
super
excited
to
be
here
and
kind
of
share
with
you,
some
some
ideas
on
how
you
can
use
pester
to
test
your
infrastructure,
and
this
is
kind
of
a
new
format
of
a
presentation
that
I'm
going
to
try
to
do
here
so
bear
with
me.
This
is
my
first
time
doing
it.
This
is
my
first
time
using
this
this
tool
and
kind
of
this
kind
of
format.
A
So,
but
by
all
means,
if
you
do
see
something
super
interesting,
you
go
ahead
and
put
it
in
the
chat
window
and
I
may
or
may
not
see
it
but
feel
free
to
stop
me.
If
there's
a
burning
question,
you
have
to
ask:
I
am
going
to
go
over
a
couple,
different
tools,
not
super
deep
into
each
one,
but
give
a
nice
overview
of
them.
So
there
will
certainly
be
quest
deeper,
quick
or
more
time
for
deeper
questions
at
the
end
as
well.
A
Not
not
infrastructure,
but
just
traditional
software
testing
that
you're,
hopefully
already
doing
with
pester
for
power,
saw
so
first
off
it
is
in
general,
it's
an
investigation
conducted
to
determine
the
quality
of
software.
You
want
to
see
if
this
software
is
up
to
snuff
and
is
doing
what
you
intend.
It
is
meant
to
be
objective.
A
A
It
verifies
that
the
software
is
fit
for
use,
meaning
that
it
does
what
it
is
intended
to
do.
So
software
testing
verifies
one
or
more
of
the
following
attributes:
they're
the
requirements
that
the
guided
is
design
and
development.
So,
if
you
have
a
piece
of
software,
you
generally
we're
going
to
have
some
requirements
given
to
that
developers
about
what
that
software
is
intended
to
implement.
The
test
will
will
validate
that.
A
A
That
is
indeed
happening,
and
it
can
be
run
in
its
intended
environments,
meaning
I
can
test
this
software,
for
instance,
on
pram
and
I,
also
deploying
it
into
into
the
cloud
I'm
running
tests
to
make
sure
that
that
succeeds
in
both
those
cases
and
ultimately
that
into
use
the
result.
Its
stakeholders
desire.
A
So,
what
about
infrastructure
testing
infrastructure
testing
is
a
little
bit
different,
that
we're
validating
the
operation
of
a
system
or
an
application,
or
a
some
type
of
service
that
we're
offering
to
a
customer.
Some
examples
of
what
we
would
probably
be
testing
in
the
case
of
website
would
be.
Does
this
website
respond
with
an
HTTP
200
response,
given
a
certain
input?
A
A
You
the
system,
what
I
expect,
meaning
if
I,
have
an
application
with
a
certain
configuration
setting
here
and
a
different
configuration
setting
here.
I
will
run
tests
to
verify
that
those
settings
are
indeed
what
they're
supposed
to
be
and
someone
hasn't
gone
back
around
the
system
to
make
a
change.
A
Another
use
case
would
be
infrastructure
properties
and,
in
this
case
I
mean
external
things
like
Active
Directory
membership
for
certain
things
or
as
or
settings
on
storage
accounts.
You
know,
I
could
validate
that.
All
of
my
stores
accounts
have
are
enabled
for
SSL
and
are
don't
allow
anonymous
access
with
something
some
type
of
property
or
policy.
I
would
like
to
test
that,
and
ultimately
again
is
the
system
operating
to
the
customers
expectations
and
that
could
be
application
owners
that
could
be
external
customers,
internal
customers,
your
own
co-workers,
etc.
A
A
Things
change
and
things
kind
of
evolve
over
time
and
systems
get
upgraded
or
versions
get
changed,
and
our
monitoring
doesn't
always
keep
pace
and
we
need
what
we
intend
to
do
with
infrastructure
testing
is
to
make
sure
that
the
current
state,
as
that
evolves,
is
matching
what
we
expect
or
we
have.
We
change
our
expectations
as
the
service
evolves.
A
We
also
want
to
notify
us
in
some
fashion
when
those
cases
differ,
and
this
could
be
emails.
This
could
be
service
desk
tickets.
This
could
be
some
other
type
of
automation
that
runs
to
bring
that
system
back
into
the
expected
state.
But
ultimately
we
want
some
type
of
action
to
happen
when
our
states
differ.
A
Another
use
case
would
be
sanity
checks
before
and
after
changes.
This
could
be
I'm
running
or
I'm
about
to
run
some
type
of
automation.
For
instance,
let's
say
some
automated
patching
of
a
system
before
I
do
that
I
want
to
validate
that.
That
system
is
in
the
state
and
in
a
sane
state
before
I.
Do
that
run
the
automation
and
then
test
the
system
again
to
make
sure
that
I
haven't
introduced
any
kind
of
unwanted
changes
or
any
adverse
side
effects.
A
To
provide
guardrails
for
automation
again,
just
like
I
kind
of
said,
I'm
going
to
unleash
some
automation
on
a
system.
I
want
to
run
infrastructure
tests
to
make
sure
that
that
is
safe
to
do
so,
and
that
could
be
anything
from
making
sure
the
system
is
up
before
I
I
run.
This
run
this
script
against
her
or
making
sure
that
the
system
is
down
before
I
run.
The
system
I
need
to
maybe
run
a
script
to
drain
servers
off
a
load.
A
A
Look
at
some
examples
of
that
Bluegreen
deployments
kind
of
like
what
I
said
earlier.
This
is
I'm
going
to
stand
up
a
and
if
anyone
doesn't
know
what
a
Bluegreen
deployment
is,
it's
basically
I
have
a
current
system.
Let's
call
it
a
running
in
production
and
I
want
to
introduce
a
new
change
or
upgrade
a
component
of
it.
A
Bluegreen
deployment
would
be
I'm
going
to
stand
up
entirely
separate
instance
of
that
system
and
cut
over
to
it
in
some
way,
perhaps
with
DNS
or
a
load
balancer,
or
something
like
that.
A
But
before
I
do
that
I
want
to
make
sure
that
the
blue
state,
the
blue
service,
is
in
a
good
state
and
the
the
newly
deployed
instance.
The
green
service
is
in
a
current,
is
in
a
good
State
cut
over
to
it
and
run
that
test
again
to
make
sure
that
the
now
in
production,
green
state
is
servicing,
request
like
it
should
or
is
operating.
How
I
expect.
A
A
Validating
server
settings
this
is
this
could
be
similar
to
some
taxi.
We
do
with
configuration
management,
but
this
would
be
say:
I
have
some
configuration
files
on
a
system
and
that
govern
how
some
application
works.
I
would
want
to
run
some
tests
to
make
sure
that
those
settings
are
what
we
expect
and
that
someone
hasn't
gone
back
in
behind
the
scenes
and
made
modifications
to
something
I'm
sure
and
people
listening
here
can
puppy
think
of
many
different
use
cases
where
I
want
to
validate
some
type
of
server.
Setting
before
I
make
a
change.
A
A
So
before
I,
before
we
at
least
executed
the
automation
to
migrate
those
VMs,
we
basically
run
some
pester
tests
to
verify
that
that
that
system
is
is
healthy,
meaning
it's
responding
in
his
end,
this
we
were
doing
it
in
basic
state.
We're
basically
saying
is
this:
can
we
ping
the
system?
Can
we
connect
to
it
with
RDP,
or
can
we
PS
remote
into
it
to
make
sure
that
we
can
do
some
type
of
remote
management?
Can
we
if
we
knew
about
what
was
running
on
the
system?
A
A
So,
to
put
it
in
another
way
and
I
tweeted
this
out
a
while
ago,
I
thought
this
is
kind
of
humorous.
Is
that
CIC
be
pipelines
or
automation
in
general.
Allow
us
to
go
200
miles
an
hour,
and
these
infrastructure
tests
are
your
seat
belts,
airbags,
anti-lock
brakes,
traction
control,
collision
avoidance
and
autonomous
driving
systems.
A
So
you
can
go
200
miles
an
hour
without
killing
you're,
safe
yourself
or
others,
and
that's
really
what
these
tests
are
is
we're
more
and
more
introducing
a
lot
more
automation
into
how
we
operate
things,
which
means
it's
generally
lights-out
or
we
have
computers
doing
our
work
for
us.
We
need
to
have
tests
in
place
to
make
sure
that
our
automation
is
doing
what
we
expect
and
we
do
it
in
a
safe
manner.
We
can't
rely
on
our
eyeballs
or
our
eyes
and
ears
to
make
sure
the
things
are
correct.
A
And
so
can
we
do
this
with
PowerShell?
Well,
of
course
we
can
and
that's
why
I'm
here.
So,
let's
look
at
a
couple:
tester
tools
or
related
testing
tools
in
PowerShell.
The
first
one
obviously
would
be
pester
I'm
not
going
to
go
super
deep
in
the
pester.
Hopefully
most
people
here
have
a
pretty
good
understanding
of
it's.
How
pester
works
at
at
least
a
high
level.
I
will
say
that
pester
is
kind
of
the
core
component
of
what
else
I'm
going
to
show
tonight.
A
But
pester
is
a
core
piece
of
all
of
this
I'm
also
going
to
talk
a
little
bit
about
the
operation
validation
framework,
and
this
is
a
module
originally
created
by
Microsoft
and
I'm
at
least
a
couple
years,
maybe
about
a
year
and
a
half
or
two
years
ago,
I
kind
of
took
over
as
maintainer
of
it
and
what
the
operation
validation
framework
is
is
a
is
a
tool
to
bundle
and
execute
and
kind
of
discover.
Pester
tests
I'll
go
over
that
in
a
little
bit
the
assert
module
and
people
don't
know
what
this
is.
A
This
is
a
this:
is
a
PowerShell
module
that
kind
of
provides
some
useful
custom
assertions
functions
that
you
can
run
and
pester
if
you're
doing
some
type
of
more
advanced
tests
and
it's
not
a
requirement,
but
it
is
a
cool,
a
good,
a
good
tool
to
at
least
know
about
if
you're,
finding
your
your
pester
tests
are
becoming
more
and
more
complicated
to
test
something
or
the
test,
some
type
of
use
case,
you
can
potentially
look
at
the
assert
module.
Let's
see
if
that
would
help,
simplify
it.
So
major
tests,
PS
health
Z.
A
Watchman
watchman
is
another
tool
I
released
a
while
ago.
That
kind
of
also
plays
on
this
idea
of
using
pester
and
operation
validation
framework
and
allows
you
to
not
only
run
tests
and
define
what
tests
are
executed
or
from
what
modules,
but
also
what
to
do
when
those
tests
pass
or
fail.
So
I
can
run
some
custom.
A
A
You
all
right,
so,
let's
dive
a
little
bit
into
pester.
It
is
the
ubiquitous
test
and
mock
framework
for
PowerShell.
We
typically
will
use
pester
to
validate
that
our
PowerShell
scripts
and
and
modules
and
functions
do
what
they
we
expect
them
to
do
so
we'll
run
a
pester
test
to
validate
some
import
or
validate
some
output
or
validate
that
a
function
execute
something
on
a
remote
system
in
the
correct
way.
A
A
Here
is
a
very
simple
function
that
will
say
this
called
get
answer
the
universe
and
all
this
function
does
is
return
the
number
42,
because
we
all
know
that
that
is
the
answer
to
the
universe.
How
would
we
test
that?
Typically,
what's
with
pester,
is
this
example
here
we'll
we'll
write
a
pester
script?
Typically,
it's
whatever
the
function.
Name
is
test.
Ps1
will
load
in
our
our
script
via
dot
sourcing
and
we'll
use
the
describing
context
blocks
from
pester
to
kind
of
order.
A
Our
tests,
and,
in
this
case,
I'm,
going
to
show
you
one,
but
because
this
function
really
only
does
one
thing.
What
we're
going
to
do
is
describe
an
it,
and
this
is
what
our
tests
name
is
and
we're
going
to
say.
The
test
is
the
answer:
yeah
nope
got
some
feedback
that
the
answer
is
42
inside
the.
If
block
will
execute
that
function,
capture
the
output
and
we'll
pass
that
into
an
assertion,
function
called
should
and
validate
that
that
output
is
indeed
42,
and
if
that
was
not
the
case,
this
should
would
throw
an
exception.
A
Pester
would
see
that
and
produce
a
failing
test
and
the
type
of
output
you
would
see
with
pester
would
be
something
similar
to
this.
Where
we're
going
to
execute
our
tests,
you
can
see
it
executing
showing
our
describe
block
in
a
context
and
running
our
ant
car.
Our
it's
a
statement.
The
answer
is
42,
and
that
is
indeed
true.
So
the
test
pass.
A
So
the
operation
validation
framework
like
I,
said
earlier.
This
is
a
framework
originally
released
by
Microsoft
and
what
the
idea
of
this
is
it
packages
up
pester
tests
into
a
module
in
a
certain
folder
structure
and
the
reasoning
behind
that
is
because
now
that
they're
in
a
PowerShell
module
you
instantly
have
versioning
capability
via
PowerShell,
via
module
versions.
A
This
framework
is
fairly
simple
in
concept,
in
that
it
only
has
two
publicly
facing
functions:
get
operation,
validation
and
invoke
operation
validation,
so
get
operation
validation.
What
this
function
does
is
it
enumerates
all
the
PowerShell
modules
inside
your
PowerShell
module
path
on
your
system,
looks
for
all
those
modules
and
does
a
inspection
of
them
and
looks
for
pests
or
tests
that
are
in
a
a
certain
folder
structure,
and
this
is
what
that
folder
structure
looks
like
here
we're
in
the
case.
In
this
case
we
have
a
top-level
folder.
A
This
is
our
actual
module
name,
apt
OVF,
and
we
have
our
typical
manifest
file
and
PowerShell
module
file.
But
what
the
OVF
framework
expects
is
this
folder
called
Diagnostics
and
inside
that
Diagnostics
folder
you're,
going
to
have
two
subfolders,
comprehensive
and
simple
and
inside
those
is
where
you
would
put
your
passer
tests.
There
is
a
better
design
to
test
the
operation
of
some
system.
A
The
difference
between
comprehensive
and
simple
is
that
oftentimes,
when
we're
running
tests
to
valet
a
system,
some
of
those
tests
could
be
very
quick
to
execute,
perhaps
I'm
doing
a
get
on
a
API
endpoint.
That's
returned
very
quickly
or
I'm
running
a
more
a
longer
performance
based
test
or
I
want
to
run
something
for
a
few
minutes
or
maybe
an
hour
and
I
want
to
capture
all
those
results
and
kind
of
determine
the
health
of
assistant
base
based
on
some
long
running
tasks,
but
I
mean
I
want
to
run
all
of
those
tests.
A
All
the
time
and
the
comprehensive
and
simple
is
a
way
to
separate
those
out
into
into
different
types
of
test
categories
you
can
see.
In
this
example,
I
have
a
handful
of
pestered
tests
named
performance
for
a
comprehensive
test,
and
a
couple
in
the
simple
folder
called
app
memory
and
services
and
I'll
show
you
a
little
bit
about
what
these
look
like.
A
So
the
app
tests.
This
is
a
very
simple
one
and
that
this
tester
script
is
basically
going
to
test
that
in
this
case,
the
partial
gallery
website
responds
and
it
responds
with
a
status
code
at
200.
And
if
people
don't
know
this
feature
of
pester
is
that
you
can
pass
in
pester.
You
know
just
like
a
normal
partial
script,
you
can
have
a
parameter
block
at
the
very
top
and
you
can
pass
in
parameters
to
a
script.
A
But
some
people
don't
know
is
that
pester
is
also
able
to
pass
in
values
into
that
parameter
block.
So
you
can
have
a
more
generic
pester
test,
maybe
with
some
default
settings,
but
then
you
can
tell
pester
to
override
those
settings
with
other
values.
So
in
this
case,
I
have
an
app
test.
That
tests
the
PowerShell
gallery,
but
I
can
also
use
pester
and
insert
a
different
URL
or
a
different
status
code
and
I.
Don't
have
to
change
my
test.
I
can
just
pass
it
different
values
in
the
operation.
A
A
There's
a
little
bit
more
detailed
example
in
this
case
I'm,
going
to
use
pester
to
test
that
a
handful
of
server
window
services
are
started,
and
here
I've
used
another
feature
of
pester
with
a
tag.
If
you
can
see
here,
I've
used
a
categorized
certain
tests
as
critical
and
others
as
important,
and
this
this
is
kind
of
an
arbitrary
grouping
of
services.
In
this
example.
But
you
could,
you
could
probably
see
a
use
case
where
I
would
like
to
use
tags
to
categorize
certain
tests
and
pester.
You
can
also
run
tests
based
on
tag.
A
Ovf
framework
also
allows
you
to
execute
test
based
on
tag
or
everything,
but
a
certain
tag,
and
in
this
case
I'm
going
to
categorized
a
couple.
Services
is
critical
and
important
and
I've
gone
ahead
and
looped
through
an
array
and
I'm
going
to
run
an
it
block.
Two
to
validate
that.
That
service
is
started.
A
Example
of
what
that
execution
would
look
like
with
OVF.
You
see
at
the
top
here
we're
going
to
run
the
use
to
get
operation
validation,
function,
passing
a
module
name
called
my
OVF
and
we're
going
to
get
a
collection,
backup
tests
of
test
objects.
We
can
also
pass
that
collection
of
objects
in
to
invoke
operation
validation
to
actually
execute
them
internally.
What
invoke
operation
validation
does
is
actually
takes
all
those
objects
and
is
Iran's
pester
and
invokes
pester
to
run
those
files.
A
It
does
a
little
bit
of
massaging
of
the
pester
output
and
term
returns.
You
back
some
objects.
It
does
also
allow
you
to
see
the
native
pester
output
is
that's
something
that
you're
interested
in.
You
can
also
with
invoke
operation,
validation
or
that
or
the
get
command.
You
can
also
pass
in
tag
or
module
version
to
be
more
specific
about
what
exactly
the
tests
are
going
to
run
are,
and
here
you
can
see
in
this
example
that
I've
run
this
all
the
the
tests
inside
this.
A
This
OVF
module
every
one
of
them
passed,
but
the
bottom
one
here
where
I
have
winter
ramp
stopped,
and
then
you
can
take
this
output
and
bundle
this
in
your
existing
automation
to
make
some
type
of
decision
like
do
I
want
to
patch
this
server
or
or
do
something
on
the
server.
Knowing
that
one
of
my
infrastructure
tests
have
failed.
A
So
the
assert
module
it's
a
set
of
advanced
assertions
for
pester
to
simplify
test
authoring,
and
it
has
probably
a
couple
dozen
different
functions.
I've
only
listed
a
few
of
them
here,
but
what
assert
does
is
you
have
some
once
you
may
find
yourself
doing
some
rather
exotic
comparisons
of
objects
or
of
collections
of
objects
to
make
sure
that
you're
expected
state?
Your
expected
state
is
matching
your
current
state
here,
I've
listed,
you
can
do
an
assert
contain,
which
does
some
advanced
string
comparisons.
A
A
Here's
an
example
of-
and
this
is
it
this
is
a
simple
simplified
version
of
what
I
actually
do
in
production,
but
here
is
a
example
of
a
infrastructure
type
test
that
would
also
use
the
assert
module.
But
what
this
is
doing
is
it's
testing
our
current
list
of
domain
administrators
in
Active,
Directory
versus
some
pre-approved
list
and
I've.
A
Basically,
how
bundled
those
into
two
separate,
arrays
and
I'm,
using
pester
to
validate
that
the
current
list
of
domain
AB
administrators
is
matching
what
is
actually
approved
in
reality,
this
would
be
a
much
more
evolved
test,
but
here's
a
good
example
of
using
the
assert
module
to
do
a
comparison
of
one
array
versus
the
other
and
also
another
handy
feature
of
assert.
As
you
can
use
these,
you
can
specify
these
custom
failure
strings
and
you
can
see
that
here
with
this
fail
message:
object
or
there
this
string.
A
What
this
looks
like
is
this:
so
if
I
run
tester
against
that
script,
I
can
see.
I
have
three
domain
administrators
approved
and
in
my
example
here
of
getting
the
actual
list
of
domain
administrators
I
have
four
and
what
you
would
see
with
pester
and
insert
module
is
something
like
this,
where
the
custody
assertion
run
would
actually
show
you
how
many
unauthorized
domain
administrators
there
were,
and
it
would
actually
list
them
all
in
order.
B
A
So
P
s
health
Z,
like
said
earlier,
this
is
a
another
module
that
I
created
that
I
was
taking
doing
some
reading
on
different
ways
of
testing
systems
and
can
came
up
with
this.
Kyra
was
introduced
to
this
pattern
here
a
couple
years
ago,
and
this
is
called
the
health
endpoint
monitoring
powder
and
you'll
see.
This
is
not
a
new
pattern,
but
you'll
see
this
used
more
and
more
I
think
as
especially
as
containers
start
evolving
and
getting
more
common.
What
this
is
is
a
form
of
black
box
testing
of
a
system.
A
What
that
will
trigger
is
some
type
of
internal
health
check
system
to
get
invoked
to
check
the
health
of
the
stores
the
database
do
I
have
appropriate
amount
of
database
allocated,
do
I
have
enough
free
disk
space
or
all
my
services
running.
Maybe
do
some
quick
performance
based
tests
to
see
if
I
am
responding
or
different
components
of
my
system?
Are
they
responding
in
a
proprietary,
we'll
return?
Basically,
a
JSON
response,
saying
yes,
I
am
healthy.
A
Here
are
some
attributes
of
what
the
health
check
that
I
performed
and
you
mister
monitoring
agent
can
deal
with
the
with
that.
What
you
will-
and
this
is
a
nice
pattern
to
implement
when
you
have
many
des
separate
types
of
systems
out
there-
that
would
be
impractical
to
try
to
mom
with
a
single
tool
or
single
agent.
You
just
rely
on
that
application.
A
A
A
A
A
This
type
of
pattern
is
probably
not
the
best
suited
for
for
those
short-lived
instances.
This
is
Matt.
This
is
really
meant
for
long-lived
servers
or
containers
that
are
there
to
longer-lived,
and
you
want
to
be
able
to
test
that
the
internal
health
of
that
system
without
actually
having
to
know
what
the
internals
of
the
system
are.
Does
that
make
sense
so
like.
A
Right,
it's
kind
of
an
abstraction
of
the
of
the
system.
My
monitoring
agent
only
needs
to
know
if
I
want
to
determine
the
health
of
this
server
over
here.
I
just
hit
this
HTTP
endpoint
I'm
going
to
get
back
a
response
and
I'll
parse
it
and
then
determine
if
that,
if
that's
healthier
or
not,
but
I,
don't
need
to
know
the
internals
of
that
and
I.
Maybe
I
can
rely
on
the
application
team
who
owns
that
system
to
be
in
charge
of
that
and
me
as
an
application
or
a
server
master
I.
B
A
Yeah-
and
this
is
this,
this
pattern
or
this
concept-
identity,
I-
certainly
didn't
come
up
with
this,
but
this
is.
This
is
more
and
more
common
in
containers
and
you'll.
Have
this
with
the
sidecar
pattern
pattern
in
containers?
Will
you
have
your
application
in
one
container,
you'll
bring
up
this
sidecar
container
next
to
it
that
is
maybe
running
a
monitoring
tool
of
some
type
and
external
systems
that
they
want
to
validate.
The
health
of
the
container
are
actually
going
to
query
that
a
health
endpoint
on
that
sidecar.
B
Also
so
I
was
asking
some
questions
of
the
group.
While
you
were
chatting
I,
don't
know
if
you
had
a
chance
to
see
any
of
them,
let's
basically
kind
of
get
a
feel
of
who
is
using
pestered,
a
and
I
think
you
probably
would
be
not
shocked
to
hear
that
it's
not
widespread
usage
people
are
just
starting
to
get
started
with
pester,
so
my
question
would
be
because
this
is
me
I'm
interested
in
pest,
but
I
haven't
done
anything
with
it
when
we're
talking
about
infrastructure
as
code
with
pesto
testing.
A
You
certainly
I
want
to
say
you
need
a
master
pester.
You
definitely
need
a
working
knowledge
of
it.
Cuz
everything
is
based
on
it,
so
I
should
be
able
to
and
have
a
working
knowledge
of
PowerShell
in
general.
I
would
say
your
your
pester
tests.
I
mean
you
need
to
know
how
to
describe
works
and
context
and
what
it
statement
does
and
that's
basically
what
pester
is
and
then
what's
inside
that
it
statement
is
just
power,
so
I
get
a
something
and
I
pipe.
B
A
A
So
I
would
say
that
you
you,
you
don't
need
to
know,
you
don't
need
to
know
the
intricacies
of
mocking
necessarily,
but
you
do
need
to
have
a
working
knowledge
of
PowerShell
and
they,
you
know
if
you
kind
of
browse
through
other
people's
blogs,
about
how
to
do
pester
or
you
can
buy
the
pester
book.
That
would
give
you
a
nice
working
knowledge
of
how
to
do.
Pester.
I
would
say
you
spend
a
couple.
A
You
know
days
like
you
know,
familiarizing
yourself
with
that,
or
maybe
looking
at
other
people's
code
out
there
on
github
of
how
they've
done
pester
tests
just
for
powerful
modules.
Most
of
those
concepts
can
all
be
applied
to
how
to
do
infrastructure
tests,
because
really
the
only
difference
is.
Is
that
it
with
an
infrastructure
test,
I'm
testing,
the
state
of
some
system,
not
the
input
or
the
output
of
a
of
a
function
necessarily
so
that
makes
sense.
Yeah.
B
Then
my
question
related
in
the
fashion
that
we
will
take.
Somebody
gets
the
same
question
so
if
I
still
see
it,
you
know
you
write
PowerShell
scripts
and
you
run
scripts
and
modules
and
stuff
like
that.
But
then
this
is
the
idea
that
you
then
create
modules
that
are
effectively
just
a
bunch
of
scripts
that
do
that.
Go
in
test,
so
you'd
write
a
function
that
nothing
but
a
tester,
and
so
do
you
do.
B
Is
that,
like
that,
the
workflows
to
simply
just
call
like
the
pester
test,
then
just
let
it
go,
do
it
stuff
and
that
things
like
same
things
kind
of
DSC
and
how
does
that,
like,
hey
I,
want
to
just
validate
that
all
these
servers
have
these
services
on.
So
then
you
would
write
a
script
that
is
effectively
just
running
this
test
that
I'm
not
sure
how
that
inception
works.
A
Well,
I
would
say
that
the
the
kind
of
the
difference
between
this
testing
and
with
DSC
is
that
DSC
obviously
is
going
to
take
an
action
to
bring
that
state
back
into
whatever
desired
state.
You
want
it
in.
So
if
a
service
is
supposed
to
be
up
and
the
service
has
stopped,
DSC
should
be
starting
that
service
again.
A
This
is
a
so
this
is
GM.
Infrastructure
testing
is
not
necessarily
intended
to
actually
make
changes
to
your
system.
It's
really
just
to
notify
you
of
what
the
state
is
and
if
that
state
matches
what
it's
supposed
to
be.
So
you
would
say,
I'm
going
to
run
a
automation
to
patch
a
server
I'm
going
to
invoke
the
OVF
module
for
that
application
to
test
basically
provide
some
type
of
run,
some
type
of
smoke
test
for
that
application
to
say.
A
Okay,
it's
running
in
some
base
state,
it's
probably
safe
to
proceed
with
patching
it
or
maybe
I
did
patch
it
and
now
I'm
going
to
run
the
OVF
module
suite
of
tests
again
that
are
customized
for
that
application
run
its
smoke
test
after
the
patching
to
verify
that
you
know.
Indeed,
after
patching,
the
system
is
still
working.
B
Okay,
yeah,
so
that's
kind
of
where
I
was
kind
of.
So
it's
almost
like
a
action
step
in
your
workflow
as
to
okay,
call,
call
instantiate
the
tester
tests
or
the
OVF
tests.
As
a
group
and
say:
okay
do
this,
then
you
can
do
your
work
and
then
do
it
again
to
make
sure
almost
you
effectively
didn't
break
anything.
That's.
A
It's
been
a
while
that's
exactly
what
I
kind
of
like
in
OVF
modules
to
scum
management
packs,
and
you
would
have
a
management
pack
for
exchange
and
one
for
ad
and
one
for
sequel,
server
and
one
for
application
XYZ
for
rinse
and
repeat
for
every
single
application.
They
could
potentially
have
their
own
OVF
module
specific
to
that
application,
and
you
could
also
have
OVF
modules
that
are
testing
generic
sequel
settings
like
the
sequel
services
are
up
or
Active
Directory
services
or
running.
A
A
One
of
the
advantages
that
I
have
with
everything,
either
in
pester
or
just
in
PowerShell
in
general,
is
that
it's
all
code
that
you
can
see
that's
visible
to
me
and
that
I
can
put
in
source
control
a
lot
right
next
to
the
application
and
I
think
that's
a
really
important
concept
to
kind
of
embraces
the
monitoring
and
tests.
Foreign
applications
should
be
living
right
next
to
the
source
code
or
the
configuration
of
that
application.
A
I've
run
into
a
lot
of
cases
where-
and
this
is
this
has
been
true
for
from
what
I
think
for
most
companies
is
you'll.
Have
many
different
application
teams
and
you'll
have
a
core
systems:
engineering,
a
platform,
engineering
system
and
type
team
who
kind
of
owns
monitoring
and
they're
supposed
to
magically
know
how
every
single
application
in
their
environment
works,
and
that's
never.
The
case.
B
B
This
isn't
necessarily
replacement
for
the
tools
that
are
in
place,
but
you
can
build
tools
that
can
do
things
that
the
existing
tools
can
or
you
don't
have
the
ability
to
do
the
configuration
to
make
it
more
customized,
and
maybe
just
a
simple
up/down
notification.
That's
right
and
I
think
we
might
go
ahead.
Jonathan
Brandon
I
pose
to
that
initially.
I
appreciate
your
response.
That's
essentially
how
I'm
using
it
right
now.
I
just
want
to
hear
your
perspective
on
it.
B
We
write
scripts
for,
like
you,
know,
80
health
checks
every
morning
and
we
code
them
using
pester
right.
So
that
was
really
one
of
the
questions
I
had
because
my
teammates
are
like.
Why
would
we
want
to
write
something
in
pester
pester
check,
infrastructure
check?
We
already
have
solar
winds
and
my
thought
was,
but
we
we
cut
everything
ourselves
and
we
know
what
the
check
we
don't
have
to
work
with
a
team
for
weeks.
Every
email
for
them
to
you
know
then
make
it
work
and
SolarWinds
blah
blah
blah.
So
that's
that's
really.
A
Right
and
kind
of
to
expand
on
that
one
of
the
nice
things
about
having
these
checks.
You
know
in
a
more
generic
framework
like
plane,
powers
of
the
pestered
versus
hitting
a
lot
of
custom
logic
inside
tools
like
Scala.
More
SolarWinds
is
that
I
can
switch
monitoring
platforms
fairly
easily
when
all
of
those
systems
are
all
what
they're
essentially
doing
is
just
running
a
pester
script.
A
So
if
I
have
solar
ones,
ruining
that
pestis
script
and
I
choose
to
change
to
a
different
monitoring
tool
that
the
new
monitoring
tool
can
just
as
easily
run
that
same
pester
script,
ID
on
the
Reid
tool,
a
redesign,
how
I'm
doing
monitoring
from
the
ground
up
by
most
of
my
logic,
is
already
there
and
is
portable
I've
done
the
same
thing
where
in
my
case,
I
was
had
some
checks.
Inscom
and
I
was
evaluating
sensu.
A
What
I
was
what
I
was
doing
is
that
I
would
also
have
a
partial
script
called
smoke
test
in
a
known,
locate
and
deployed
on
to
the
server
and
sensu
and
chef
would
detect
if
that
file
was
present
and
if
it
was,
they
would
instruct
sentry
to
run
or
to
execute
that
file
every
five
minutes
or
whatever,
and
that
script
would
do
whatever
needs
to
do
sense,
who
doesn't
care
what
that
script
was
actually
doing.
It
only
cares
about
the
output.
The
death
script
returns.
So
sensor
has
a
certain
output.
A
A
The
script
was
running
OVF
to
go,
execute,
mean
OVF,
module
tests
and
kind
of
massage
them
and
determine
if
they
fail
and
if
they
did
return
a
certain
exit
code
to
sensu.
But
since
you
was
oblivious
to
what
was
going
on
internally,
it
was
just
it
was
just
saying:
I
see
a
smoke
test,
script
I'm
going
to
run
it
every
five
minutes,
so
I
could
have
a
generic
rule
in
chef
and
sensor
to
say.
If
you
have
a
smoke
test,
you
I'm
going
to
run
it.
A
What
you,
a
policeman
team,
decide
to
do
how
to
monitor
your
system
is
up
to
you
as
long
as
you
can
form
to
the
requirements
of
of
sensu
in
its
output
format.
But
what
you
do
in
that
smoke
test
is
up
to
you
and
I
enabled
them
to
to
help
own
their
monitoring
and
not
rely
on
the
central
application
team
or
essential
as
19-2
to
know
the
ins
and
outs
of
every
application,
because
that's
not
feasible
hope
that
answered
so.
B
B
Makes
up
a
bill?
We
a
work,
we
actually
just
I,
just
integrated
from
scripts
and
festered
scripts
into
Jenkins
and
Jenkins
for
us
is
just
simply
excluding
these
scripts
to
launch
everyday
at,
like
9
a.m.
right
for
an
overall
ad
health
check.
So
that's
what
we
did
an
integrated
it
with
our
internal
git,
repo
and
all
that
good
stuff,
so
that
that's
worked
pretty
good
for
us.
A
A
Use
Jenkins
for
that.
What
we've
also
done
this
is
wasn't
necessarily
to
monitor
the
health
of
systems,
but
like
it
was
something
with
that.
Active
Directory,
the
domain
administrator
check
I,
was
running
that
in
git
lab
with
get
lab
CI,
as
is
basically
a
scheduled,
build
and
I
was
running.
I
had
our
approved
list
of
domain
administrators
in
a
certain
git
repo,
basically
as
a
text
file
that
only
certain
people
could
modify
and
in
this
other
repo
I
was
running.
A
This
check
to
read
that
list
and
also
compare
it
with
what
was
actually
in
Active
Directory
fail
if
they
don't
match
and
I
was
just
run
as
a
scheduled.
Ci
build
in
git
lab
every
day
and
I
could
also
hand
that
hand
those
results
to
auditors
and
say
here.
You
know
producing
kind
of
a
pretty
report
or
basically
just
a
CSV
file
and
saying
here
is
our
daily
compliance
audit
check
for
domain
administrators
and
even
give
them
the
ability
to
run
that
build
ad
hoc.
A
And
we've
kind
of
started
to
extend
that
that
same
concept
to
other
different
types
of
compliance
checks
and
they're.
Basically,
they
all
get
boiled
down
into
their
some
pester
script
running
either
scheduled
in
get
lab
or
in
bsts
or,
and
you
could
do
in
Jenkins
or
any
other
system
that
basically
will
kick
off
that
script.
For
you.
A
A
You
would
start
healthy.
You
provided
a
port
obstinately
you
provided
a
HTTP
path.
In
this
case
it
would
be
health,
so
it
would
be
like
localhost
port
8080
slash
you
could
pass
through
and
I
were
to
return.
You
back
an
object,
but
start
with
Health
Z
listener
is
doing.
Is
it's
basically
running
a
PowerShell
HTTP
server
as
a
separate
job,
separate
PowerShell
job?
A
You
could
also
use
the
get
healthy
listener
command
to
return
any
running
jobs
in
game.
You
can
even
run
multiple
sensor
there
in
PowerShell
jobs.
You
can
have
multiple
listeners
running
on
different
ports
with.
There
are
other
parameters
with
the
start.
Healthy
listener
command,
so
you
can
pass
in
a
token
or
provide
a
certificate
thumbprint
that
you've
already
installed
on
the
system.
If
you
want
to
enable
SSL
I
with
caveat
that
that
only
works
on
Windows
on
a
Mac
SSL
support
doesn't
work
right.
Now.
A
A
So
here
is
how
you
would
actually
use
a
healthy
or
an
example
of
it,
so
I
have
healthy
listening
locally
on
port
8080
path.
Health
I
can
basically,
this
using
vocal
rest
method
to
query
that
endpoint
and
give
me
back
a
JSON
response,
and
by
default,
health
Z
does
not
actually
execute
any
OVF
tests.
It
requires
you
to
provide
a
extra
query,
parameter
specifying
the
tests
or
the
module
OVF
module
name
of
the
test
XQ,
and
here
it's
also.
A
A
So
if
we
actually
look
whoops
because
I
was
test,
so
we
can
also
look
at
the
available
tests
and
you
can
see
I
have
four
here
from
the
all
from
the
single
module
OVF
Windows
Server,
this
name
here,
maps
to
the
described
block
of
pester.
So
if
I
have
a
describe
block
called
logical
disks,
that's
what
gets
reflected
here
is
is
the
the
name
of
that
test.
A
So,
let's
look
at
that
result
a
little
bit
so
in
this
case,
this
one
did
not
pass
and
we'll
show
you
how
long
the
test
took
the
XQ,
and
this
took
just
over
one
second,
the
list
of
available
or
the
tests
that
it
executed,
and
then
these
are.
These
two
properties
here
are
much
bigger
collections
of
the
actual
pester
test
results
and
I've
also
grouped
just
two
failing
ones
into
a
separate
property
really
out
of
convenience.
A
So
if
we
look
at
that
failed
test
collection,
is
this
an
example
of
what
you
would
see
so
you'd
see
the
the
test
name
and
this
maps
to
the
name
of
the
it
block?
Tester
give
you
the
module
that
that
test
came
from
its
result.
It's
describing
context
the
ultimate
file
path
to
where
that
test
was
executed
and
any
kind
of
output
from
pester
for
that
test.
A
A
A
Opf
and
pester
results
when
like
I
was
mentioning
earlier
pester
by
default
anyway,
does
not
take
an
action
based
on
test
passing
or
failing.
It
just
shows
you
that,
yes,
they
did,
or
they
did
not.
What
watchman
is
intended
to
do
is
actually
take
action
based
on
those
tests
passing
or
failing,
and
it
plays
on
the
concept
of
OVF,
so
it
what
what
watchman
will
do
is
it
will
inspect
your
system
for
installed
obf
modules
and
run
those
tests.
A
It
really
only
has
two
commands,
get
watchman
test
and
invoke
watchman
test
and,
like
I
said
earlier,
what
it,
what
watchman
is
really
intended
to
do
is
to
take
action
based
on
those
tests,
so
in
Washington
I
call
them
notifiers,
and
what
these
are
are
are
different
actions.
You
can
take
like
sending
an
email
based
on
a
failing
test
or
writing
to
the
event
log
writing
to
some
text-based
log
file
executing
a
arbitrary
partial
script
that
you
define
or
even
sending
the
slack
message
or
sending
to
syslog.
A
You
would
then
run
a
notifies
block
and
tell
it
n
number
of
actions
to
take
based
on
those
tests,
and
you
can
provide
it
a
additional
qualifier
of
that's
called
when
witches
run
the
log
file
notifier
when
the
test
paths
when
it
fails
or
when
both
are
when
either
those
happen.
So
there
may
be
cases
where
I
want
to
run
a
extra
powershell
script
or
to
write
to
a
log
file
regardless
of
that
test
fails.
A
But
I
only
want
to
send
a
slack
message
when
the
test
fails
or
something
like
that,
and
here's
an
example
of
what
the
required
properties
would
be.
If
you
wanted
to
run.
Have
this
send
its
lock
message,
so
you
would
need
a
slack
a
web
token,
provided
the
channel
name
to
send
it
to
and
a
little
bit
of
properties
here
to
define.
What
that
message
looks
like
and
at
the
bottom
here
is
how
you
would
go
ahead
and
get
those
tests,
so
you
would
run
get
get
watchman
test,
pass
it
the
path
to
that
file.
A
A
B
A
So,
with
this
an
example,
I
can
also
have
hot
spot.
I
can
have
a
custom
pop
spot
command.
That
would
query.
Do
an
invoke
rest
method
on
that
health,
endpoint
parse
the
results
and
give
those
back
to
slack
so
I
can
run
an
ad
hoc
test
within
slack
or
I,
can
give
this
command
and
have
anyone
I
deem
necessary,
be
able
to
execute
this
command
and
slack
to
test
the
systems
that
they
need
to.
A
A
I'm
going
to
validate
the
the
domain
admin
list
in
production
is
exactly
what
I've
defined
it
or
someone
else
maybe
has
defined,
who
are
the
approved
domain
administrators
and
I
can
run
this
test
daily
hourly
every
minute
if
I
want
to
like
someone
was
saying
either
with
Jenkins
or
with
SolarWinds
or
with
any
other
type
of
scheduling
or
orchestration
tool.
I
can
run
these
tests
and
alert
me
when
any
of
them
fail.
A
And
here's
a
this
is
more
of
a
POC.
I
did
I
haven't
run
this
in
production,
but
this
is
an
example
of
combining
a
couple
different
technologies
together
to
kind
of
give
you
a
pretty
dashboard
kind
of
reimagining.
What
how
monitoring
could
look
like.
So
this
is
a
graph
on
a
dashboard
where
I
have
an
agent
running
on
a
system
to
gather
performance
based,
metrics
and
store
them
in
a
time
sory
database
and
in
this
case
I,
was
using
in
flux
DB.
A
A
So
the
the
performance
of
the
CPU
or
the
amount
of
disk
space
on
a
system
really
is
not
all
that
important.
It's
interesting
to
know
for
forensics
use
cases
or
maybe
for
troubleshooting,
but
it
doesn't.
The
fact
that
my
CPU
is
90%
does
not
tell
me
if
my
application
is
slow
or
is
operating
completely
normally.
A
So,
if
I
have
a,
if
my
memory
is
90%
CPU,
maybe
that's
bad,
but
if
it's
a
sequel
server,
that's
completely
normal
and
it's
what's
exactly
what
it
should
be
doing
so
alerting
on
those
types
of
metrics
is
test
is
not
that
valuable.
It's
better!
It's
much
better
to
run
tests
to
test
what
the
actual
user
will
see
from
that
system.
A
So
is
the
application
returning
a
website
respond
WebP
responds
in
less
than
one
second
or
something
like
that,
but
the
fact
that
that
web
server
is
50%,
CPU
or
is
90
percent
on
memory
does
not
mean
that
that
applications
about
healthy.
That
could
be
completely
what
that
thought
to
normal.
For
that
application.
Don't
alert
me
on
that
alert
me
when
my
my
service
level
metrics
start
to
exceed
what
we've
designated.
A
A
You
could
say
you
know
it
does
the
server
respond
to
a
ping
and
that
could
be
a
very
bare-bones
up/down
type
test
for
the
system
and
then
iterate
on
that
as
you
learn,
if
you
have
time
and
have
you
as
you
learn
about
how
that
application
behaves,
what
are
the
good
external
types
X?
You
can
run
on
that
system
to
kind
of
gauge
this
performance
and
then
once
you've
done.
A
A
Those
tests
should
also
be
in
version
control
and,
ideally
right
next
to
the
application
code
or
the
configuration
management
code
for
that
application.
If
you're
doing
that,
I
found
that
it's
much
easier
and
much
more
likely
that
your
tests
will
be
accurate
if
they're
right
next
to
the
application
being
deployed.
This
is
kind
of
the
similar
concept
to
documentation.
The
further
documentation
is
from
the
system,
the
more
likely
that
it's
going
to
be
out
of
date,
use.
A
Configuration
management,
if
appropriate,
to
deploy
those
tests
into
your
environment,
don't
or
please
don't
RDP
onto
a
server
and
manually
drag-and-drop
script.
Files
onto
the
system
use
things
like
DSC
and
chef
and
puppet
to
have
more
control
over
the
configuration
of
your
systems.
So
putting
things
in
get
deploying
them
to
systems
with
configuration
management
is
a
plus.
A
Now
that
they're
in
git
or
they're
in
source
control
and
they're
deployed
with
configuration
management
now
it
makes
it
easier
for
your
application
owners
to
author
tests-
and
this
is
like
I-
was
saying
earlier.
Oftentimes,
the
the
role
of
monitoring
is
put
on
the
system
level
team
and
those
teams
generally
don't
have
the
best
context
for
how
to
monitor
business
applications.
They
may
have
good
contexts
to
monitor
infrastructure,
ad
and
sequel
server
and
things
like
that,
but
not
line
of
business
type
applications.
A
Typically
application
owner
is
business
analyst
or
something
or
system
analysts
who
live
in
that
application.
Day-To-Day
know
exactly
what
to
check
for
to
see
if
that
system
is
healthy.
The
a
system
administrator
for
people
removed
from
that
process
is
never
going
to
have
that
knowledge
so
expecting
that
person
to
figure
out
how
to
monitor
that
system
is
really
not
the
best
scenario,
so
think
of
ways
that
you
can
make
the
the
task
of
out
of
testing
easier
and
more
consumable
by
an
application
order
to
do.
A
B
B
So
my
question,
for
you
is
I
know
we
were:
did
you
come
to
a
place
that
had
some
sort
of
pests
there
and
infrastructure
testing
in
place,
or
did
you
set
that
up
at
the
place
and
the
reason
I
ask
that
is
how
much
work
did
you
have
to
do
to
bring
the
rest
of
the
business
around
support?
If
you
want
to
do
these
types
of
taxes,
so.
A
I
will
say
that
we're
strong
we're
still
on
the
path
to
getting
all
these
to
getting
our
stuff
monitored
in
a
more
modern
way,
I
put
in
extra
tests
for
things
like
compliance
things
and
maybe
three
years
ago,
and
that's
now
the
primary
way
that
we
kind
of
do
compliance
type
tests
and
more
we're
even
getting
that
extended
to
non-windows
system.
So
we'll
we'll
test,
basically
we'll
get
an
export
of
some
system,
we'll
run
a
pastor
test
to
it
to
validate
that
expected
state
and
we'll
provide
that
to
the
auditor.
A
So
that's
becoming
the
more
and
more
than
the
standard
way
that
we
do
checks
and
once
we
did
that
with
compliance
tests,
we're
doing
that
more
and
more
with
things
in
Azure,
so
we're
like
I
was
saying
earlier,
we're
doing
validation
of
so.
If
we
have
a
policy
that
says,
storage
accounts
must
not
allow
anonymous
access.
That's
a
fairly
easy
pester
script
to
write,
to
enumerate
all
the
storage
accounts
and
just
check
them,
or
any
of
them
allow
an
anonymous
access
if
they
are
fail
and
alert.
A
Someone
about
that
kind
of
rinse,
repeat
those
for
more
and
more
systems.
I
will
say
that
application
level
testing
is
going
to
be
is
going
to
be
harder
and
we're
not
there.
Yet
it's
easier
to
do
with
infrastructure
like
system
related
things
like
sequel
server,
echo
directory,
VMware
what-have-you,
it's
more
difficult
to
do
it
with
applications,
because
each
one
is
different
and.
B
A
B
Cool
so
guys
with
that,
we
are
finishing
up
here.
We
went
long
tonight
which
is
completely
fine
because
there's
great
content
but
feel
free
to
unmute
your
mic.
If
you
got
questions
and
then
you
want
to
say,
if
not,
we
will
be
posting
this
on
a
YouTube
channel
and
github
repo
will
be
available
to
you
guys
shortly.
But
if
you
have
anything,
you
want
to
ask:
go
for
I.
A
A
You,
hopefully,
everyone
got
something
out
of
that
at
least
gotten
expired
on
how
to
you
know
how
they
could
apply
some
of
these
concepts.
They
don't
necessarily
need
to
use
any
of
these
tools.
Hopefully
they
will
use
pester,
but
they
don't
use
anything
else.
As
long
as
you
know,
we
use
something
to
test
well,.