start exploring unit testing in
JavaScript’s i think of unit testing as
a software development technique where
you divide your software up into small
isolated units and then you write
automated tests for those that verify
that each unit works as expected my main
motivation for doing unit testing is to
keep complexity from overwhelming me
we’re going to look at how a piece of
code always starts out simple but
eventually grows in complexity until it
is too much to keep in our hips
I am mvj and you are watching fun fun
function
so today’s video is completely focused
around why we do unit testing it so we
are actually not going to be writing any
proper unit tests today we are not going
to be at all focused on the what unit
testing s or or how we do it we we’re
going to start with Y and I want to
start in this way because unit testing
can be daunting it can be daunting to
learn it can be daunting to do when
you’re under pressure like tight
deadlines you just want to get your
software out or on days when you’re just
feeling lazy in those situations it’s
very important to know why we are doing
unit testing and where it comes from and
what we’re trying to achieve with it
alright so let’s imagine that we are
running an online pet store that
specifically targets people who own
small dragons in the checkout and some
other places we are going to display the
order total a sum of all the items that
we currently have in our shopping cart
somewhere in the code base we’re going
to have this this function called order
total that function is given an order
and it outputs a total amount of all the
all right success let me walk through
this code for you so we have this
example order here called some order
this some order has an item property
with an array of of dragons that have a
name and they have a price the dragon
cage is slightly more expensive than the
dragon food it costs 800 things and here
we have the star of the show order total
it takes an order and it accesses the
items property here and it reduces all
those items down to a order total by
summing them something the price
together and then we call the order
total with some order here and we get a
result in that is 108 which is 800 here
plus 808 just say 100 808 huh
hello MP J your emotions here I have not
seen reduced before and that makes me
feel a little bit uncomfortable I would
rather use something that I’m used to
like a for-loop hello feelings a
benefits here I it’s completely normal
to be afraid of new things but remember
that new things become less scary the
more you use them and reduce is super
useful and I really urge you to learn it
it will really change the way you think
about things I have we have actually
made an episode about that that you can
find by clicking there I excuse me for
chiming in here I would just like to
this here like can I guess I would like
to alternate yeah this this is a bit
nicer now it looks like a table right
that’s nice okay that looks beautiful in
that specific case but it would break in
a linter in any real project that is
just imitation that is useful in just
this specific case that’s how many
points but this video is about unit
testing can focus on that all right fine
this this example to me seems very young
example this order total function here
it’s this is already a cleanly separated
you
it function it’s in real code things
tend to be a lot more intermingled I
feel like this is just a very
theoretical example yes this this
doesn’t feel like real code to me
sure this is absolutely no very
simplified example but this again is an
oh it’s just an introduction to unit
testing can we can we look at what the
code looks like right now and what we
could learn here all right we can do
that I I feel like this code or a total
it doesn’t need tests doesn’t feel like
it need tests it’s very simple even with
the reduce which I’m uncomfortable with
because it’s new it’s it doesn’t feel
like this is enough logic to warrant
having an automated test suite that
seems like shooting shooting a fly with
a bazooka well sure it looks like that
now but even the even the most
horrifyingly complex function starts out
in a simple way it’s kind of like what’s
the expression boiling a frog
what do you boil a lobster is it a
lobster you put it in cold water and
then you just increase the temperature
until you know that’s a good point let’s
uh let’s try adding some complexity to
to this code let’s invent some let’s add
quantity
[Music]
okay so I’ve added a little bit of
complexity now what can we talk about
this I feel like well I’m still not
afraid of this code it still seems very
manageable
maybe unit tests are a waste on on
simple functions like this maybe that is
maybe that’s a good point
maybe that’s they could be beneficial
for us to pick our battles and not do
unit testing on on every single function
and just save the time and not do unit
testing on simple functions like order
total here people people people you have
to think about the old Swedish proverb
you have to think longer than your nose
goes that’s not a good translation of
that proverb my point is that complexity
is going to grow over time what we see
let’s let’s try that hypothesis and just
add even more complexity that’s invent
let’s add shipping and if the order
total is about Bob above a thousand
bucks
then our shipping is free
[Music]
all right so what did we do here we
extracted the total like we started
filtering the items first before doing
the summing so we ship we sum only items
that have a that aren’t shipping items
and then we find the shipping items in
the array and then we calculate the
shipping if to be 0 if total items value
is above thousand or the shipping to be
the price of the shipping item otherwise
then we added two together and then we
eventually get the result down here now
this this is what I’m talking about
things are getting more complicated now
now that we added a conditional
statement here we our code has multiple
execution paths before when we just had
the price and we just had the quantity
our code just had one execution path but
now we have two one where order is the
order is large and we waive shipping and
one where the order is small and we
charge shipping ok so I think I’m
starting to get your point this this
code definitely got a little bit scarier
now that we added shipping yeah and I
think I know why it’s because previously
before we are the chipping we could
express the entire logic or like what
order total did with just this with just
the some order example we had one
example that expressed the entirety of
what the function could do but now the
example call like summary can only tell
half of the story which is in this case
that it’s it’s a big order what if I
changed this to be quantity 1 we are now
on the only small order case so this
this time it adds at shipping but the
example can only express
one of the forks in the robe so to speak
yeah I I mean I still feel pretty
confident about this code it’s I hear
and that’s because I I kind of executed
this in my head while we while we wrote
it so I and it’s it’s only one other
fork one other branch in the logic so it
feels kind of manageable to keep in my
head but exactly and let’s say that we
started adding more steps to the
complexity over time like say that we
added taxes or immaterial goods that
require no shipping charges yes then you
can probably see how this would
eventually go get to a point where it’s
just too much for your brain to handle
all right that makes sense but if our
goal is to think about less things at
the same time then couldn’t we start
breaking this thing apart into smaller
functions like breaking a bigger
functions into smaller isolated
functions that are responsible for for
for just very isolated things that’s
that’s generally a very useful tool but
I don’t think it makes sense in this
case all the total seems like a pretty
good a good unit to me it seems like an
isolated problem in order to break
things up into small functions you
actually have to be able to also break
up the conceptual problem like if you
just start extracting things out into
lots of tiny functions you’re not really
breaking the problem up so that you can
think about it separately you are you’re
really just spreading the problem out
over multiple places so that you have to
diverge your thinking even more I think
that you actually have to accept that
even when I software module is small and
isolated and minimal it is probably
still too big for you to keep it all in
your noggin okay yeah but again it feels
like doesn’t that doesn’t that mean that
I’m dumb it feels like a rock star a
super smart programmer would be able to
keep this easily in their head I
understand where that feeling is coming
from but that kind of thinking yes
doesn’t scale if we have a software
industry where the average developer
can’t build software of reasonable
quality then we are doomed as a world to
have shitty software and and and and and
even if you are a software company that
can afford it and is capable of hiring
the very best of the best even their
brains is going to get overwhelmed by
complexity at some point it’s like with
juggling I can juggle three audience
okay and maybe you are better at jumping
maybe you can juggle five and the world
record is 11 balls but nobody is even
close to handling 15 balls alright so
what did we learn here let’s let’s
summarize code always feels very simple
from the start but it doesn’t stay
simple it grows and grows and grows into
multiple use cases too many to keep in
our heads all right I I want to see what
unit tests look like and now if they can
help with this which is what the next
episode is about you have just watched
an episode of fun fun function I release
these every Monday morning Oh 800 GMT if
you are watching from the future you
find next Monday’s episode here
otherwise you can subscribe here so that
you don’t miss it if you are forgetful
you can also turn on notifications in
the YouTube app I am mpj until next Monday morning stay curious