How This Test Saved Kent’s Site
ฝัง
- เผยแพร่เมื่อ 5 มิ.ย. 2024
- 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
![ไม่ต้องมีที่ที่ให้ฉันอยู่ แต่ขอแค่มีฉันอยู่ก็พอ (Spaceless) - getsunova [SHORT FILM]](http://i.ytimg.com/vi/MuT0d_cvJkc/mqdefault.jpg)
Thank you for bringing light to the topic of implicit testing! Feels surreal to have your writing showcased ❤
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.
@@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!
Thanks kyle for making videos on testing stuffs. Nowadays there is less talk about qa guys especially on youtube. Expect more stuff on testing..
Web devs really be out here writing "tests" that load an entire page and calling it a day, huh?
No one does this bs, no company will allow this nonsense
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.
It also implicitly assumes that you are the only one ever going to have to read and understand the test.
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.
@@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.
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.
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".
This is the "testing" equivalent of "some things go without saying".
Love it, awesome refresher!
This channel is a gold mine of information. Thank you for making making me a better engineer.
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.
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?
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.
@@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?
Yeah, I've always seen tests like this assert no exceptions rather than asserting true -> true
I might start writing javascript tests now
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
@@petleveler8366 test your validators
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?
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.
@@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.
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.
@@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.
@@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.
Awesome. Thanks for sharing Kyle
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?
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.
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.
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
What's the purpose of hiding your true test in a riddle?
Just write an explicit test.
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.
Good stuff!
Does actually `goto` checks the page rendered without errors?
Seems like it only throws if your server fails.
Throw an exception in your component. What happens to this test?
What about coverage if you are using a software like sonarcloud?
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
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.
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.
Please, Can you do a tutorial on Backend Testing using TypeScript?
This reminds me of using assertions in C. They are kind of like sanity checks.
Simple but genius
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.
For smoke test it is great specially when features are added.
ok, performing the navigation makes sense, but what does expecting "true to be true" accomplish?
Many test frameworks complain about not having explicit assertions in them.
@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.
@@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 :)"
Senior (make it simpler)
Nah, we just lazy to actually check the rendered page. As long it render, then we push to prod.
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!
Thanks
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" 💀
What if there is no assertion at the end? Won't this still fail the test if there are problems?
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_
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.
Nifty stuff mate++ Thanks for this++
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.
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.
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?!
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.
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
These are also known as indirect tests/scenarios, been around forever
I wonder how many of these tests are completely redundant in a statically typed and compiled language.
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.
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.
There is an easy way, it's called Copilot.
@@piaIy You can use copilot, but as of right now it doesn't give the same experience and functionality.
Isn't this already the norm, like, from the beginning of testing era?
You are amazing
We also expect that we are running javascript. 1 point.
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.
lmao dude
Lol
Truth can hurt
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?
This makes no sense. Either cover that portion of the screen with your hand, or you know, read the actual article?
👍
Don't test functionality, test behavior
The test is fine, the assertion is idiotic
Agree
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?
@@-taz- They could be using some linter which complains if you don't make an assertion.
bro talks by shaking his head
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.
If my NestJS builds successfully, it means it should work.
No need for testing
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.
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!
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 !!!
Pretty sure Kent already agrees with you.
Even the creators of RTL agree with you and recommend integration testing instead.
One (good) system test is worth a thousand unit tests
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
But it's not going to fail... because of the implication.
holy crap, something other than react. I unsubscribed a couple weeks ago because you seem to be solely focused on react these days...
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.
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.
this is a good thing? lol
i will check that the GET response code is valid. tell… me… your… intentions.
i get it that we need to make assumptions when testing. but it doesn’t mean you hide your intentions when programming.
Oh hi 👋
👋 I just want to say your testing content (including your testing JS course) is incredible. I have learned so much from it all.
@@WebDevSimplified thank you ☺️
I hate that assertion. Why does it exist? To make a shitty pinte rhaopy?
Wanna get fired as a Validation Engineer? Sureeeeeee
Kent C. Godds
Well, ackshually ...
expect(true).toBe(true) also checks that your test suite is at least somewhat functional.
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.
Please make more videos about epicweb / epicstack / remix