Jest/Vitest interactive course (runs in the browser)

Jest/Vitest interactive course (runs in the browser)(howtotestfrontend.com)

52 points by howToTestFE 58 days ago | 13 comments

Vitest is a brilliant software. I wish that the vitest vscode extension would be managed in a more careful manner though, too buggy for me to use.

howToTestFE 56 days ago | |

yup vitest is great (my default choice for new projects).

vitest browser mode is really nice too. (new-ish feature, although at this point it isn't exactly new).

halflife 56 days ago |

Jest mocks allow developers to write bad code. Instead of separating concerns with DI, jest mocks overwrite the importing mechanism without any type safety. Also, if you wish to migrate to native node test runner, the mocks lock you into jest.

Use proper mocks with ts mockito and it will force you to write better code.

anon7000 55 days ago | |

You can get some type safety with jest mocks with jest.mocked

Anyways I mostly agree, it’s very annoying to use mocks in jest even past the code smell. But I also find certain DI codebases to be highly annoying too. Exceptionally verbose for what it actually accomplishes at times.

howToTestFE 56 days ago | |

100%. its a horrible code smell, and AI loves to jest.mock (or vi.mock()). (The most recent blog post on my site covers this as one of the things to look out for in AI generated tests...)

in JS (with Jest/Vitest) it is far too easy to call mock()...

jitl 56 days ago | | |

i view this as the strength of dynamic language like JS or Ruby rather than a weakness: look at all the busywork a language like Java would otherwise inflict on us that we’re able to avoid. it takes a single syntactic lint rule to enforce type safe use of these module mock APIs (enforce `testlib.mock<typeof import(P)>(P, …)`), and only about 100 lines of one time setup to add mock helpers in vitest to mock a specific export rather than the whole module. There are also lint rules that prevent pretty much all scoping problem misuse of hoisted apis like testlib.mock.

Your course should mention these techniques! Without them tests are unsound!

We do some dependency injection of our framework-level service objects like ServerApiService or RouterService or RecordCacheService (usually with a subclass of the actual implementation) but it hardly needs to be ubiquitous or typical for product developer code.

locknitpicker 55 days ago | | |

> 100%. its a horrible code smell (...)

It's a testing technique used particularly in legacy projects called characterization tests. If you are faced with covering with tests a component you didn't wrote and you don't want to introduce a regression when refactoring it, you just mock existing function calls to assert observable behavior.

In compiled languages such as C++ this is even done with link time stubs.

Calling it code smell conveys the idea you are inexperienced and lack any experience managing test coverage.

epolanski 56 days ago |

I think unit testing FE to be borderline useless and very expensive to maintain.

I have seen so many broken products where leads where obsessed with 100% coverage and quality tests I just don't believe the methodology.

E2Es are the only tests that tell you whether the product is making money or not with a good approximation.

You have to invest in reducing flakiness and their run time, but if my 5 men team maintaining 6 products could, I think it can be done by more people, yet so many seem to be burned on their 10 year old experience..

Of course there are situations you want to test via normal unit tests and even do TDD (parsers/encoders/math stuff, etc) or you're writing libraries, but the people testing react components and such are involved in delusional productivity porn if that's not the case.

prinny_ 56 days ago | |

The value of FE unit testing is inversely proportional to the amount of mocking in said tests. I once worked on a complex admin dashboard with lots of business edge cases. The unit tests for the forms and the settings didn’t have any mocks and therefore we could catch legitimate bugs. On the other hand I have worked on code bases with so much mocking that I couldn’t make the tests to fail by intentionally bricking the component.

benoau 56 days ago | |

I strongly prefer Playwright over frontend unit tests, just doing what the user does against the system in its entirety, jiggle parameters like resolution and locale / timezone to really lock it down. A good Playwright test suite makes a lot of backend e2e and unit tests redundant.

crab_galaxy 56 days ago | |

Mostly agree. I do find that FE unit tests are a decent litmus test for complexity though. IMO the more difficult it is to test your react component, the more you probably need to think about breaking your component down.

jickmao 55 days ago |

The hard part of Jest/Vitest isn't the API — it's understanding async behavior, mock boundaries, and when to test implementation vs. behavior. Does this cover those patterns or mostly syntax?

howToTestFE 58 days ago |

learn step by step the main features of both Jest and Vitest (they're very similar for most common usages) in these interactive4 lessons