Unit testing in JavaScript Part 2 - Your first tests

😙 Support the show by becoming a Patreon

🔗 Watch this series from the start

🔗 Discuss this video on the Fun Fun Forum

🔗 Inline evaluation plugin (Sponsor)

🔗 Code snippets from the episode

🔗 mpj on Twitter

🔗 The gear I use to produce the videos

🔗 Help translate the show to your language

Today, we are continuing our journey on unit testing in JavaScript. In the last episode (you can find a link to it in the video description) we explored about why we're do unit testing, which is protect ourselves from being overwhelmed by the growing complexity of our code.

Today, we're going to focus a bit more on what unit testing is, and how unit testing helps with managing complexity.

💛 Follow on Twitch and support by becoming a Subscriber
We record the show live Mondays 7 AM PT

💛 Fun Fun Forum

💛 mpj on Twitter

💛 Wallaby (Show sponsor)

💛 CircleCI (Show sponsor)
Robust and sleek Docker-based Continuous Integration as a service. I used CircleCI prior to them becoming a sponsor and I love that their free tier is powerful enough for small personal projects, even if they are private. Use this link when you sign up to let them know you came from here:

💛 Quokka (Show sponsor)
Wonder how MPJ evaluates JavaScript inline his editor. Quokka is the answer - use this link when you buy to let them know you came from here:

💛 FUN FUN FUNCTION
Since 2015, Fun Fun Function (FFF) is one of the longest running weekly YouTube shows on programming 🏅 thanks to its consistency and quality reaching 200,000+ developers.

🤦‍♂️ The Failing Together concept is what makes FFF unique. Most coding content out there focus on step-by-step tutorials. We think tutorials are too far removed from what everyday development is like. Instead, FFF has created a completely new learning environment where we grow from failure, by solving problems while intensively interacting with a live audience.

Tutorials try to solve a problem. Failing Together makes you grow as a developer and coworker.

📹 Each show is recorded live on Twitch in a 2-hour livestream on Mondays. The host, assisted by the audience, is tasked to complete a programming challenge by an expert guest. Like in the real world, we often fail, and learn from it. This, of course, reflects what the audience identifies with, and is one of the most praised aspects of the show.

⏯ On Fridays, an edited version of the show is adapted for and published on YouTube.

Content Topics revolve around: JavaScript, Functional Programming, Software Architecture, Quality Processes, Developer Career and Health, Team Collaboration, Software Development, Project Management

[ddanielsandberg]

The main reason to write tests first (TDD) is that the test becomes the first client/user of that code, or more specific; the first client of that API. If the tests are easy to understand the API is probably good. When I started out with TDD I ended up in situations where I felt like "the tests doesn't let my write the code I want to write, this is stupid!". It was only later I realised that my designs, code and APIs was s*it and I should listen to the tests telling me that. If tests are hard to write, the design is either bad or I'm writing some horrible integration code (filesystem, network, db).

The other reason to have a test failing before writing the implementation is to ensure the test is testing what you think it is.
For example, making the code just throw an error to "make the test fail" would be missing the point. It's not the test that is failing, it's the implementation that fails the test. I would suggest having the test tell you what went wrong: i.e "Expected a total of: 808, was: 0". Now we can see that we are testing for the case we think we are. In the end it's really about building confidence in the tests.

[db-tb]

The Odin Project once again sent me for your channel. You have a real way with words, extremely helpful as always.

[jamesshadrack]

The Odin Project sent me here on this day

[paigedumplings]

Here from The Odin Project - love your videos and your teaching style! You make it both educational and fun :)

[KimHogeling]

These 23 minutes felt like just 5. This is done really well and improved my perspective towards unit testing! Can't wait for next episode :)

[JefersonEuclides]

When I started unit testing I always felt like I was doing if(true) true; if(false) false; And that made me feel like I was just wasting my time. After a few hundreds lines of tests I definitely felt like I was secure, like the API was secure against myself, my own mistakes. The felling of running npm tests after a major update and knowing that everything is fine (without hours of postman tests) is priceless.

[humberjini]

8:04 is why your video series is so great. Having a blast learning from you, thanks!

[sweeball]

Thanks mpj. I like the introduction to the concepts without the use of a test runner. It demonstrated that one can write test by employing just plain old vanilla JavaScript. Look forward to next Monday!

[marekk]

You, sir, are a godlike teacher. Explaining concepts instead of showing bland code in a specific framework really makes every second worth watching you. Hope you make it as a full time youtuber. Cheers

[ibetovski]

MPJ, this video is great! Congratulations for splitting the unit tests theory from using test runners.
One of the mistakes every newcomer can make when starting doing unit tests is to test the unit's implementation instead of input->output confirmation.
When I started I tested every property of a class if it exists and if it is a certain type. One hour later I realized my mistake.
I hope you will mention the mocking and stubbing in the next videos and if it is a code smell or not.
Good luck :)

[leonardodiasdevasconcelos]

MPJ: Multiple Personality Javascript-master.
Loved the new idea of "different people" asking questions and commenting as you explain things.

[JeatBunkie]

You are a genius teacher. Oh my god, I am going to gain so much from this channel I am so glad I found this today 💛

[naderabdelrahman]

The soup analogy was great, very helpful

[jalalchachoua]

this guy is genius, or should I say these guys :D

[emilaasa]

Strong pedagogy! I like the fact that you did not use a test-runner!

[vikai_fang]

Great show, any other hosts would make this topic way too boring, but not you! :) Thanks a lot.

[simoneicardi]

Thank you very much MPJ! I'm just approaching unit testing and these videos are very useful to me. Love your "unit explanation way", so it's very easy to understand everything without having over-information. Keep doing it!

[jeffwells]

I just had an epiphany about unit testing and why it works. I've been working through an all-inclusive programming textbook called 'All of Programming', and in it they lay out the entire process for writing an algorithm from start to finish in great detail in a sort of old-school, traditional, tried and true way. The start is defining a problem, then solving one instance of that problem (without writing any code), then making that solution general enough to solve every instance of the problem that is within your scope, and finally writing the code version of that solution to form the algorithm.

Well, unit testing is basically a way of working through the problem to find the solution in parallel to writing the algorithm. It's like combining the two steps without losing the benefits of either. The test is basically solving the problem, and then you write code that satisfies the test. Bonus is that you've automatically got something that verifies things like your old code working with your new code, which you showed in the video. Pretty cool, IMO, and not the way I used to think about TDD. Definitely seems like something I should learn.

[BokoaChocobo]

What you meant by every test being a unit, could be seen in the Single Responsibility principle, automated tests are also software, hence, best practices still are tied to them, a single test that tries to test the whole API of a component will be probably harder to maintain, way more fragile, and harder to understand. Also, some of us believe that unit tests can be used as part of the documentation, single tests that tell you exactly what certain functionality of the component does could help you a lot when you are working on code you have never touched before.

[MatthewPeck_personal]

Self-taught JS developer here. Gotta say man, your videos are amazing and help me fill in some of my own skill gaps. Awesome videos!