---
title: "What to test in a Vue app (and what to skip) · vuejs.school"
description: "Unit tests for pure logic, component tests for what users see, a few end-to-end runs for the paths that pay. With a coupled test and its rewrite."
canonical_url: "https://vuejs.school/community/blog/what-to-test-in-a-vue-app"
meta:
"og:description": "Unit tests for pure logic, component tests for what users see, a few end-to-end runs for the paths that pay. With a coupled test and its rewrite."
"og:image": "https://vuejs.school/_og/d/a_~V2hhdCB0byB0ZXN0IGluIGEgVnVlIGFwcCAoYW5kIHdoYXQgdG8gc2tpcCkgwrcgdnVlanMuc2Nob29s%2Cc_OgCard.takumi%2Ctitle_What%2Bto%2Btest%2Bin%2Ba%2BVue%2Bapp%2B(and%2Bwhat%2Bto%2Bskip)%2Cdescription_~VW5pdCB0ZXN0cyBmb3IgcHVyZSBsb2dpYywgY29tcG9uZW50IHRlc3RzIGZvciB3aGF0IHVzZXJzIHNlZSwgYSBmZXcgZW5kLXRvLWVuZCBydW5zIGZvciB0aGUgcGF0aHMgdGhhdCBwYXkuIFdpdGggYSBjb3VwbGVkIHRlc3QgYW5kIGl0cyByZXdyaXRlLg%2Ceyebrow_~RGVlcCBkaXZlIMK3IDcgbWluIHJlYWQ%2Ctint_mint%2Cp_Ii9jb21tdW5pdHkvYmxvZy93aGF0LXRvLXRlc3QtaW4tYS12dWUtYXBwIg%2Cs_ygHBypxWS4K7bdsr.png"
"og:image:alt": "What to test in a Vue app (and what to skip) · vuejs.school"
"og:image:height": "600"
"og:image:type": image/png
"og:image:width": "1200"
"og:title": "What to test in a Vue app (and what to skip) · vuejs.school"
"twitter:image": "https://vuejs.school/_og/d/a_~V2hhdCB0byB0ZXN0IGluIGEgVnVlIGFwcCAoYW5kIHdoYXQgdG8gc2tpcCkgwrcgdnVlanMuc2Nob29s%2Cc_OgCard.takumi%2Ctitle_What%2Bto%2Btest%2Bin%2Ba%2BVue%2Bapp%2B(and%2Bwhat%2Bto%2Bskip)%2Cdescription_~VW5pdCB0ZXN0cyBmb3IgcHVyZSBsb2dpYywgY29tcG9uZW50IHRlc3RzIGZvciB3aGF0IHVzZXJzIHNlZSwgYSBmZXcgZW5kLXRvLWVuZCBydW5zIGZvciB0aGUgcGF0aHMgdGhhdCBwYXkuIFdpdGggYSBjb3VwbGVkIHRlc3QgYW5kIGl0cyByZXdyaXRlLg%2Ceyebrow_~RGVlcCBkaXZlIMK3IDcgbWluIHJlYWQ%2Ctint_mint%2Cp_Ii9jb21tdW5pdHkvYmxvZy93aGF0LXRvLXRlc3QtaW4tYS12dWUtYXBwIg%2Cs_ygHBypxWS4K7bdsr.png"
"twitter:image:alt": "What to test in a Vue app (and what to skip) · vuejs.school"
---
> Index of every page on this site: [llms.txt](https://vuejs.school/llms.txt)
## What unit, component and end-to-end tests each prove
A unit test calls a function and checks what it returns. It runs in milliseconds, needs no DOM and no browser, and when it fails the cause is in that one function. Its weakness is that it proves nothing about the wiring: the function can be perfect and never be called.
A component test mounts one component in a simulated DOM, interacts with it the way a user would and checks what it renders and emits. It takes tens of milliseconds, catches the wiring inside the component, and fails for reasons close to what a user would notice.
An end-to-end test drives a real browser against a running build of the app. It takes seconds, needs the server up, and when it fails the cause can be anywhere, from a CSS change that hides a button to a database that is down. It is also the only one that checks the whole app working together.
Cost rises down that list, and so does the confidence one test gives you. The sensible shape is therefore many unit tests, a reasonable number of component tests, and a handful of end-to-end tests. That shape is often drawn as the testing pyramid: not a rule to obey, just the natural outcome of putting each check where it is cheapest to run and clearest when it fails.
## Pure logic gets unit tests
Anything that computes without touching the DOM or a store belongs in a plain module, and plain modules are where unit tests shine. Pricing, date arithmetic, validation, sorting, formatting, the function that decides what comes next: write them as functions in `shared/utils` and test them with plain calls. A cart total is a typical case:
*shared/utils/cart.ts*
```
export type Line = { price: number; quantity: number }
export function cartTotal(lines: Line[], discountCode?: string) {
const subtotal = lines.reduce((sum, line) => sum + line.price * line.quantity, 0)
const discount = discountCode === 'STUDENT' ? Math.round(subtotal * 0.1) : 0
return { subtotal, discount, total: subtotal - discount }
}
```
*tests/unit/cart.test.ts*
```
import { describe, expect, test } from 'vitest'
import { cartTotal } from '../../shared/utils/cart'
describe('cartTotal', () => {
test('sums price times quantity', () => {
expect(cartTotal([{ price: 500, quantity: 2 }]).subtotal).toBe(1000)
})
test.for([
{ code: 'STUDENT', discount: 100 },
{ code: 'student', discount: 0 },
{ code: undefined, discount: 0 },
])('discount for code $code is $discount', ({ code, discount }) => {
expect(cartTotal([{ price: 500, quantity: 2 }], code).discount).toBe(discount)
})
})
```
Prices are in pence, whole numbers, so there is no floating point to argue with. `test.for` runs one case per object and fills `$code` and `$discount` into each test's name, so the report shows three named tests instead of one loop.
The habit this builds is worth more than the tests: when you find yourself wanting to test a computation that lives inside a component, move it out. The component gets simpler and the logic gets a cheap test.
## Components get behaviour tests
A component test should read like a short description of what a user does and sees. Mount it, click what they would click, assert what they would read. Take a quantity picker, a number between minus and plus buttons, bound with `v-model`:
*app/components/QuantityPicker.vue*
```
```
`defineModel` declares the `modelValue` prop and the `update:modelValue` event in one line. When no parent binds `v-model`, as in a test that mounts the picker on its own, it keeps the value locally and still emits the event.
Three things here are worth checking, because a user or the parent component can observe them:
- Clicking plus counts up.
- The count stops at `max`, and the plus button says so by being disabled.
- The parent is told of each change through `update:modelValue`.
Function names, internal state and CSS classes are invisible to both, so they get no test.
## Rewrite a test that depends on internals
Here is the test people write first:
*tests/unit/QuantityPicker.spec.ts**Breaks***
```
import { mount } from '@vue/test-utils'
import { expect, test } from 'vitest'
import QuantityPicker from '../../app/components/QuantityPicker.vue'
test('increment', async () => {
const wrapper = mount(QuantityPicker, { props: { max: 3 } })
await (wrapper.vm as any).increment()
expect((wrapper.vm as any).quantity).toBe(2)
expect(wrapper.findAll('button')[1].classes()).not.toContain('is-disabled')
})
```
It passes, and it is wrong in four ways:
1. It calls `increment()` directly, so it would pass even if the button were not wired to it.
2. It reads `quantity` off the instance, so renaming the ref breaks the test while the component still works.
3. It picks the second button by index, so reordering the template breaks it.
4. It checks for a class name the component does not even use, so that line passes for the wrong reason.
A `