Vue adopted a Single File Component philosophy, which has some benefits over splitting concerns, which you can read up on in the official Vue Docs. From a SFC philosophy, you’d want everything that relates to your component in a Single File. So let’s explore this take with our component tests as well, because why would your tests be any different than your scripts, template or styles?

We’re going to leverage a feature that Vitest offers, out of the box, to a Vue example code base. Bear in mind that this approach would be applicable to other implementations that leverage Vitest just as easy. Also, this is a thought experiment.

Having identified a number of different types of tests, you can already imagine that each tests has its own place in the process.

The process here is key: because software development is complex and consists of several steps, it just makes sense to validate each of these steps. We'll outline a lineair process, but of course in practice there's more iteration between steps. That's fine and is in fact where tests offer the confidence of moving back and forth!

Software development is complex. It involves people talking about an idea or concept and then translating it to code. The code then is compiled, packages or run and we expect a certain result. In all of these (generic) steps, there's room for complexity, interpretation and errors to sneak into the software.

Luckily, testing software has matured and expanded to a level where we can confidently release code that doesn't break on build, only changes where change is needed and the features can even be asserted before writing a single line of code!

I was seeing a lot of Playwright mentions in my timelines recently, so I decided to investigate what the fuss was all about. Playwright, as it turns out, is a tool for executing end to end (e2e) tests, similar to Cypress.

With Cypress being my go to tool to integrate e2e tests, I figured I could do a comparison on the two, to see which better fits my needs at this point.

Nobody that I know of is happy with endless repetition. Software has drastically improved any field of work where repetition takes place by facilitating a certain level of automation to ease all of our jobs. But when you’re implementing any automated process, there’s always a cost to consider.

The good news when working on software, is that cost is relatively low compared to effort. Since we’re working in a landscape that’s so very tightly coupled to the tools that provide automation, most of the automating is a breeze!

Why do you test? Is is because you want to prevent errors on a deployment affecting the visitor? Is it because you simply want to know that the software does what it needs to do? Or maybe you want to get to know the software a bit better?

Hopefully, in this day and age, your main software tests are automated. Running before a commit, running in the deployment pipeline and running on a testing environment. Repetitive jobs need automation and testing fits that mantra very well. This article is relevant for automated testing, although for certain topics you could use a manual testing perspective as well. If you like.