Unit tests vs. Integration tests - MPJ's Musings - FunFunFunction #55

💖 Support the show by becoming a Patreon

We explore the differences between unit and integration tests, the advantages and disadvantages of unit tests and integrations tests, and if integration tests can completely replace unit tests. I also spend some time talking about why automated tests are critical to producing software.

⏯ Highlights
00:15 Why automated regression tests are critical
05:11 Unit test definition
08:42 Integration test definition
11:22 Downsides of unit tests
17:03 Downsides of integration tests
26:47 Summary

📺 Music in the video: Peacock by 7 minutes dead

💛 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

[MarisZemgalis]

Brilliant video! I watched this video at home, put it on TV via Chromebox. Even my girlfriend liked the video - she's not into IT yet the video itself, the presentation, was totally fun to watch. Good job!

[cristiandavidtorrespenaran]

I watched almost all videos of this channel and this is my favorite one. You are doing a great job, your videos helped me a lot of times.

Greetings from Colombia.

[anasalbarghouthy]

26:10 "Young developers, Jesus that sounded arrogant" 😂😂😂😂 Man your videos are just great! This is what schools and universities need, very joyful people like you who has enough practical experience to be able to teach software engineering in a very entertaining way, Jeez you're so good. Love your videos man, hope you read this comment. You made me love JS and testing which are things hard to make people love easily LOL 😂

[Rendis-pz]

Thank you for this video, as a junior dev, test automation is perhaps one of the most important things I haven't explored much yet and there aren't many accessible resources on it. I like that you started with a purpose of tests. Keep it up.

[Shadowdoctor]

Very clear video. I was taught about unit testing on my onboarding for junior dev job, but integration testing was very much a black box for me.


This helped a lot!

[antonbozhinov]

The best start of the week! Every week! LONG LIVE FUNFUNFUNCTION!

[redstrikedn]

I like the speedy summary at the end of the video <3 That part truly helps me recall the overall contents and quickly re-memorize them (y)

[DecaSpace]

An integration test is something that almost made me fail Calculus 2 😂

[Snorbuckle]

As a software tester moving more and more into a development role, this is the first video of yours where I felt I already understood the subject matter. You did a great job communicating it!

You're definitely right in that the biggest downside of unit tests is that they don't test the contract between two "units" whereas integration tests do. However, I don't think it's necessary to go to full-blown integration tests to actually test the contract in most cases. Given that the way to unit test is to select a "unit" and mock everything around it, I've proposed the idea of "unit integration" tests, where in order to test a contract between units, you select two "units" and mock everything around THOSE (in this example, one of the "units" from the view, and one from the controller). This, combined with the individual unit tests for those units can really help protect you from making breaking changes whenever you need to refactor things in the area. Do you think that's something worth pursuing, or do you think the idea of wanting three different kinds of automated tests would be too much to ask of a development team?

[MatthewChenIsAwesome]

Your TL;DR summary at the end was fantastic! Every development YouTube tutorial should have that :D

[ricardovsilva]

Awesome video! I'm a senior developer and couldn't think in a way more didatic to talk about both kind of tests. Congrats and keep making those awesome videos! You won my sub.

[ryanbach]

Jeez! Seems like I blinked and you flew from 10k to 50k subs! Congrats! :D

I'm glad to see you're popularity start reflecting your competence, character, and awesome teaching style.
You're the best Instructor I've found on Youtube. The attention to clarity and detail is much appreciated.
Thanks for spending your Sundays helping myself and tens of thousands of others grasp JS concepts!
Keep "wasting" that paper! ;P Here's to 100k subs, you'll get a silver play button soon enough!

[tljstewart]

@24:00 when you said "network errors" youtube bugged out lol! First testing video I've ever been able to watch and enjoy. Thanks FFF!

[RabbitWerksJavaScript]

Very excellent breakdown of these two testing methods. If anything I've taken away from it so far is that the first step is just to get it in there and get dirty and write trial and error tests until it starts fo make sense. Looking forward to the more in depth examples to come. Thanks for the food for thought, as always.

[buchanan]

I agree both are needed. I usually describe the reason for both as the unit tests help prove the functionality works as the developer envisioned it and the integration tests, provided they were written from a user perspective prove that the whole behaves as desired.
I also just like the code structure you end up with as a byproduct of making it testable.
Thanks for a great video as always!

[rdean]

Aside from execution time, writing integration tests for applications or services in data-intensive or complex environments takes a lot of development time. Spinning up a dummy database is one thing, populating it with all of the data needed by your application is quite another. And keeping that dummy data in sync with future changes to the production database schemas is a major commitment.

[zainabedin]

Really awesome video. Answered a lot of questions I had regarding tests.

[thememace]

thanks again for another hilarious and instructive video!
maybe you could consider doing the summary at the beginning of the video. 30 mins is kinda long and your 1 min wrapup gets your point over pretty well too.

[aylictal]

You know a great deal more about javascript than I ever will and I frequent a lot of your videos.

However, I am proud to say that I know a little bit more about automated blackbox testing I believe (you labeled this as integration testing throughout the video). This is because I work as quality assurance, rather than as a developer for corporations, so it's usually not my responsibility to write the app, but test the app. I'll highlight some other things for other people interested:

Selenium grid is one method in which you can run integration tests in parallel. It turns a 8 hour nightly test run into sub 15 minute runs at best for individual tests. The only limitation is the amount of browsers you can physically open on the machine.

Page object model is the approach I go about to writing solid integration tests. It is a hefty amount of boilerplate, but it is tried and true, and it gives an approach as if you're writing -an app to test an app-, rather than tests of an app. The philosophical approach of using page object model requires knowledge of the concept of scraping, which is what the "brittle" parts the op was describing and he is without a doubt correct.

Lastly - screenshotting, or grabbing stack traces isn't too hard from the client, however getting serverside (or even db) stack traces is difficult or even impossible if you stick to a blackbox model for your integration tests.

[PragMaliceTV]

I've always felt that most people get scoping on integration tests wrong. While it is important to test unit interactions (contracts), it is not necessary to test them in the context of a holistic "day in the life" of some sort of data transformation. If you're doing proper unit testing, you've already got tons of facade/mock implementations of your system's components lying about, so you should be putting them to good use and limiting the scope of any given integration test to specific contract behavior. Done correctly it effectively eliminates two of the downsides you cited as it gives you the granularity to both simulate errors and detect where problems exist. It increases how expensive integration testing is as you will no doubt have to generate/spin up excessive amounts of boilerplate data/or components, but I view this as the price of sanity in testing. That said it does potentially afford you significant savings by limiting the combinatorics of mutli-component/platform testing. I've never been in an organization with the (mis)fortune of trying it both ways, but it isn't too hard to imagine the small scope approach's expense being similar to that of a test suite with too large a scope defined when all is said and done.