Tdd

Vite brought super fast bundling and hot reloading to our regular dev workflow, and Vitest is doing the same for our testing workflow. So I'm mostly transitioning away from Jest in favor of Vitest. But there are a lot of amazing tools in the Jest ecosystem, and not of them can be easily replaced. Luckily, the Vitest API is mostly compatible with the Jest API...

The JavaScript ecosystem has a lot to offer when it comes to testing. With the recent addition of Vitest we get the performance and convenience features of Vite for testing too. Mock Service Worker is an excellent mocking solution for mocking network requests in the browser and Node.js...

When we first start to dip our toes into the deep waters of automated software testing, all those different kinds of tests can feel intimidating. In this article, I give you a quick overview of the most crucial testing strategies. After reading this tutorial, you should have a much clearer picture of the strengths and weaknesses of the different kinds of testing methodologies...

Out of the box, Cypress offers an amazing live-reloading feature. But there is one caveat: live-reloading only works when changing test code, not when updating the application code. Nowadays, we are used to live-reloading in the browser thanks to webpack hot module replacement (HMR) and other fantastic development tools like Vite or Snowpack. If we had something similar in Cypress, practicing TDD would be a lot easier...

When testing components (e.g., Vue or React) or regular JavaScript modules, we typically want to decouple our test code from the implementation as much as possible. Ideally, we want to write black box tests. That means that we are only allowed to interact with the public API of the component under test...

In this article, we will take a closer look at how we can run automated cross-browser acceptance tests in real browsers on LambdaTest using TestCafe as our test framework...

A few weeks ago, I wrote about naming unit tests BDD style using Given/When/Then. In this article, I have expressed the thought that I do not like to repeat information in the description and in the expect statement. After writing some tests the way I've described in this article, I noticed a couple of drawbacks...

For the most time, when writing unit tests, I favored the it should ... pattern for naming my tests. But time and time again, I noticed that when following this naming convention, I either had to write very long test cases or omit important information...

Last week was a slow week when it comes to discovering or learning about new things. Here are a few things I encountered...

Last week I did go down the rabbit hole reading about TDD best practices and misconceptions. Everything began with a Twitter discussion about David Heinemeier Hansson's (old) article: TDD is dead. Long live testing...