Когда я был молод, я не писал модульные тесты

JavaScript модульный тест

В крупномасштабном проекте с несколькими людьми, работающими вместе, мы можем часто встречаться с следующими проблемами во время процесса разработки:

  • Эй, в этот раз я не изменил это здесь, как может быть ошибка?
  • Эй, как получилось, что добавлена ​​новая функция и затронута исходная функция?
  • Эй, почему стиль здесь испорчен?

Когда нам представили эти баги, мы были ошарашены, потому что это не оправдало ожиданий программиста! ! !
Итак, как мы можем избежать вышеперечисленных проблем и использовать наш опыт для дальнейшего развития (написание ошибок)?
Здесь я пытаюсь обобщить решение проблемы

Проблемы со стилем требуют соответствующих спецификаций

  • Не может использовать CSS, можно использовать только меньше для записи
  • Класс модульного письма с использованием меньшего
  • Стиль именования принимает БЭМ

(рекомендовать)

.app{
    width: 100%;
    .center{
        height: 100%
    }
}

(Не рекомендуется)

.app{
    width: 100%;
}
.center{
    height: 100%
}

Как насчет доступности устаревших функций?

На самом деле я и раньше имел краткое представление о юнит-тестировании, но относился к юнит-тестированию на тот момент очень негативно, потому что это было слишком безвкусно, и тестировали какие-то совсем уж базовые функции, но когда автор попался на этом время После мучений рефакторинга я переосмыслил, как обеспечить робастность кода.С таким настроем автор отправился исследовать, на что способны юнит-тесты.

Прежде чем мы поговорим о том, что он может сделать, давайте поговорим о том, что это такое?

С точки зрения буквального анализа, это значит разбить ваш код на модули один за другим, а затем написать разные тестовые примеры для разных модулей.

На этот раз у нас возникнет вопрос: если юнит-тест пройден, может ли он выйти в онлайн напрямую без тестирования студентов?

В соответствии с нашей идеальной ситуацией, если охват нашего тестового примера достигает более 5 девяток, его можно будет выпустить напрямую, но в это время у нас все еще есть некоторые сомнения в наших сердцах, то есть в том, что каждый модуль был пройдено, не будет ли проблем с интеграцией? На самом деле это вопрос, в котором я до сих пор не уверен. (Получение интеграционных тестов может решить эту проблему? Если у вас уже есть ответ, исправьте меня ниже)

Исходя из этого, автор надеется, что написание тест-кейсов во фронтенде позволит достичь следующих целей:

  • Сначала убедитесь, что основные функции каждого модуля работают нормально.
  • При добавлении новых функций исходные функции не затрагиваются.

Чтобы выполнить вышеуказанные требования, автор представит конкретное использование.Что касается ключевых моментов различных тестовых фреймворков, эта статья не будет подробно раскрываться.Наконец, в сочетании с нашим проектом, мы, наконец, приняли jest+enzyme facebook. Основное внимание будет уделено расширению следующих двух тестов типа компонента реакции.

Тестирование компонентов дисплея

Тестирование компонента дисплея означает, что каждая модификация соответствует ожиданиям.Здесь я хочу сосредоточиться на функции моментального снимка в фреймворке jest.

Shapshot делает снимок компонента для записи текущего состояния.Каждый раз, когда вы запускаете jest, сравнивайте его с последним разом, чтобы увидеть, есть ли какие-либо изменения. Идеальная ситуация заключается в том, что мы упаковываем все стили css, затем визуализируем пользовательский интерфейс компонента, сравниваем предыдущую запись, чтобы увидеть, есть ли какие-либо изменения, но, к сожалению, файлы моментальных снимков, сгенерированные shapshot, в настоящее время содержат только классы и ничего общего. если вы не напишите все стили как встроенные стили, тогда он может записать ваши стили стилей. Кажется, что мы не достигаем цели.

Но, если хорошенько подумать, это на самом деле идет вразрез с первоначальным замыслом нашего модульного теста. Здесь автор также делает смелое предположение. Когда официальная шутка реализует эту функцию, она должна хотеть только записать html-структуру текущего компонента после следующий шаг Сравните с последним снимком, чтобы увидеть, работает ли функциональность должным образом. Код относительно прост:

describe('XJLayerCard', () => {
    it('renders correctly', () => {
        const wrapper = Enzyme.render(<XJLayerCard {...mockData}/>);
        expect(toJson(wrapper)).toMatchSnapshot();
    })
})

Тестирование функциональных компонентов

Функциональное тестирование компонентов должно охватывать основные функции компонента, чтобы гарантировать, что после каждой модификации после запуска модульного теста можно определить, что предыдущая функция была нормальной.

Сначала я думал, что модульное тестирование было очень безвкусным, потому что я не понимал его глубоко.На этот раз я обнаружил, что даже компоненты, которые тесно интегрированы с бизнесом, могут имитировать нормальные операции.Вот пример компонента, объединенного с редуктом.

import React from 'react';
import Enzyme from 'enzyme';
import AppInput from '../AppInput';
import toJson from 'enzyme-to-json'
import initialStore from '@/../__mocks__/store.js';
import appInfoData from '@/../__mocks__/appInfo.js'
import { Provider } from 'react-redux';
import configureStore from '@/entries/maker/redux/store';
import { updateAppInfo } from '@/entries/maker/redux/action';
import moxios from 'moxios';
import instance from '@/api/instance'
import Adapter from 'enzyme-adapter-react-16';
Enzyme.configure({ adapter: new Adapter() });

let store;
let wrapper;
beforeEach(() => {
    moxios.install(instance);
    store = configureStore(initialStore)
    wrapper = Enzyme.mount(
        <Provider store={store}>
            <AppInput onChange={(obj) => {
                store.dispatch(updateAppInfo(obj))
            }}/>
        </Provider>
    )
})
afterEach(function () {
    moxios.uninstall(instance);
})
describe('demo', () => {

    it('renders correctly', () => {
        expect(toJson(wrapper)).toMatchSnapshot();
    });

    it('click div, select show', () => {
        // 渲染选项框正常
        expect(wrapper.find('.xj-appinput-item').length).toEqual(2);
        // 一开始没有输入框
        expect(wrapper.find('input').length).toEqual(0);
        wrapper.find('.xj-appinput-value-wrapper').at(0).simulate('click');
        expect(wrapper.find('input').length).toEqual(1);
    });

    it('updateAppInfo action', (done) => {
        // 拦截请求
        moxios.stubRequest('/app/get', {
            status: 200,
            responseText: 'success'
        });
        // 点击下拉框中的第一个,会触发action
        wrapper.find('.xj-appinput-item').at(0).simulate('click');
        moxios.wait(() => {
            // mock数据
            let request = moxios.requests.mostRecent();
            request.respondWith({
                status: 200,
                response: appInfoData
            }).then((res) => {
                // input输入框消失
                expect(wrapper.find('input').length).toEqual(0);
                // 选中的app展示出来
                expect(wrapper.find('.xj-appinput-wrapper').length).toEqual(1);
                expect(toJson(wrapper)).toMatchSnapshot();
                done();
            }).catch(err => {
                console.log(err)
            })
        });
    })


})

Как видите, тестовый контент здесь представляет собой комбинацию библиотек redux и axios. На самом деле весь процесс состоит в том, чтобы инициализировать компонент, чтобы увидеть, соответствует ли визуализированная HTML-структура ожидаемому, затем щелкнуть раскрывающийся список, выбрать первый, инициировать запрос, получить подробные данные, а затем посмотреть, соответствует ли компонент отображается нормально, после написания тест-кейса он уже смоделировал всю ручную работу с кодом, как насчет этого, он очень мощный?

Я думаю, это полезно, дерзайтепометить это


Категории