I used to think that the time to write test code is not as fast as a little bit of testing, and with such complex logic, writing test code is not easy, in fact, I now have the two points of complexity and time-consuming Some new ideas:
- First of all, it is not easy to write test code for complex logic. You must have a clear understanding of which businesses and functions need to write test code. Once you know this, you must pay attention when writing code. Use it in multiple places. The obtained code should be extracted into common code as much as possible, and the complicated logic should be divided as much as possible, and through the test code, it can be seen that the focus of the test is only the input and output, which bends and bends in the middle, If you don t care about these, then you will deliberately pay attention when you write business and functional code. What is the input and output? If the written code is coupled with many other things and there is no way to write the test code, then you need to Consider whether it is inappropriate to write code in this way, and see if there is a better way to write it.
- Secondly, for the time-consuming writing test code, it is better to test it quickly. I think so, maybe your project is too small, maybe your cognitive level has not reached this level, for example : Some companies need to run the test code continuously for 8 hours to finish all the test code. If you change to do it manually, the time consumed will be immeasurable, and it is very easy to cause problems if you manually test one by one. of. For writing test code, it may be a bit troublesome in the early stage, but it will save time and effort in the future and benefit mankind~
Test classification
1. Black box testing
In the common development process, there are testers. They only look at the outermost input and output regardless of the internal implementation mechanism. This is called black box testing . For example, if you write an addition page, you will design N use cases to test the correctness of the addition. This kind of test is called E2E test
2. White box testing
There is another kind of test called white box test . We write test code for some internal core implementation logic, which is called unit test .
3. Integration Test
Integration Testing is a collection of multiple tested units to test together.
The benefits of writing test code
- Provide documentation describing component behavior
- Save time on manual testing
- Reduce bugs generated when developing new features
- Improved Design
- Promote refactoring
Automated testing allows developers in large teams to maintain complex basic code. Let you change the code no longer cautiously
Ready to work
use tools
In vue China, it is recommended to use Mocha+Chai or Jest
1. To complete the test task, you need a test framework (run test), assertion library (write test) and a test suite specific to the programming framework .
2. The above Mocha is a testing framework, Chai is an assertion library, and Jest contains two at the same time.
3. The writing of test codes such as components in vue requires thevue-test-utilssupport of the suite.
New vue project/integration in existing project
-
New vue project
- Choose Unit Testing and E2E Testing
- Unit testing solution choice: Jest
- End-to-end test solution choice: Cypress
-
Integration in existing projects
Running
vue add @vue/unit-jestandvue add @vue/e2e-cypressNote: There are requirements for the node version when installing, and a version above 10.0 is required
unit test
Unit testing: Check and verify the smallest testable unit in the software.
write
After installing @vue/unit-jest, the project will have tests/unita directory, create a test file below, the naming convention: must be * .spec.js file name
//test/unit/test.spec.js
function add (num1, num2) {
return num1 + num2
}
// test suite
describe('test', () => {
// test case
it(' add ', () => {
// assert
expect(add(1, 3)).toBe(3)
expect(add(1, 3)).toBe(4)
expect(add(-2, 3)).toBe(1)
})
})
Assertion API introduction
1describe.: Define a test suite
2it.: Define a test case
3expect.: Judgment conditions for
assertion More assertion API
carried out
npm run test:unit
Test vue components
Vue officially provides a tool library for unit testing@vue/test-utils
- Create components
//src/components/testUnit/index.vue
<template>
<div>
<span>{{ message }}</span>
<button @click="changeMsg"> </button> </div>
</template>
<script>
export default {
data () {
return {
message: 'vue-text'
}
},
created () {
this.message = ' message'
},
methods: {
changeMsg () {
this.message = ' '
}
}
}
</script>
- Test component
import testUnit from '@/components/testUnit/'
describe('testUnit.vue', () => {
//
it(' created ', () => {
expect(typeof testUnit.created).toBe('function')
})
it('message vue-test', () => {
// data
expect(typeof testUnit.data).toBe('function')
// data
const defaultData = testUnit.data()
expect(defaultData.message).toBe('vue-test')
})
})
- Check the expected result after mounted
<template>
<div>
<span>{{ message }}</span>
<button @click="changeMsg"> </button> </div>
</template>
<script>
export default {
data () {
return {
message: 'vue-test'
}
},
mounted () {
this.message = ' message'
},
methods: {
changeMsg () {
this.message = ' '
}
}
}
</script>
import { shallowMount } from '@vue/test-utils'
import testUnit from '@/components/testUnit/'
describe('testUnit.vue', () => {
//
it(' created ', () => {
expect(typeof testUnit.created).toBe('function')
})
it('message vue-test', () => {
// data
expect(typeof testUnit.data).toBe('function')
// data
const defaultData = testUnit.data()
expect(defaultData.message).toBe('vue-test')
})
it('mount data message message', () => {
const wrapper = shallowMount(testUnit)
// `wrapper.vm` Vue
expect(wrapper.vm.message).toBe('hhhh')
})
})
- Test data changes after clicking the button
<template>
<div>
<span>{{ message }}</span>
<button @click="changeMsg"> </button>
</div>
</template>
<script>
export default {
data () {
return {
message: 'vue-test'
}
},
methods: {
changeMsg () {
this.message = ' '
}
}
}
</script>
import { shallowMount } from '@vue/test-utils'
import testUnit from '@/components/testUnit/'
describe('testUnit.vue', () => {
it(' ', async () => {
const wrapper = shallowMount(testUnit)
//
await wrapper.find('button').trigger('click')
//
expect(wrapper.vm.message).toBe(' ')
// html
expect(wrapper.find('span').html()).toBe('<span> </span>')
//
expect(wrapper.find('span').text()).toBe(' ')
})
})
Note: Any changes that result in manipulating the DOM should await the nextTick function before asserting. Because Vue will perform batch asynchronous updates to the ineffective DOM, avoiding unnecessary rendering due to repeated data changes.
End-to-end testing
Borrowing the capabilities of the browser, from the perspective of the user tester, the input box, click the button, etc., completely simulate the user. This has nothing to do with the specific framework and completely simulates the browser behavior.
Test file
//tests/e2e/spec/test.js
//https://docs.cypress.io/api/introduction/api.html
describe('My First Test', () => {
it('Visits the app root url', () => {
cy.visit('/')
cy.contains('h1', 'Welcome to Your Vue.js App')
})
})
run
npm run test:e2e
Modify the App.vue file
<template>
<div id="app">
<h1>Welcome to Your Vue.js App</h1>
<router-view/>
</div>
</template>
Test coverage
Jest comes with its own coverage rate. If you use mocha, you need to use Istanbul to count the coverage rate.
package.jsonModify the command configuration in:
script:{
"test": "jest --coverage"
}
package.jsonModify the jest configuration in:
"jest": {
"collectCoverage": true,
"collectCoverageFrom": ["src/**/*.{js,vue}"],
}
It can also be configured independently and created in the root directoryjest.config.js
module.exports = {
"collectCoverage": true,
"collectCoverageFrom": ["src/**/*.{js,vue}"]
}
carried out:
npm run test
%stmts is statement coverage: Is every statement executed?
%Branch branch coverage: Is every if code block executed?
%Funcs function coverage : Is every function called?
%Lines line coverage: Is every line executed?