How This Test Saved Kent’s Site

Testing is a difficult and time consuming process, but it doesn’t have to be. If you take advantage of implicit testing you can get the same level of test quality and coverage while writing significantly less tests. This is exactly what Kent C. Dodds has done on his Epic Web site since he has just one test that gives him pretty good test coverage. In this video I will explain what implicit testing is and how you can take advantage of it.
📚 Materials/References:
Implicit Assertions Article: www.epicweb.dev/implicit-asse...
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
01:18 - What Are Implicit Assertions
04:10 - Why This Is Useful
#WebDevelopment #WDS #Testing

[@kettanaito]

Thank you for bringing light to the topic of implicit testing! Feels surreal to have your writing showcased ❤

[@WebDevSimplified]

Thank you for writing this article. It was incredibly well written and all the examples you used were spot on. I will definitely be checking out more of your articles in the future.

[@kettanaito]

@@WebDevSimplified Means a lot to me to hear that! Take a look at what I've already written, there's plenty of interesting testing topics we should be talking more about. Once again, huge thanks!

[@Bhushantbn]

Thanks kyle for making videos on testing stuffs. Nowadays there is less talk about qa guys especially on youtube. Expect more stuff on testing..

[@1DrowsyBoi]

Web devs really be out here writing "tests" that load an entire page and calling it a day, huh?

[@tinahalder8416]

No one does this bs, no company will allow this nonsense

[@Jabberwockybird]

Some companies will allow it. Not all corporations are tech companies with strict requirements

[@sergtimosh]

The problem with implicitly checking stuff- bad errors in the reports. You will not always get explicit errors, and will spend more time to investigate what went wrong. So basically it’s the matter of balance, I’d better use few more lines for things that I wan’t to be logged in the report for clarity.

[@nielle1963]

It also implicitly assumes that you are the only one ever going to have to read and understand the test.

[@piaIy]

It's the opposite. From my experience, all of the popular testing libraries (Jest, Testing Library, Playwright, etc.) print very good error messages with diffs and lots of extra information when you use more complex assertions that include a bunch of implicit checking. The linked article has some good points about this. Think about `expect(obj.prop).toBe('something')` vs `expect(obj).toEqual({ prop: 'something' })`. If `obj` doesn't have a `prop` field, the former will give you something like "undefined is not equal to something", while the latter will print a diff between the two objects. And it's a very basic example, but it's even more true when you're asserting whole page elements with locators in e2e tests, because these complex assertions can handle edge cases you've never even thought of. Another example that most people without experience will write is a bunch of assertions with handwritten comparisons as the expect parameter coupled with `toBeTruthy`. These tests are almost useless if not outright evil because all you get is "false is not true" in case of an error, and you lose all the information about the context.

[@-taz-]

@@piaIy Yes, Jest et al. will say what went wrong, but not why it's wrong. Hopefully the developer of the test put the reasons for things into the test names, instead of just repeating the code in the strings. "people without experience will write is a bunch of assertions" In JS frameworks like Jest, yes. But in DocTest or Boost::Test for C/C++, or tons of other libraries (probably some in JS, too?), we can write assertions in the language directly and the framework is smart enough to produce nice output. If I could have the power of DocTest in JS, it would be a dream come true.

[@paulstelian97]

Implicit tests can be good if you run them every commit, because if a test suddenly fails it can be obvious that you have to look at the diff… most of the time.

[@virtue3]

I was going to say the exact same thing. It makes it dramatically harder to figure out WHY the test isn't working. This is especially important when people have a failing test a few months/years down the road and have no clue what is going on. Or you work with alot of people (and across time zones).

[@sylvainschellenberger]

It seems you've mixed two different concepts in this video: while the blog post linked in the description talks about implicit assertions, the test of Kent C. Dodds' app is a smoke test. It doesn't really matter if the assertions are implicit or explicit, what matters is that this test runs in the CI pipeline, so it tests the status of the deployed app (any dev would be able to tell if the app is crashing in their own development environment). Besides, it is not even a reliable test for some classic webapp: the root url could render a blank page or the 'not found' page, and the test would still pass. It seems this app is some kind of learning material that users are expected to clone and run in their own local environment, so this smoke test is probably just testing that the tech stack can run in a basic node.js environment that is not Kent C. Dodds' personal computer.

[@ispepsi2023]

This is the "testing" equivalent of "some things go without saying". Love it, awesome refresher!

[@LoveLearnShareGrow]

The only problem with implicit tests is that when an error happens, it might be way harder to debug than if you had written more explicit tests that start very general and then narrow down to the details. That way you'll see how much went right before something went wrong, and you're more likely to get an error that is something like getting an orange when expecting an apple, as opposed to a confusing error where you expect an apple and get a "cannot call method on undefined".

[@den9943]

Don't you think that writing a test like this worsens the understanding of the intent of the person who is testing and merely leaves Easter eggs behind? If we try to implicitly cover all cases with one test and don't consider that the code being tested could change just enough to meet the test while not working correctly, then what's the point of writing tests at all?

[@akam9919]

For tests like these, don't be afraid to comment. Someone will know what the code does, but not know why it exists. Comments are your sometimes annoying and nerdy friend, but they clearly serve a critical role among your friend group. It's better to have them around than not.

[@den9943]

@@akam9919 so let's comment everything instead of good test coverage, right? When we write comment, maybe our code is unclear and smells not so good. Better to write obvious code than support comments. Btw, comments keep silence when your code is broken down.

[@TokyoXtreme]

In my experience, we have tests that assert that the components rendered and are visible. In this case, we'd use end-to-end tests with an automated browser.

[@den9943]

@@TokyoXtreme You can write tests however you like, depending on your intentions and what exactly you want to cover. The question was different-it was about the need to avoid writing overly detailed tests and to limit yourself to implicit, I would say magical, contrived ones more than they really are.

[@TokyoXtreme]

@@den9943 I think the test was that when the user navigates to the initial page, the page should appear? Unit tests can assert that a certain number of components or elements appear, although it may be easier to have E2E tests that assert nothing broke during an update. Full-page screenshots can assert that nothing visual changed within the layout.

[@adaliszk]

Wouldn't be nicer to expect no exceptions to be thrown? That way at least the test itself hints at what we are looking for and not just relies on implicit assertions?

[@nikkehtine]

I guess the point here is primarily to just be a safe measure to protect you from shipping broken code, not a proper debug function. It's called "smoke test" after all. A smoke alarm doesn't tell you where the smoke is coming from, it's there primarily to warn you before it's too late.

[@adaliszk]

​@@nikkehtine Using that analogy, this way of writing the test sounds to me that the smoke detector checks the temperature of the air and not the CO2 concentration. While it does work, why not be more accurate with the intent?

[@PunchingW00d]

Yeah, I've always seen tests like this assert no exceptions rather than asserting true -> true

[@javabeanz8549]

BTW, "smoke test" was a term we used in electronics, applying power, then looking to see if any of the "magic smoke" got out.

[@ShadowKestrel]

as someone who doesn't do much javascript and spends far more time with compiled languages, the thought of implicit tests to make sure your module exists, your function inside the module exists, and the world around you still exists, is basically unimaginable to me. Maybe this is my inner zig user speaking here, but if something has complex enough behaviour to warrant testing then just give it its own explicit test. Don't send programmers into a wild goose chase of "why did my code change break a seemingly unrelated test" when you can have a test right next to the code in question that clearly communicates the guarantee made about that code! To quote the zen of zig, Communicate intent precisely.

[@TennysonHull]

This channel is a gold mine of information. Thank you for making making me a better engineer.

[@aamiramin6112]

Awesome. Thanks for sharing Kyle

[@Respectable_Username]

The problem with implicit tests is that it can be harder to figure out _what_ failed. Explicitly testing shows clearly _at what point_ your code failed, making debugging a lot simpler. Obviously you don't need to go overboard with it, but some simple sanity checks can help resolve some "gotchas" a lot faster

[@icedog225]

I definitely see the benefit of having a basic smoke test. But about the point at 5:10 of removing redundant type assertions before testing - wouldn't leaving that explicit type assertion in there help make it clearer what exactly is expected (and what exactly went wrong) to whoever is reading the test?

[@piaIy]

How is an extra type assertion any clearer than just expecting the exact object? There's no additional benefit. The error message would contain the actual value of the data in case of a non-object type either way.

[@buddy.abc123]

I might start writing javascript tests now

[@petleveler8366]

me too.. as a fullstack dev that is 2 years in the Industry and now promoted to senior dev might as well write test lol

[@wil-fri]

@@petleveler8366 test your validators

[@arielcani85]

When you create a new Angular component, by default the cli creates a .spec.ts file with boilerplate config and a test asserting that the component should be truthy. I used to underestimate these tests when I start learning Angular, but they're critical in fact.

[@Nellak2011]

So before watching the video, here is what I gather about that test. The await will only go through if the test runner is able to access the page. So that means that the expect true == true will only ever run if the await goes through. So I am assuming after a certain timeout, the test runner fails the async test. So this test is testing if it can access the page or not.

[@burtyful1]

Good stuff!

[@psychic8872]

What if there is no assertion at the end? Won't this still fail the test if there are problems?

[@idoschacham6276]

Sure, this test can catch rudimentary issues. However, if Kent's homepage loads an HTML page with no content and no errors then the test will pass, even though his website is broken.

[@mutatedllama]

What's the purpose of hiding your true test in a riddle? Just write an explicit test.

[@OzixiThrill]

It's the ancient lumberjack trick of print("this bit runs"); from last century. Also, explicit tests take time to write; Unless you need (as in actually need) to test something, sure, go for it, but for simple sanity checks, that's the sort of wasted time that bloats time requirements for no gain.

[@electricz3045]

It's faster to write. You can Always add a comment to let Others know how the implicit Test works

[@GuRuGeorge03]

we have similar tests in our codebase and new developers keep asking why we have them or make PRs to delete these tests. When I tell them what kind of bugs they've already prevented from going live, they start understanding

[@go_better]

Thanks! Awesome and powerful

[@marna_li]

This should actually be obvious. The reason why many don't want to write code is that they think of explicit testing - and sometimes coverage. Just having some code testing something is better than testing all the details. Unless perhaps you are dealing with a complex API consumed by others and you are dependant on the data returned.

[@williamdrum9899]

So what purpose does "Expect True To Be True" have? Couldn't you leave that out without changing the outcome of the test

[@electricz3045]

Well you gotts Test something and true is a good Default Test

[@williamdrum9899]

@@electricz3045 I don't know the language but can't you just run the website without a test and get the same result?

[@QwDragon]

Does actually `goto` checks the page rendered without errors? Seems like it only throws if your server fails.

[@adambickford8720]

Throw an exception in your component. What happens to this test?

[@nahueltarricone]

What about coverage if you are using a software like sonarcloud?

[@ProfRoxas]

in some cases this can be fine, like if it only has to render, but in most cases (mostly not frontend development) it usually far from sufficient, because with implicit test, you most likely wont know where the error is and you have to spend hours debugging

[@nielsvanderveer]

I do see the point you are making, but the example are a bit weird to be honest. Why do I want to test the amount of arguments of a self defined function? If it is randomly changed the tests of that sum function wouldn’t even run. Why do I even bother testing other function definition that are not part of my “unit”? I guess the important note is that this strategy applies to integration. Return types and arguments are classic examples a statically typed language does verify for you. I can’t imagine a word where I need to re-implement my code in a test to verify the call-signature is not messed up.

[@randyproctor3923]

This reminds me of using assertions in C. They are kind of like sanity checks.

[@Vegamorph]

Implicit testing has value of course, but the issue with things being implied is that different individuals expect different things. With fixed syntax code i appreciate that intention is clearer, but its a bad practice to get into. Tests are a safety net to move quickly and alert you of unexpected issues succinctly.

[@piaIy]

Read the article and the best practices chapters in the docs of the popular testing libraries; the overuse of explicit assertions is not only redundant, but sometimes even harmful, because they can obscure the intent and hide the context that a better, more complex assertion could convey in the error message.

[@charleschukwuemeka8482]

Please, Can you do a tutorial on Backend Testing using TypeScript?

[@libenhailu5193]

For smoke test it is great specially when features are added.

[@diogenesoliveira6473]

Honestly, it would be better to do expect().resolves or expect().not.toThrow. This expect(true).toEqual(true) just smells like someone trying to silence a linter

[@snobbybumblebee]

"Smoke screen test" and "Testing is one of the most complex features out there..." 🤔

[@prajunathunt]

Simple but genius

[@hundvd_7]

I am sorry, I genuinely cannot watch this video. It's actually crazy how much you move your head around. It is _literally_ making me kinda dizzy. It's like you're trying to hypnotize me-and it's _working_

[@dasten123]

ok, performing the navigation makes sense, but what does expecting "true to be true" accomplish?

[@lerarosalene]

Many test frameworks complain about not having explicit assertions in them.

[@Robert-yw5ms]

​@lerarosalene which is a hint that either the testing library is defective or Kent is using it incorrectly. Either way he shouldn't be so proud of this test.

[@piaIy]

@@Robert-yw5ms Kent's answer to a similar complaint under his tweet: "This was written a long time ago before there really was anything on the page. I'm just saying that the difference between no tests and your first test is an enormous amount of confidence :)"

[@cameron1376]

Nifty stuff mate++ Thanks for this++

[@BeCurieUs]

Every one of our base components has a unit test that basically just renders it as it. A great test to have. test('Some Component renders without crashing', () => { const div = document.createElement('div'); ReactDOM.render( , div ); ReactDOM.unmountComponentAtNode(div); }); for basically every component

[@sa3dclay859]

Senior (make it simpler)

Nah, we just lazy to actually check the rendered page. As long it render, then we push to prod.

[@sa3dclay859]

Not exactly, I have seen it, some times developers write tests to check if the event is fired and how many times and with which attributes, etcetera, In my opinion, these extra checks are not useful and do not really serve the main idea of unit tests!

[@angell2341]

You are amazing

[@kisaragi-hiu]

Something like this needs a comment to explain its purpose or even just to reassure the reader that yes, the writer knows what they're doing. This might be hard for a common pattern, but if it's the only test in a project a single comment would've reduced the confusion to zero.

[@doniaelfouly4142]

Thanks

[@nightshade427]

These are also known as indirect tests/scenarios, been around forever

[@lancediduck6278]

Wow. You guys just discovered precondition tests. Who knew?

[@ergeorgiev]

You implicitly have a test that tests all of those things, a dev refactoring the code doesn't know that so only focuses on the one explicit purpose of the test when rewriting it. So there's a downside to implicit testing. Also, integration tests.

[@SlenderMiner99]

Genuine feedback: I am not sure if the video needs your facecam to effectively get the point across and your shaking head while you're talking is strongly distracting me from the text content that I am trying to read. Perhaps consider omitting the facecam or at least reducing head movement.

[@mrcheeseguyman]

lmao dude

[@psybitcoin]

Lol

[@FlanderDev]

Truth can hurt

[@Levi_OP]

If you want to read it why don’t you just go read the article on your own? Do you just want a voiceover you can read along to?

[@ariassingh462]

This makes no sense. Either cover that portion of the screen with your hand, or you know, read the actual article?

[@lbgstzockt8493]

I wonder how many of these tests are completely redundant in a statically typed and compiled language.

[@savageteam354k4]

hey men i really love the like your video it is deep and very helpful but right now i really struggle about file management like every time when i want to do some practice i always install react app again and again specially i am very confused by the installation of necessary files like nodemon , express and run my file on terminal and like so on things really hard for me so can you make a tutorial video on how to handle files and folders, do we have to install every time when we want run our app or so many things please?!

[@alanonym8972]

I am confused at how you are struggling with file management. If you want to practice, you should have a single project and push your knowledge to the limit on that single project. It is pointless to start a dozen project and never take it to the end, you will never learn the hard stuff by doing so. Any online tutorial "get started with react" would give you what you want in a few seconds, you do not need a video for that.

[@zuka1100]

You don’t have to do npm install every time you start a project. What you can do is to make a template that you have already done npm install in and then copy and reuse it anytime you want to start a new project for practice. And when you think you want to start a new project with all the new features that you may not have in the previous version which is the template you created. Then you do another npm install

[@XiaZ]

Isn't this already the norm, like, from the beginning of testing era?

[@asagiai4965]

Hot take I think there should be an easy way to implement tests in most ide Also, some predefined tests that are always in used must be included.

[@piaIy]

There is an easy way, it's called Copilot.

[@asagiai4965]

@@piaIy You can use copilot, but as of right now it doesn't give the same experience and functionality.

[@AlternativPerspectiv]

We also expect that we are running javascript. 1 point.

[@vlc-cosplayer]

My man took the advice of "Don't test the implementation details" a bit too far, and said "just do end to end testing lmao" 💀

[@RishiRajxtrim]

👍

[@TheStickofWar]

Don’t be so amazed. You don’t need the assertion, the rest running and not crashing alone is enough for this type of test. It isn’t even worthy as a whole topic, if you’re not testing your component just renders then you’re doing something really wrong.

[@Nellak2011]

In real projects, NEVER use implicit tests. Implicit tests are non-intutive and as a result may be removed later by maintainers believing them to be trivial tests. Also, since they are implicit, it makes what they are testing unclear. Instead, you want Explicit tests that make it clear what the purpose is. You also want Property Based Tests rather than Example Based Tests, so that you don't forget edge cases.

[@nanonkay5669]

Don't test functionality, test behavior

[@mtranchi]

holy crap, something other than react. I unsubscribed a couple weeks ago because you seem to be solely focused on react these days...

[@alexlowe2054]

The idea of writing implicit tests goes strongly against another idea I've heard, which is that each test should test the smallest and most basic functionality it can. That way, the purpose of the test is clear for anyone who needs to rewrite the test, or debug a failing test. It prevents the need to provide tons of code comments, because the assert statements provide all the context needed to understand exactly what the test does. Writing implicit tests goes directly against that goal. That implicit test is impossible to debug directly, since it gives zero information or context about what exploded. Writing lots of implicit tests makes your system effectively impossible to update without a deep understanding of every one of those tests and a deep knowledge of the entire system you're testing. Never once did you mention what "type" of test this is. I find that so many people confuse different types of test at different levels. This isn't a unit test. This is a smoke test. Still, having a single barely functional smoke test is infinitely better than zero smoke tests, since it helps validate that everything is functioning in the official environment with all the integrations and other issues. But it's still important to know what type of test you're writing, since the objective of each type of test is dramatically different. If someone wrote a unit test like this, I'd immediately close their pull request and schedule a meeting, because this is the world's worst unit test. But as a smoke test, it's okay-ish. It's important to know what level you're testing at. This also highlights the big differences between front end dynamic JavaScript, and back end compiled code. In my world on the back end, we don't need to validate that the type is correct, since the compiler validates that we're using the correct type. Compiling your code is evidence of a whole host of valid behavior and assumptions. Those validations get even better if you're using something like the nullable type checks in C#, and making sure you're fixing any nullable warnings in your code. Being able to have a compiler explicitly tell you every possible place your code can throw a null dereference is an incredibly powerful tool. This video could definitely use some improvement, but it helped me clarify a concept in my mind, that the difference between low level testing and high level testing is how much of the test is implicit. I think this will help me start writing better high level tests, since that's something I've always struggled with. It's a normal instinct to test the most basic functionality first, but I think this flips that idea on its head. If you want to catch the largest possible number of issues, you should start by writing the most simple test that touches the most complex behavior in your system.

[@kitamashi]

bro talks by shaking his head

[@sadanyagci]

I'm all for implicit testing. But it isn't explicitly clear what is being tested. So every implicit assertion should be listed in a comment above the test. That way, if it fails, you can go from top to bottom with that list to debug the issue. If someone else has to deal with your code, that implicit test won't tell them what it's for or how to debug it. In 3 months, you will forget half the reasons for that implicit test. In 3 years, you'll be grasping at straws to determine what it's there for at all. Code should be as explicit and clean as possible. If you do something implicit, explain it well in a comment. On top of that, you can use the implicit test to trigger a list of explicit tests, to determine specifically what went wrong, so you can get a report about it and quickly fix the issue.

[@waxfrenzy]

One (good) system test is worth a thousand unit tests

[@waelltifi-2023]

i don't care what anyone thinks , 99.9 % of unit tests in front end especially in that react sh!t IS AN ABSOLUTE WASTE OF TIME !!!

[@Robert-yw5ms]

Pretty sure Kent already agrees with you.

[@piaIy]

Even the creators of RTL agree with you and recommend integration testing instead.

[@blueghost512]

If my NestJS builds successfully, it means it should work. No need for testing

[@KentCDodds-vids]

Oh hi 👋

[@WebDevSimplified]

👋 I just want to say your testing content (including your testing JS course) is incredible. I have learned so much from it all.

[@KentCDodds-vids]

@@WebDevSimplified thank you ☺️

[@GesteromTV]

You shoude not unit test a ui, it just dosen't make any sens

[@jhirn2957]

But it's not going to fail... because of the implication.

[@GaryFerrao]

this is a good thing? lol i will check that the GET response code is valid. tell… me… your… intentions.

[@GaryFerrao]

i get it that we need to make assumptions when testing. but it doesn’t mean you hide your intentions when programming.

[@Dr-Zed]

I hate that assertion. Why does it exist? To make a shitty pinte rhaopy?

[@TheSliderW]

I promise, you can write better explicit code and even have time for usefull comments when you don't waste time writing useless tests and test cases.

[@zyt4zcn]

The test is fine, the assertion is idiotic

[@TheStickofWar]

Agree

[@-taz-]

It seems like a failure would throw an exception which would fail the test? And the assertion would also pass so it's just a useless statement?

[@mikemorrison5080]

@@-taz- They could be using some linter which complains if you don't make an assertion.

[@AlternativPerspectiv]

This is dumb. Sorry. This feels like the big deal made back when inline css became a thing, then a new movement against inline css came along with inline js then the next movement... each one was made to sound like THE way to do things. We are now at JSX and Typescript and next month something else will com along and be THE way to do things. Been there, dun that.

[@AlternativPerspectiv]

My guy, you are usually very good at diving into the subject matter but at 1:00 you are still just hyping up the video/subject! C'mon!

[@tinahalder8416]

Wanna get fired as a Validation Engineer? Sureeeeeee

[@michawhite7613]

Please say April Fools

[@pyromancy8439]

Wow, that's a horrible way of describing a "homepage rendered successfully" test. Tests should be written to be as descriptive of the tested logic as possible, that's the whole point of expect-style test DSLs. When another developer looks at this, they would think that this is a test that is supposed to check whether true is true, so if you're reading this, please, don't write tests like that.

[@aisdjsiasiodjisoajd7698]

Kent C. Godds

[@etilworg]

shit test for developers that dont test changes .

[@KaiHenningsen]

Well, ackshually ... expect(true).toBe(true) also checks that your test suite is at least somewhat functional.

[@fullfungo]

This is just a library abuse. If you are testing that “await xyz()” doesn’t throw errors, then WHY THE HELL would you write “expect(true).toBe(true)” instead of the obvious, and more sensible “await expect(xyz()).resolves.not.toThrow()”?? The example you showed makes absolutely no sense. All it does is obfuscates the test, so that it becomes unintuitive for any future maintainer.

[@tririfandani1876]

Please make more videos about epicweb / epicstack / remix

[@KrzysztofWojnar]

expect(true).toBe(true) is redundant garbage. Downvote