Test-Driven Development // Fun TDD Introduction with JavaScript

Great material, as always. Thanks!

Code tester

What was the purpose of installing Vite in this case?

The best Thumbnail ever on a Developers Channel! ✝️

writing code to pass tests is equivalent of making movies to get awards

Mutation testing for coverage.

Unit testing client facing JS = No thanks.

In 2023 we can just use Playwright to cover important paths and Storybook to document and test all our component state in isolation or composition. Then we check all our use cases with interactions, accessibility and visuals regression tests. In my opinion this is way superior than standard Jest because it gives us way more confidence that all our use cases are working from the user's perspective in our supported browsers and viewports and that the visual were not impacted by CSS leaks. I don't see any benefits to TDD on the front-end for component driven apps whatsoever.

Watching this video to procrastinate on my stack data type assignment only for him to say let’s start by making a stack data type

thanks

The words 'fun' and 'JavaScript' do not belong in the same sentence.

You should build your stack inside each tests and not in the beforeEach() even tho it doesn't respect the DRY principle it respect a more valuable principle in TDD call AAA

TDD doesn't make sense in the front end

Guys is there any good source or course for Jest and Cypress , including the TDD ? I cant find any good one.

All tests should read top down. I really hate beforeEach etc. There should be no code in your tests. If anyone in my team writes code in tests I suggest that they write tests for their tests.

What would I do without fireship, lmao

Which vscode theme is this?

i never wrote tests, did not use typescript, had no clue about ci .. i learn this stuff right now in my new job and i love it!

Code coverage is a bad metric and should not be used. During TDD development test and code come and go. Some times tests go away because parts of the code is tested with other test. This leaves gaps in the coverage, but all the relevant functionality is still tested.
I often find that I am at the third or fourth generation of both tests and code when a relatively simple function or part of my code is done. This is mostly because my understanding of the problem at hand develops during development.
An often overlooked aspect of TDD is edge cases. You can get a false sense of accomplishment with one or two tests for a function; they test the core functionality of the function but only just that. If the function is fed garbage or something unexpected, it breaks. Putting some thought into this to get a 360 degree view of the code yields a much more robust code base.

I've read and watch a lot of TDD guides and I still can't wrap my head around why we needed it.

Thank you for making such an informative video im learning alot from it

But you go too fast and just speak too fast and do everything fast i have to stop every couple of seconds to make sure im following your steps

red being green and green being red in the first 1 second of video really messed with me

This is testing oversimolified. Love it!!

Could you do a course one cypress with js or do you have a course on that?

I prefer playwright to Cypress

Is it normal that I’m playing your videos all the time while i have a very little knowledge about what you’re saying just because your voice makes me calm 😐

This looks like a complete waste of time. Why would i do something as stupid as testing if an object is created, when i have no class for this object?

the first 30 seconds made me spit out my coffee.

❤️❤️

As a tech lead of the QA automation team in my company I can't stress enough how important is Cypress for web testing. And if done right it can do much more than Selenium with waaay less test flakyness

"Improve the maintainability in the long run" - false:
Catching side effect - and solving it is fine for the first time, but an application which is prone to repeated side-effects has an exponential curve on maintenance. Testing does not help that in any way shape or form.

Good tutor tho'

Comment for Commenting's sake.

Every example of TDD uses an extremely simple Mickey Mouse requirement. Implement a basic stack. And even then it's not fully tested. For anything remotely complex I've found TDD completely impractical. You'll end up rewriting all your tests again at the end when you discover that 95% of the methods and functionality were unaccounted for, or different than predicted.

Test driven development implies, that you write a failing test first, then write Code to make it green, then you refactor. Makes sense. Hands down, when you start the frontend of a webpage, do you start with a cypress test, or do you make a mock-up of some sort first? If you actually start with the cypress test, i can respect that. What kind of test do you start with if you have to train an AI model then? Just curious.

I'm a tester and this is one of the best explanations for different testing strategies one can look for

What's the advice on writing a correct test and how do one know their test is even correct when going taking TDD approach

@Fireship always keeping things simple and straight to the point, Thanks for this.
As someone just coming into testing and expected to do TDD one major challenge I face is not knowing if its my test that's bad or if my feature implementation are just wrong, this makes me cut corners. Writing the code then testing it (but this can lead to bias, as I've been told)

It was good to not show "mocking" here since it is in 99% times not needed. Mock frameworks get abused most of the time to write quick but bad tests.

Is tdd approach work with end2end testing? Idk how to use tdd in e2e testinf

Pog

Would love to see a tutorial on mocking in jest. I find it really tricky to understand

dynamic time-warping algorithm in jQuery in 100 seconds😁

I think add might have a bug init

The cool thing is, the error output tells you exactly what code to write next. Also it is more beneficial to have only one expect per test case. That way if the test fails you know exactly which part of the component is broken. Arrange, act, assert.