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..

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

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.

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

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.

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

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.

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.

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

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!

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 :)"

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

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.

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?

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.

Pretty sure Kent already agrees with you.

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

👋 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 get it that we need to make assumptions when testing. but it doesn’t mean you hide your intentions when programming.