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!
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'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.
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).
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".
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?
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.
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.
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.
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.
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.
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.
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
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.
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_
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.
The comment about the du implicit test is interesting. In a compiled, strictly typed language like c# these implicit tests are done by the compiler! It doesn’t just import some file. It links an assembly. Any code that uses „sum“ not existing will not compile. If sum has two parameters you can not call it with one ore three. And you know what sum returns: you declared it. All that without writing any test. In C# such a test is futile. It would test if the compiler works. It does! So many up and leave JS/Python/Script X behind and use strongly typed/compiled. A first step is using TS 😊
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.
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.
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
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
@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 :)"
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
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.
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.
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
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!
I miss any mention of downsides of this approach. Makes me think the author didn't go deep in understanding of this topic. And, btw it's smoke test not smoke screen test.
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.
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.
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.
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.
It feels like a lazy solution to testing things in your code. Sure, it will only pass if all things go right, but if something blows up, the test case would fail. How willl you debug it, if the only error message that you see is about the overly generic test case failing? Sure, most of the testing frameworks hide all logs that the program spits (even for the errors, afaik), which can be tackled by introducing the verbose flag. But aren't we mitigating our code base problems to lack of verbosity in the test case results?
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.
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
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.
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.
Tests aren't just about testing, they're about conveying meaning and intent, and this `await page.goto('/')` reveleas no intention. additionally, it's all dependend on the exact web testing library that you use. You might assume it will thrown an exception if it receives 404, but some don't. it's way better to explicitly specify the intended behaviours, and leave out testing implementation details. Isn't "implicit testing" just another word for testing implementation details? Looks like it.
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.
