---
title: 'DPC2020: My Top 10 PHPUnit Tips & Tricks - Juliette Reinders Folmer'
source: 'https://youtube.com/watch?v=ZpWdeDMAfuY'
video_id: 'ZpWdeDMAfuY'
date: 2026-06-15
duration_sec: 2315
---

# DPC2020: My Top 10 PHPUnit Tips & Tricks - Juliette Reinders Folmer

> Source: [DPC2020: My Top 10 PHPUnit Tips & Tricks - Juliette Reinders Folmer](https://youtube.com/watch?v=ZpWdeDMAfuY)

## Summary

Juliette Reinders Folmer presents her top 10 PHPUnit tips and tricks at the Dutch PHP Conference 2020. She covers essential practices for writing effective unit tests, from setting up the test environment to advanced techniques like mutation testing. The talk aims to help developers improve their testing skills and write more reliable code.

### Key Points

- **Have Tests** [02:14] — Start with the basics: add PHPUnit to composer.json, configure autoloading for the test directory, and create a phpunit.xml.dist file. Use the --generate-configuration option to get started quickly. Begin with a simple, standalone function to write your first test.
- **Use the Right Assertion** [06:09] — PHPUnit has over 100 assertions. Use assertSame instead of assertEquals for strict type comparisons. Using the correct assertion makes tests more descriptive and simpler. Always have the PHPUnit manual open to find the right assertion.
- **Don't Just Test the Happy Path** [08:34] — Test unexpected inputs and edge cases. For example, test with quotes within the text or boolean false input. Document expected behavior through tests. Avoid strict types in tests to allow testing of unexpected inputs.
- **Limit Assertions per Test** [10:44] — Multiple assertions in one test can make it hard to identify which one failed. Use the optional message parameter in assertions to describe each assertion. Alternatively, use data providers to run each test case separately.
- **Use Data Providers** [12:21] — Data providers allow you to run the same test with multiple inputs and expected outputs. Each test case runs independently, so failures don't stop other cases. Return an array of arrays where each sub-array contains the parameters for one test case.
- **Don't Use Your Own Code to Create Test Data** [14:07] — Using your own code to generate test data can perpetuate bugs. Instead, use an external data source or your own brain. For complex calculations, use an external tool to verify the expected output.
- **Name Your Test Cases** [16:10] — Use named keys in data providers to describe each test case. This makes it easier to identify which test failed, especially with many cases. Named test cases also improve readability and maintainability.
- **Explore Filtering** [17:58] — PHPUnit's filter mechanism allows you to run specific tests by namespace, class, method name, or data provider key. Use --filter with a regex pattern. This is useful for local development when you don't want to run the entire test suite.
- **Don't Trust Code Coverage, But Examine It** [19:33] — Code coverage can be misleading; 100% coverage doesn't guarantee thorough testing. Use coverage to identify untested code, but don't make it a hard requirement. Configure coverage with a whitelist and logging, and use scripts to run coverage locally.
- **Skip Tests Conditionally** [26:15] — Use markTestSkipped() or annotations like @requires PHP 7.3 to skip tests conditionally. This is useful for tests that depend on specific PHP versions or extensions. Verbose mode shows skipped tests and reasons.
- **Cross-Version Compatibility** [30:39] — To support multiple PHPUnit versions, use annotations like @beforeClass instead of relying on method names with return types. This avoids issues with void return types introduced in PHPUnit 8.
- **Test Your Tests** [32:19] — Use mutation testing with Infection to verify that your tests catch errors. Also, consider using PHPUnit Compatibility and PHPUnit QA rule sets for PHP CodeSniffer to detect deprecated or suboptimal assertions.
- **Lose Count** [34:37] — You can never have enough tests. Extra tests for edge cases can catch issues from dependency changes or PHP version upgrades. Having a comprehensive test suite helps prevent production bugs.

### Conclusion

Juliette emphasizes that writing good tests is an ongoing process. Start small, use the right tools, and continuously improve your test suite to catch bugs early and ensure code reliability.

## Transcript

[Music]
hi and welcome to the dutch php
conference
2020 edition we're so glad that you've
chosen to be here with us today we hope
you find it a
valuable investment of your time we've
got a great speaker coming up for you
but
real quick i want to give a huge shout
out to my buddies at ibuildings for
putting on this conference all these
many years
i've been involved in this conference
since about 2007 when i spoke at the
one of the first ones and just
absolutely love it it's one of my
favorite php conferences
ever and one of the main reasons that
it's my favorite is that
i buildings puts on a great conference
so tom yoni and angela and all the
i-building staff
thank you all for all the hard work that
you've put into this
and now it is my great pleasure to
introduce to you one of the
my favorite people in the entire world
this is julie or miss juliet formless
and she's going to talk to us about my
top 10 php unit tips and tricks juliet
take it away
okay so my talk is about php units but
before we start i'm going to reiterate
what cal said
and that is if the slides are actually
moving forward
for some reason they're not ah here we
go
so there is a github repo where i have
all the code samples we're going to be
using in this in the slides
and if you want to follow along go to
that github repo and the commits
which i'm referencing is in the slides
will
line up with that git repo and you can
also use it obviously afterwards
to browse and see um yeah what we talked
about and then to take your
benefit from that also as cal said
please discuss it's like there's a
specific channel for this talk
if you want to be sure i see your
message please place it there
okay now to really get started
welcome i hope you all had a nice break
my name is juliet reindus former and
we're going to talk
through my top 10 php unit tips and
tricks
the first one being have tests
okay how many people are behind the
screen now with their hands
in their uh they're facing their hands
sinking like oh yes
yeah i know i ought to but i haven't
i see a few at least one hand going up
here how
are the responses in the chat
cal okay cal's not responding
okay i realize if you have a legacy code
base
it can be really really hard and really
daunting to get started
on creating unit tests for your code
base
do not get discouraged but start
somewhere
start small so the very basics to get
started
is to have the setup in place so to get
the setup in place
first we're going to adapt the composer
json
by adding php unit to it and then adding
an autoload def to make sure that the
test directory
will autoload as well in the dev setup
good once that's done we add a php unit
config
now what this does is it basically tells
php unit
i have a test suite named foe in
the particular directory called tests
every file which ends
with test.php will be a test file and
please execute the tests in that
now there's two more things i want to
draw your attention to
first phpunit.xml.dist
the file name there you can use the
filename phpunit.xml or phpunit.xml.list
i'd recommend for a project to always
use the dist file name
the reason for that is that people can
then use phpunit.xml if they have
something in their local environment
they need to
tweak or do have the conflict slightly
differently
and they can then use that file because
it will overrule the disk file
second thing if you only have
a basic project where there's no
specific environment set the setup to be
done
just add the fender load from composer
as your bootstrap
and things will work fine right
next up you can actually get this
generated
largely by php unit itself
using the generate configuration so
that's your basics
and then you need to start somewhere so
start small
find preferably a standalone function
somewhere
which will just be an easy starting
point
to get the first test in place i'm using
this function as an example
strip quotes basically this function
says
i'm getting a string i want to make sure
that any
surrounding quotes are stripped but only
if they are the same type of quote
and not if they're like somewhere within
the string
good so to set up that as a test i'm
going to create a class called
a food test where the function test
strip quotes
i'm gonna extend the php unit basic test
case
i'm gonna call my function and i'm gonna
assert
that the results should be the same as
the expected results text
your first test is in place having those
basics in place
makes it so that contributors know that
tests are welcome
the tests are desired it makes it so
it's
that the next person who looks at the
code base wants to contribute doesn't
know where to start
knows that okay contributing test would
be a good idea
and maybe i should
next use the right assertion
hp unit has a wealth of assertions
there's over a hundred
assertions at my last count in php unit
nine
and one of the most common things i come
across is
people not knowing the difference
between assert equals and the search say
remember strict comparisons yeah assert
equals
is your double is searched same is the
tripolis most of the time when people
want to use
cert equals they really want to use a
search same
because if you use strict comparisons in
your code
why not are why aren't you doing it in
your unit tests
there are a lot of assertions available
this is just an example of
not even the complete set of assertions
and as you may see in the slide
nearly every single assertion also has a
not variant
so assert not contained only or certain
not contained assert
not empty asserts not ishval
use the right assertion and i know
getting familiar with all these
assertions can be hard
so just have the manual open have the
php unit
manual open next to your code base
when you're creating your unit test and
just check if there's a
assertion available which does what you
need
the reason why using the surgeons from
php unit is
important is one it makes your tests way
more descriptive
two it will make your test code a lot
simpler because all
of all the things php units can do for
you which you don't have to do within
your own test code
and three it will generally use the
wealth of information and wealth of
knowledge from
other people around the world to make
those assertions better if they need to
be
right now if we look back at that first
test we wrote let's fix that yeah
so that assert equals should have been
an assert same because we do want to
make sure
it's actually a string called text and
that we don't get well an integer
which will evaluate to something
and and you know not type juggling
and everything to do with that if you
want to know more about that
go and watch the big y equal doesn't
equal quiz
right next up don't just test the happy
parts
particularly people will use test driven
development
often have a tendency to focus
more than anything on the happy path
does the function
do what i want it to do instead of also
testing but how does it handle
unexpected inputs
how does it be how does this function
behave
in an unexpected circumstances you may
envision that your code will only be
used by you
but you have no idea of the imagination
of other people
people will use your code in unexpected
ways
well unless it's a closed story in your
own company but generally speaking
if it's open source if the code is
available to the public in any way
people will use it in unexpected
manners so don't just test the happy
parts
so if i look at that example function
again let's add some more tests
let's uh first the test with some quotes
within the text where the quote should
not be removed and then an unexpected
input
false and we document here
that that returns an empty string it
doesn't return the original value
it returns an empty string so your test
not only tests your code but also
document the expected behavior
now to allow for testing the unhappy
part
there's two things you need to remember
do not use strict types in your
tests and do not use parameter type
declarations
in your tests please do use them in your
code
but don't use them in your test because
it will make
testing the unhappy part really
difficult because you're
the type juggling will happen in the
test before
the parameters will actually get to the
function
under test so
it just makes it impossible to test
those unexpected
cases and those uh yeah the unhappy part
the unexpected inputs
limit the assertions per test
now you saw me adding two more
assertions to that previous test
what would happen if one of those would
fail
okay uh in this case
well i know which one i felt because it
shows me
where the plus and the minus the actual
expected text
and what the actual result was however
what happens if
the result would be true or false value
if you have three assertions and they
all expect through a false
this is not helpful you don't know which
one of the three assertions has failed
now every single assertion in php
has an extra parameter and the parameter
is called message and if we take that
functions
i've had the test function we had here
we can add
that message parameter and just tell
phpunit this is the particular assertion
which
is failed you may think oh yeah but this
is extra work
imagine how much time you will save when
one of these tests will start failing
that's where it's to help you debug it's
to make your life easier when things go
wrong
so if you make it a habit to always have
to have message parameters
if you have multiple assertions in a
test it will just make your life easier
now if that's a true false fails now you
can
see that it gives me a description of
the test case
and i know exactly what test case has
failed
yeah multiple assertions in a test okay
in this case in my example i'm
basically asserting the same each time
with different input and different
expected output i'm using the same i'm
using the
code in that case it's better to use a
data provider and the data provider
works like this
we have the test method and we tell it
that we're going to use a data provider
and the name
of the function which will be
acting as a data provider then we
tell it which parameters to pass to the
test function
and we make sure those parameters are
used so we use
in for calling the the actual function
we use out as the expected
value in your data provider
for every single test case you want to
test you create
an array so you return an array of
arrays
where every sub-array has those
parameters you're going to pass to the
function
without a data provider if one of those
assertions we had before those three
would fail the test would stop
because it's failed already and the
other
the other assertions underneath the
filled assertion would just not be run
whatsoever
with a data provider all three will run
it will just mark the one which failed
as failed
but the other test cases will still be
run
so it makes your test more descriptive
again and more stable
and now okay this one should be obvious
don't use your
own code to create test data
i know it should be obvious but it isn't
always obvious to everyone
and i'm going to read the account a
little anecdotes with permission
i was working with a customer on getting
their first unit test set up
and we discussed what we were going to
do we discussed the function we were
going to use it was a very
very simple function which was
translating
fancy phone numbers so 800 call now
to the real phone number
so we discussed using data providers i
asked the customer please
set up some test data create you know
some
inputs you want to use and some outputs
in the meantime i was setting up the
configuration
10 minutes later i go and check with my
customer how he's doing
and yeah
what i saw him do is he copied and
pasted
his own code into evol
was running his own function in e file
with various inputs and using the
outputs from that as the expected data
the function was buggy if i would have
allowed that to continue
he would have what the test would have
achieved would have been to perpetuate
the existing bugs
instead always use an external data
source or
just your own brain which is also an
external data source
to create your test data if it's really
complex like a really complex
mathematical
formula fine use an external
site which also does that calculation
preferably use
two verify that both return the same
output and then use that for your data
provider input
do not use your own code to create test
data
name your test cases now
remember those test cases are created in
the data provider
if i use a feature which i really really
like called test docs
i can actually see which tests are being
run in this case
the test trick votes with dataset 0 1
2. now you don't want to do this when
you run a large
test suite but if you're debugging a
particular test class
this is really useful because you know
exactly where something is going wrong
you can see it go running but
what if i had 70 test cases
then okay test number 53 has
failed okay i have to go to the data
provider and start counting
to figure out which one is data set 53
that's going to cost me a lot of time
again there's a smart solution for that
and that's called
named test cases so in your data
provider
when you have those arrays of arrays you
can use
the key and the key can describe what
you're testing
there and if you do that first of all
your tests become more descriptive
if you look back on your own test suite
in two years time you will know why you
added that particular test case
it makes your life easier in that sense
but also when a test
fails it will show you in a lot more
descriptive way
what has failed
see cal how are the people responding so
far is there
any questions so far hell
there are no questions in the q a and
juliet
okay thank you joni moving on
explore filtering now php unit has
an incredibly powerful filtering
mechanism
and quite often uh obviously in your ci
you're running your complete test suite
but when you're developing locally you
don't always want to have to run your
complete test suite
if you have 5000 tests and you're
just tinkering with one test class you
just want to run those tests
because all the others won't have
changed
so using filtering you can do that
and you can filter on a lot of things
you can filter on the namespace on the
class on the method name
you can even filter on the test case
number from a data provider or the name
from a data provider
and if this wasn't enough there's
shortcuts to help you there as well to
make it
still simpler it will take a little
getting used to
uh figuring out what will work and what
isn't uh won't work
basically it's being used as a regex
it's case insensitive
and as i said before incredibly powerful
especially in
the current versions of php unit it's
come a long way since
php unit 45 where the filter mechanism
wasn't as powerful
as it is now so if i just wanted to run
a few test cases i could filter
not string input on the previous example
and it will just show me the not string
input test cases
i hope you find this useful
don't trust test of a code coverage but
do examine it
okay now code coverage can be a hotly
debated topic
some people will say you have to have
100 code coverage some people say
i don't care about code coverage at all
i'm somewhere in the middle but let's
look at that function we
used as an example if i have
one test case this function will be 100
covered
however the regex adds an extra layer of
complexity
and even though the test coverage will
say this test
is a dysfunction is 100 covered in
reality it's not
not until i add a significant number of
extra test cases
now using test coverage
is a good idea do not hang yourself with
it do not make it a hard requirement
but do examine it do keep track of
what's going on
and okay some lines aren't covered
because they're
for edge cases and edge cases which are
so rare it's even
difficult to write a unit test for it
that's fine
sometimes you might have private methods
which you think uh
hang on but those are implementation
details so i'm not testing those because
i'm testing them via
other methods that's fine but do do
something with
code coverage do examine it to do so
you need to tell psp unit how to record
it
so first of all we're going to add a
filter
element to the config with a white list
and tell php units that
all our source files are in the source
directory
and that is the code which needs to be
covered
then we're also going to tell php unit
to lock the results
and i'm giving as an example the clover
logging mechanism the reason for that is
that a lot of automated
tooling which will integrate with your
ci
which you can use as status checks on
github
will use the clover file
now before you say help whitelist
each unit just like a lot of companies
and a lot of projects in the industry
is changing away from the term whitelist
as of php unit 9.3 that term is
deprecated and all these kind of
configurations are deprecated and
changing more
because they're now changing the basic
config
expects all of the whitelist code to be
terminology to be removed in php unit
10.
if you want to have a preview look of
what the configuration will look like
once you move up to php unit 9.3
there's a special sorry i'm skipping
something
there's a special branch in the demo
code repo
which you can see the commit which would
update this configuration
now the two things are skipped first
force covers
annotation okay this is about
accidental code coverage and intentional
code coverage
every test method should say i'm testing
this particular method or this
particular class
if you don't do that then a test which
doesn't have a cover stack
will just record any coverage on
any method it uses so that would be
accidental coverage where you're not
targetedly testing a particular method
by using the force covers annotation you
make sure that
every test has to have a cover stack and
codes
coverage will not be recorded unless
there is a cover stack
for those methods which don't
particularly test anything but you still
need that test
you can use covers nothing uh
be strict about co covers annotations
i'm a bit in doubt in two minds about
that one that
is very strict it basically says that
every single method even the ones which
you're using under
the hood including the ones possibly
from dependencies
would need to be annotated in a cover
stack
if you're very strict then yeah you can
play with it but for most projects it's
going a bit far
so know that it's there but make up your
own mind whether you want to use it
so if we go back to the test method we
had before
we're going to add the cover stack which
clearly indicates which method is being
covered
and in case you're now saying hey why
are you using an fqn
phpunit demands you use in fqn
you need to have a fully qualified class
name
function name not doing so
will not record the coverage properly
so even though you say yeah i've got you
statements no
fully qualified name please then
makes life easy on your contributors
whether it's your own team or a
team of open source contributors you
want them to use it correctly and you
want to
make it easy for them to run your test
but also run the test with code coverage
now once you've added the coverage tags
and add the logging
php unit will run with code coverage
every single time
and that slows down your test suite
incredibly
so to make it easier
add these two scripts to your composer
file
test with no code coverage as the
default
and then coverage which will record code
coverage
and to make life even even easier
sometimes you're just testing something
locally and
you don't really want to wait for
something to become a pr
to have some idea of whether whether
your changes are going to affect code
coverage
so make it easy to run code coverage
and create the result locally if you
create this script with coverage html
php unit will generate a website which
you can just
open in any browser and it will show you
the code coverage for your code
i hope everyone by now has heard at
least one thing which was new to them
but if not we're not finished yet so
don't leave without saying goodbye
sometimes you have tests which are
either
uh you either you're skipping them
because they're conditional like
they will only run when a certain
extension is available
or they will should only be run on a
certain php version
or you might have test stops where
you're
basically just go skeleton method
we need a test here but it's not there
yet
an incomplete test now
for a conditional test you can do it
like this you can just have
a comparison and return before doing an
assertion
that test will be marked as risky by php
unit because it's a test without
assertion
if you run it on php 72 we can do better
we can actually tell phpunit to mark the
test as skipped
then in that little dot overview which
you have as the default
test runner you'll get an s that test is
skipped
but then you still don't know why the
test is skipped
so document that by adding a message
this test requires php 73
and the example code is in in the test
branch
is a bit nonsense but it's just to drive
the point home
what the different options are in this
case if
we now run the test again we get the s
for skipped
but if we run php unit in for bose mode
it will also list
all the skip tests including the reason
they were skipped
now psp unit has a number of built-in
checks there so for php version or a pc
unit version or an extension or a class
exist or function exist
you can actually use annotations
and it will do the same thing and you
don't even have to do the version
compare yourself anymore
and again php unit will
annotate that with information and mode
with why the test was skipped
right now and one where when i
previously gave this test i got
responses on twitter from people seeing
the slide saying like i've now made my
test
cross version compatible
sometimes when you have a project you
can determine freely what the minimum
php version is
and you can say okay seven two seven
three
fine however especially with open source
or
with projects which work with legacy
code
so upgrading might be difficult and
changing the minimum required version
might be a slow process
if we look at the versions of php unit
itself
you can see that of the currently
supported versions
uh which are php unit eight and nine
php seven two sorry
my clicker is gone php72 is the minimum
uh and with php 7.2 as a minimum
yeah if you still need to be uh support
php 7
that's going to be difficult because
in php unit 8 php unit
introduced void return type for any of
the fixtures
and by the fixtures i mean things like
uh you use this particular type of
functions called
setup before class tear down after class
setup
and a teardown set before class and ah
tier that after class are
for setting up things which are used by
every single tester
and setup and teardown are run before
and efforts
and after every single test
with the void return type dead void
return type wasn't introduced until php
7-1 so if you still need to support php
7-0 and therefore also need to support
php
unit 6 you have a problem
and i'm going to click through to the
next slide and look if i can find
a little bit from to get my clicker
working in
i don't think i can so in the meantime
let's have a look how we can do this
as of php unit 8 we need the void return
type
this is a problem so what to do to get
rounded first we rename the
method
to setup database connection because
that's what it does
it makes the method far more descriptive
than setup before class anyway
and we add the before class annotation
with the before class annotation it will
run the method as if it was set up
before class
and you do not have to have the return
type for it
same goes for after you can use
after class rename the method don't use
the return type for it
and similar for setup and for teardown
which are the methods
run before and after every test again
you have the before
and after annotation you've seen me use
several annotations now you've seen me
use
annotations for coverage you've seen me
use these annotations you've seen me use
the requires annotation
there are more please have a good look
at those
because annotations can be really
powerful in php units
and before you ask yes
these annotations before class after
class before and after
will stay supported at least for the
foreseeable future
i spoke with sebastian and he's
indicated he has no intention
in the foreseeable future to drop
support for them so this should make
your
test suite cross-version compatible with
various php unit versions
and still maintainable for the future
okay test your tests now this might
sound
really really matter and in a way it is
but are your tests actually testing what
they're supposed to do
to test what are they stable what if
something changes in your code base will
you start a test start failing
uh straight away and
in some cases will they not fill when
it's something like a constant which
change
should the test maybe take that constant
into account
so to help with that first of all
we have infection infection is mutation
testing
it's a framework which will try
to mutate your source code and then
see if your tests fill correctly on the
mutated code
if you want to learn more about it first
of all there's a url to their own
website but second of all
there's a youtube video from my dear
friend michelangelo van damme
where he gives a little demo of how
infection works
i'd recommend watching it and i know
he's given more talks on it if you
have a chance to see it uh go and watch
michelangelo from them talk about the
election it's worth your time
another thing and this is just a quick
refill because they're not
online yet php unit compatibility and
php unit qa
these will be rule sets for php code
sniff so they will integrate
in your coding standard check which you
do by default anyway
don't you and
these will the qa one will check things
like
hey you should use a different assertion
or there's a more specific assertion you
could use for this particular
test code php unit compatibility will
warn you just like php unit itself does
in verbose mode
about using certain things which are
deprecated
except php unit will do it when you're
basically already
too late and with this you can do it
using an
or an older php version to figure out
what is needed to upgrade
your test suite so expect those soon
last tip lose count
i think i said at the beginning this was
a top 10.
please follow example lose count
you can never have enough tests having
some extra tests even though the really
edge cases and you think those will
never ever happen in real life can be
helpful
uh also remember things change
in the world whether it's in your
dependency or whether
php8 which is around the corner comes
along
and changes all sorts of notices and
warnings to
errors and exceptions make sure you test
those edge cases
because then your test suite will be
able to catch those situations
of php cross-version compatibility or
changes in your dependency
before it gets to production so it's not
a bad thing to have some extra
test cases right
that was it for me i hope you enjoyed
this talk i hope you found something
useful in it
please leave feedback joined in you can
use qr code on the slide
to get straight to the right page the
slide will be up later this afternoon at
speaker deck
and yeah of course
read the docs from phpunit
cal are you there now yes you're there
and we have a question please
um about the usage of code to generate
test data what is your opinion on using
constants from the code on test
come again about the usage of
code to generate test data what is your
opinion on using constants from the code
on tests
i tend to duplicate the constants in the
test to ensure the changes in the
constant values are detected
but some colleagues disagree with this
okay it depends on the context and i
can't give you
a hundred percent answer because it
really depends on the code
there are in my own code basis
i have situations where i'm
duplicating the constants just to make
sure that if the constant
changes the test will fill and i know
something has changed
uh there's also places where i use the
actual constant from the source code
because it's a public constant in this
case
in my test to make sure that the test
will
continue to pass even when the constant
changes
so it depends on the context and you
really need to look at the individual
situation for that
excellent i know it's not yeah it's it's
not a yes or no answer i'm sorry
that's okay it was an answer so hey
um let's see i think that's the only
question we had for you
so i am going to thank you for that i
appreciate that that was a wonderful
presentation hope everybody got as much
out of it as i did
okay um let's see let me
take back over the screen and share that
okay we got 20 minutes until the next
talk 20 minutes so get up get stretch
get you a cup or a glass of whatever
you're drinking for the afternoon
and we'll be back at the top of the hour
hey don't forget go out to joined in
leave juliet some feedback on what she
did right and what she can do better
and of course we always appreciate it
when you tweet out
or whatever social media you use when
you post about
dpc20 thank you we'll be back in 20
minutes
see you later
you