Storybook’s visual regression testing tool Chromatic is powerful but expensive. Luckily, with tools like Playwright, we can build a free alternative for running visual regression tests on our UI components. In this article, we’ll explore how to integrate Playwright with Storybook and use Docker to ensure consistent test results across different machines and CI environments.
Recently, I was back on the job hunt. At one particular interview, my potential future colleagues and I got into a discussion about testing, specifically the term end-to-end testing. I was in the awkward position that I didn't have a word to describe a type of test where you run your web application in a real browser...
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...
In this article, we'll explore the integration of AI-assisted development with established best practices. We'll discuss how to leverage techniques like TDD, writing user stories, and setting acceptance criteria in the post-ChatGPT era, addressing the limitations and opportunities presented by LLMs...
I could never quite wrap my head around how to test SSR applications (Nuxt, Next.js, Laravel, etc.) that talk to HTTP APIs (e.g., microservices). Using the built-in mocking capabilities of tools like Playwright and Cypress is not possible in this scenario because...
When we dive into the world of testing in programming, it's easy to get caught up in the numbers game—how many tests have we written? What's our code coverage? However, if we pause and consider the bigger picture, we realize that the true measure of success isn't the output it's the outcome...
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 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...
Today we'll explore how we can use Docker to run our tests in a standardized environment in order to prevent false positives because of differences between operating systems...
Assuming that we already have integration tests and unit tests in place, it’s time to take a look at how we can build our next line of defense against unwanted regressions in our app. In this article we'll use Jest and Puppeteer to set up Visual Regression Tests...
This is a followup article of my previous article about Integration Testing Vue.js applications with Cypress. In this article, we test the same application but, instead of using Cypress, we want to use the combined forces of Jest and Puppeteer...
In my previous article about Advanced Component Composition, we wrote Unit Tests for all of our Vue.js components except the Container Components. Writing Unit Tests for components with a lot of external dependencies (e.g. making API calls or accessing the $route object) is usually very hard to do because most of the time you have to mock a lot of their dependencies...
If you test Vue.js Components with a certain complexity, oftentimes you'll be faced with the situation of repeating the same component initialization code again and again. There are multiple patterns to deal with situations like that but today we'll take a look at how we can solve this problem by using a wrapper factory function...
My very own CSS framework avalanche, uses BackstopJS for regression testing. Unfortunately, for the most time, this didn't work as expected on my continuous integration service of choice: Travis CI. The rendering of fonts is slightly different on the Linux image which is used on Travis CI compared to macOS which I use for development...
As most of my regular readers have probably already noticed, I'm a huge fan of testing all the things. In many of my recent articles, we've already explored multiple techniques for unit testing and acceptance testing. Unit testing ensures that certain parts (or _units_) of our code do work correctly with acceptance testing, we can guarantee that what we've built does what it should do. Visual regression testing makes it possible that we can test if our application looks the way it's supposed to look...
Although testing, and especially acceptance testing, seems like a rather boring topic (at least to many developers) in the past few months I acquired an interest in optimizing the test setup and come up with better ways of writing tests. Especially when using Nightwatch.js in combination with Cucumber.js, there is another challenging aspect to it: writing step definitions...
In my previous article about automated acceptance testing with Cypress I explored the possibilities of the `cy.route()` and `cy.clock()` commands. Because I fell in love with how easy it is to stub network requests and manipulate JavaScript timeout functions (like `setTimeout` and `setInterval`) with those two commands, I began to feel bad about not having this functionality in Nightwatch.js und Cucumber.js powered acceptance tests...
This is the second part of my article series about automated acceptance testing with Cypress. In the first part of this series we've learned how to set up Cypress. Today we're going to take a look at two advanced features of Cypress: Network Stubs and Timers...
In today's article, we're going to take a look at one of the rising stars in the automated end-to-end testing scene: Cypress. When I first discovered Cypress, I thought that it looks very promising, but I was skeptical if it can live up to the hype...
Today we're building a modal dialog in Vue using Vuex. In my last article about exploratory TDD I wrote about the lack of tutorials demonstrating TDD in more complex, real world scenarios, so I decided to guide you through the whole process of building a modal dialog using the TDD methodology...
I'm currently working hard on making TDD my default way of writing code. Although I have noticed that the more I practice TDD, the easier it becomes, I still often fall back on writing dozens of lines of code without running tests that cover them...
Thanks to the vue-test-utils, testing Vue components has become much more comfortable. But things can get a little more complicated if you add Vuex to the equation...
Today we will examine two ways how we can speed up the testing process with Nightwatch.js – because faster is always better. The first small speed improvement can be achieved by eliminating Selenium from the setup...
Testing Vue.js components is different from testing regular JavaScript modules or classes in two ways. First of all Vue.js components depend on Vue.js, its global state and oftentimes on plugins like Vuex or the vue-router. Second, Vue.js single file components usually are compiled with webpack, the regular workflow of using Babel to compile JavaScript code before testing it, is not sufficient in this case. Let's find out how to deal with those challenges...
Today, in the third and final part of this series about acceptance testing with Nightwatch.js and Cucumber.js, we will integrate automated cross-browser testing powered by BrowserStack into our workflow...
In an ideal world, it should be possible to write basic acceptance test specifications without having to add any new step definitions. In the real world this is not always possible, because some features, with some very specific functionality, might need special treatment and are impossible to test without writing custom step definitions...
Nightwatch.js is battle-tested and has proven to be a potent tool in the utility belt when it comes to conducting end-to-end tests. The combination of Nightwatch.js and Cucumber.js enables the writing of robust automated acceptance tests in plain language (Gherkin) so that every project stakeholder can read and understand the test definitions...
Today we're going to look at the approach of using CSS selector namespaces to help us with detecting changes which have to be considered in the tests. Using separate selectors for testing also leads to a more stable way of structuring our code without tightly coupling our tests with the markup and CSS styles of the implementation...
One problem you might encounter when trying to run cross-browser tests in multiple browsers on BrowserStack with TestCafe is the parallel test limit that depends on your BrowserStack plan. At the time of writing, all regular BrowserStack plans include only one parallel test - which means you can only run one automated test at a time...
In this article we'll build acceptance tests powered by TestCafe, BrowserStack, and npm scripts. After setting up local testing we configure Travis CI to automatically run our tests after pushing new code to a Git repository...
In this article, we will examine how to write unit tests for JavaScript code that is intended to run in the browser. We will use use ava as our test runner and the mock-browser package to simulate a browser environment...
A few months ago I started learning more about TypeScript. It was very refreshing and I learned a lot about type-based programming in general. So I was overcome by the natural urge of every programmer who is learning a new technique that they enjoy: I wanted to rewrite everything I ever built with TypeScript...
This is a pattern to write JavaScript modules which are fully testable by unit tests but also easy to use without the overhead of directly using a factory function. You might use this pattern when you want to use unit tests but you do not want to give up on the flexibility of a modular, dependency based approach of structuring your code...
For a long time testing and test-driven development (TDD) was a magical thing for me. I didn't really know what it meant and it seemed to be something only “real” developers can do correctly. Many developers suffer from imposter syndrome and so did (sometimes even today do) I and I was too scared to get into this magical thing called TDD. Two or three years ago I started to work...