К слову о юнит-тестировании переднего плана

В первую очередь сделайте рекламу своим друзьям, это знают большие ребята в кругу и те, кто собирается вступить в круг,Определенный курс и недорогие ресурсы на различных платформах, таких как Geek, Kaikeba и т. Д., Пакетные обновления, в руках этого передового приятеля по разработке и в то же время для службы руководства интервью и технического руководства для тех, кто собирается войти в отрасль, добавьте его!

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

1. Что такое интерфейсное модульное тестирование

Сначала мы должны уточнить, что такое тест:

Чтобы определить, соответствует ли конкретная цель стандарту, для проверки используется специальный инструмент или метод, и, наконец, получается конкретный результат.

Для процесса разработки интерфейса конкретная цель здесь относится к коду, который мы пишем, а инструмент — это тестовая среда (библиотека), тестовые примеры и т. д., которые нам нужно использовать. Результат инспекционного бюро должен показать, пройден ли тест, или предоставить отчет о тестировании, чтобы облегчить устранение неполадок и последующее устранение проблемы.

Основываясь на утверждении «что такое тест», чтобы облегчить углубленное понимание коллег, которые только занимаются фронтенд-разработкой, мы перечисляем «что не является» модульным тестом:

Тесты, которым требуется доступ к базе данных, не являются модульными тестами.

Тесты, требующие доступа к сети, не являются модульными тестами.

Тесты, требующие доступа к файловой системе, не являются модульными тестами.

--- Искусство модификации кода

Для тестирования подразделения «не является« ссылкой на объяснение, до сих пор выйти за рамки этого. Учитывая ограничения в области пространства, ссылку на содержание, я думаю, что у него будет предварительное понимание самостоятельно после того, как его посмотреть коллеги по развитию в первом концерте.

2. Значение модульного тестирования и зачем оно нужно

2.1 Значение модульного тестирования

Для текущего фронтенд-инжиниринга, стандартного и завершенного проекта, тестирование очень необходимо. Много раз мы просто завершаем проект и игнорируем часть теста проекта.Значение теста в основном заключается в следующих моментах:

1. TDD (Test Driven Development) — это проверенный принцип написания программного обеспечения, который охватывает больше функциональных интерфейсов.
2. Быстрая обратная связь по вашему функциональному результату для проверки ваших идей.
3. Для обеспечения безопасности рефакторинга кода статический код отсутствует, а контрольные примеры могут дать вам уверенность в изменяемой структуре кода.
4. Код, который легко тестировать, свидетельствует о хорошем дизайне. Прежде чем делать модульный тест, его нужно инстанцировать.Если у этой штуки много зависимостей, эта тестовая система будет занимать очень много времени, что повлияет на эффективность вашего теста.Что мне делать? Чтобы полагаться на разделение, класс минимизируется, чтобы обеспечить единую функцию, такую ​​​​как разделение представления и функции, поэтому ваш код также прост в обслуживании и понимании.

2.2 Зачем нужно модульное тестирование

1. Во-первых, это фундаментальная причина для интерфейсного модульного тестирования: JavaScript — это динамический язык, в нем отсутствует проверка типов и он не может обнаруживать ошибки во время компиляции; проблемы совместимости хоста JavaScript. Например, производительность манипулирования DOM в разных браузерах.
2. Правильность: тесты могут проверить правильность кода и убедиться, что вы знаете, прежде чем запускать его в жизнь.
3. Автоматизация: Конечно, можно тестировать вручную, а внутреннюю информацию можно распечатать через консоль, но это разовая вещь, и следующий тест нужно делать с нуля, поэтому работоспособность гарантировать нельзя. Написав тест-кейсы, вы можете написать их один раз и запускать много раз.
4. Объяснение: Тестовые случаи используются для проверки важности интерфейсов и модулей, затем в тестовых примерах будет задействовано использование этих API. Для других разработчиков, использующих эти API, чтение тестовых примеров — хороший способ, иногда более понятный, чем документация.
5. Стимулирование разработки и руководство по дизайну: Предпосылкой тестируемого кода является тестируемость самого кода. Чтобы обеспечить тестируемость кода, необходимо обратить внимание на дизайн API во время разработки. TDD играет такую ​​роль в продвижение теста вперед.
6. Гарантированный рефакторинг: Скорость итерации продуктов в интернет-индустрии очень высока, и после итерации должен быть процесс рефакторинга кода Как мы можем гарантировать качество рефакторинга кода? С поддержкой тестовых случаев вы можете смело проводить рефакторинг.

3. Как писать модульные тесты

3.1в общем

• При тестировании кода учитывайте только тест, а не внутреннюю реализацию
• Данные должны максимально имитировать реальность, чем ближе к реальности, тем лучше
• Полностью учитывать граничные условия данных
• Сосредоточьтесь на ключевом, сложном и основном коде и сосредоточьтесь на тестировании
• Используйте АОП (beforeEach, afterEach), чтобы уменьшить объем тестового кода и избежать бесполезных функций.
• Сочетание тестирования и функциональной разработки способствует проектированию и реконструкции кода.

3.2Две широко используемые методологии модульного тестирования

В модульном тестировании обычно используются две методологии: TDD (разработка через тестирование) и BDD (разработка через поведение).

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

3.3Я верю, что у вас будет ваше личное мнение по TDD и BDD после его прочтения. Здесь я сначала поговорим о моем понимании TDD и BDD:

TDD (разработка через тестирование):

Основная идея состоит в том, чтобы провести всю разработку через тестирование.

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

• Тестирование — это средство, а не цель. Основная цель тестирования — не доказать правильность кода, а помочь найти ошибки, в том числе низкоуровневые.

• Тестируйте быстрее. Беги быстро, пиши быстро

• Сохраняйте тестовый код кратким

• Не игнорировать неудачные тесты. После того, как команда начала принимать тестовую сборку, не удается, тогда они постепенно адаптируются до 2,3,4 или более провала. В этом случае набор тестов больше не будет функционировать

должен быть в курсе:

• Нельзя неправильно понимать основную цель TDD!

• Тестирование не для охвата и точности

• но, например, сообщая разработчику, какой код писать

• Красный свет (код неидеален, тест зависает) -> зеленый свет (пишут код, тест проходит) -> рефакторинг (оптимизируем код и убеждаемся, что тест проходит)

Процесс TDD:

1. Анализ требований, обдумывание реализации. Подумайте, как «использовать» производственный код, будь то метод экземпляра или метод класса, следует ли передавать параметры из конструктора или из вызова метода, имя метода, возвращаемое значение и т. д. В это время он фактически занимается дизайном, и дизайн отражается в коде. На данный момент тест красный

2. Реализуйте код, чтобы дать тесту «зеленый свет»

3. Рефакторинг, затем повторите тест

4. В итоге все требования соблюдены, а именно:

   • Каждое понятие четко выражено

   • Ни один код не повторяется

   • Там нет дополнительных

   • Прошел тест

BDD (разработка, основанная на поведении):

Behavior Driven Development (BDD), которая направлена ​​на получение понимания ожидаемого поведения программного обеспечения посредством обсуждений с заинтересованными сторонами (сокращенно с клиентами), которыеОсновное внимание уделяется общению

Процесс BDD:

1. Определите конкретные, измеримые цели с точки зрения бизнеса

2. Найдите способ достижения тех функций, которые наиболее важны для бизнеса для поставленных целей

3. Затем опишите каждое конкретное действенное поведение, как историю. Метод его описания основан на некоторой общеупотребительной лексике, обладающей способностью точного выражения и последовательного значения. Например,expect, should, assert

4. Найдите правильный язык и метод для реализации поведения

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

4. Рабочий процесс внешнего тестирования Mocha/Karma+Travis.CI

Вышеупомянутое содержание от того, что такое модульное тестирование, к методологии модульного тестирования. Так как же использовать общие фреймворки для модульного тестирования? Что представляет собой инструментальная среда для модульного тестирования? Как бы выглядел практический пример модульного тестирования?

  Сначала краткое введение в Mocha, Karma и Travis.CI

**Mocha: **mocha — это многофункциональная среда для тестирования переднего плана. «Тестовая среда» — это инструмент для запуска тестов. С его помощью вы можете добавлять тесты в приложения JavaScript, чтобы убедиться в качестве кода. mocha может работать как в среде Node.js, так и в среде браузера. Чтобы узнать больше, перейдите наОфициальный сайтучиться. Его официальное введение:

Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub.

**Karma:** Инструмент управления процессом выполнения тестов JavaScript на основе Node.js (Test Runner). Инструмент можно использовать для тестирования всех основных веб-браузеров, его также можно интегрировать в инструменты непрерывной интеграции (CI) и использовать с другими редакторами кода. Одной из мощных функций этого инструмента тестирования является то, что он может отслеживать изменения файлов, выполнять их самостоятельно и отображать результаты тестирования через console.log. Мощная функция Karma заключается в том, что она может отслеживать преобразование набора файлов и немедленно начинать тестирование сохраненных файлов, не выходя из текстового редактора. Результаты тестирования обычно отображаются в командной строке, а не в редакторе кода. Это также делает Karma практически пригодным для использования с любым JS-редактором.

Travis.CI:Он предоставляет услуги непрерывной интеграции (сокращенно Continuous Integration, CI). Он привязан к проектам на Github, и пока есть новый код, он будет автоматически захвачен. Затем предоставьте среду выполнения, выполните тесты, завершите сборку и выполните развертывание на сервере.

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

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

Для Travis.CI мы рекомендовали площадкуНгуен Даа такжеЛяо ДаДва учителя говорят яснее, чем я могу написать здесь.

Библиотека утверждений

Я полагаю, что после введения базовой инструментальной среды коллеги, которые немного разбираются в тестировании, знают, что для модульного тестирования необходимо писать тестовые сценарии, поэтому в тестовых сценариях нужно использовать библиотеку утверждений. «Утверждения», личное понимание, это «использовать код для проверки правильности этого кода, проверять и выявлять ошибки этого кода».

Посмотрите на пример кода:

expect(add(1, 1)).to.be.equal(2);

Это код утверждения.

Так называемое «утверждение» предназначено для оценки того, согласуется ли фактический результат выполнения исходного кода с ожидаемым результатом, и если он несовместим, выдается ошибка. Утверждение выше означает, что результат вызова add(1, 1) должен быть равен 2. Все тестовые примеры (блоки) должны содержать одно или несколько утверждений. Это ключ к написанию тестовых случаев. Функция утверждения реализуется библиотекой утверждений, сама Mocha не имеет библиотеки утверждений, поэтому сначала необходимо ввести библиотеку утверждений.

Представляем пример кода библиотеки утверждений:

var expect = require('chai').expect;

Существует много видов библиотек утверждений, Mocha не ограничивает, какую из них использовать, он позволяет вам использовать любую библиотеку утверждений, которую вы хотите. Библиотека утверждений, введенная в приведенном выше коде, называется chai, и она указана для использования стиля ожидаемых утверждений. Ниже приведены распространенные библиотеки утверждений:

• assertЭто модуль утверждений в Node.js.
• should.js
• expect.js
• chai.js

Здесь мы в основном представляем часто используемые API в node assert.

• assert(value[, message])
• assert.ok(value[, message])
• assert.equal(actual, expect[, message])
• assert.notEqual(actual, expected[, message])
• assert.strictEqual(actual, expect[, message])
• assert.notStrictEqual(actial, expected[, message])
• assert.deepEqual(actual, expect[, message])
• assert.notDeepEqual(actual, expected[, message])
• assert.deepStrictEqual(actual, expect[, message])
• assert.notDeepStrictEqual(actual, expected[, message])
• assert.throws(block[, error][, message])
• assert.doesNotThrow(block[, error][, message])

assert(value[, message])

Утверждают, является ли значение value истинным, если проверка на равенство использует == вместо ===. message — это описание утверждения и необязательный параметр.

const assert = require('assert');
assert(true);

assert.ok(value[, message])

Используйте тот жеassert(value[, message]).

assert.equal(actual, expect[, message])

Ожидается, что фактическое и ожидаемое значения будут равны. Фактическое и ожидаемое, используемые равным для сравнения, являются данными базового типа (строка, число, логическое значение, ноль, неопределенный). В сравнениях используется == вместо ===.

it('assert.equal', () => {
  assert.equal(null, false, 'null compare with false');  // 报错
  assert.equal(null, true, 'null compare with true');  // 报错
  assert.equal(undefined, false, 'undefined compare with false'); // 报错
  assert.equal(undefined, true, 'undefined compare with true'); // 报错
  assert.equal('', false, '"" compare with false');  // 正常
})

notEqual(actual, expected[, message])

То же использованиеassert.equal(actual, expect[, message])Просто отрицайте (т.е. не равняйте) ожидаемый результат.

assert.strictEqual(actual, expect[, message])

То же использованиеassert.equal(actual, expect[, message])Но внутреннее сравнение использует === вместо ==.

assert.notStrictEqual(actial, expected[, message])

То же использованиеassert.strictEqual(actual, expect[, message])Просто отмените ожидаемый результат (т.е. не строго равный).

it('assert.strictEqual', () => {
  assert.strictEqual('', false); // 报错
})

assert.deepEqual(actual, expect[, message])

Метод deepEqual используется для сравнения двух объектов. Процесс сравнения заключается в том, чтобы сравнить, совпадают ли значения ключа и значения двух объектов, используя == вместо ===.

it('assert.deepEqual', () => {
  const a = { v: 'value' };
  const b = { v: 'value' };
  assert.deepEqual(a, b);
})

assert.notDeepEqual(actual, expected[, message])

То же использованиеassert.deepEqual(actual, expect[, message])Просто отмените ожидаемый результат (т. е. не строго глубокое равенство).

assert.deepStrictEqual(actual, expect[, message])

То же использованиеassert.deepEqual(actual, expect[, message])Но внутреннее сравнение использует === вместо ==.

assert.notDeepStrictEqual(actual, expected[, message])

То же использованиеassert.deepStrictEqual(actual, expect[, message])Просто отмените результат (т.е. не строго глубокое равенство).

assert.throws(block[, error][, message])

Утверждение ошибки и захват, утверждение указанного блока кода обязательно сообщит об ошибке или выдаст ошибку. Если код выполняется без ошибок, утверждение не выполняется и утверждение является ненормальным.

it('throws', () => {
  var fun = function() {
    xxx
  };
  assert.throws(fun, 'fun error');
})

assert.doesNotThrow(block[, error][, message])

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

it('throws', () => {
  var fun = function() {
    xxx
  };
  assert.doesNotThrow(fun, 'fun error');
})

После ознакомления с соответствующими инструментами расскажу о личном практическом опыте использования Mocha, Karma и Travis.CI.

Mocha

• установить мокко

  npm install mocha -g

Конечно, вы также можете установить его глобально, но только локально в проекте.

npm install mocha --save

• Создать тестовый файлtest.js

  var assert = require('assert')

  describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { assert.equal(-1, [1, 2, 3].indexOf(-1)) }) }) })

Этот файл и простой тестArrayодин изindexOf()метод. Библиотека утверждений, которую я здесь использую, предоставлена ​​Node.AssertAPI в модулях. Это утверждает, что -1 равно массиву[1, 2, 3]воплощать в жизньindexOf(-1)После возвращаемого значения, если тест пройден, об ошибке не будет сообщено, если есть ошибка, будет сообщено об ошибке.

Ниже мы используем глобально установленныйmochaзапустить этот файлmocha test.js.
Ниже приведен возвращаемый результат

Пример базового теста

const assert = require('assert');

describe('测试套件描述', function() {
  it('测试用例描述: 1 + 2 = 3', function() {
    // 测试代码
    const result = 1 + 2;
    // 测试断言
    assert.equal(result, 3);
  });
});

Тестовые случаи Mocha в основном включают следующие части:

1. описать определяет набор тестов (набор тестов)
2. он определяет тестовые случаи (тестовый пример)
3. тестовый код
4. Раздел утверждения

Примечание. В каждом тестовом файле может быть несколько наборов тестов и тестовых наборов. mocha может работать не только в среде узла, но и в среде браузера, запуск в узле также может выполняться черезnpm i mocha -gТакже можно установить mocha глобально, а затем запустить тестовые примеры из командной строки.

Вот небольшое подробное введение в метод написания тестового сценария

Роль Mocha заключается в запуске тестовых сценариев.Во-первых, вы должны научиться писать тестовые сценарии. Так называемый «тестовый сценарий» — это сценарий, используемый для проверки исходного кода. Ниже приведен код дополнительного модуля add.js.

// add.js
function add(x, y) {
  return x + y;
}

module.exports = add;

Чтобы проверить правильность этого дополнительного модуля, нам нужно написать тестовый скрипт. Как правило, тестовый скрипт имеет то же имя, что и исходный тестируемый скрипт, но с суффиксом .test.js (для тестов) или .spec.js (для спецификаций). Например, имя тестового сценария для add.js — add.test.js.

// add.test.js
var add = require('./add.js');
var expect = require('chai').expect;

describe('加法函数的测试', function() {
  it('1 加 1 应该等于 2', function() {
    expect(add(1, 1)).to.be.equal(2);
  });
});

Приведенный выше код является тестовым скриптом, который можно выполнить независимо. Тестовый сценарий должен содержать один или несколько блоков описания, а каждый блок описания должен содержать один или несколько блоков it.

Блок описания называется «набором тестов» и представляет собой группу связанных тестов. Это функция, первый аргумент которой — название набора тестов («тесты для функции сложения»), а второй аргумент — функция, которая фактически выполняется.

Блок it называется «тестовым набором», который представляет собой один тест и является наименьшей единицей тестирования. Это тоже функция, первый параметр — название теста («1 плюс 1 должно равняться 2»), а второй параметр — функция, которая фактически выполняется.

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

// 相等或不相等
expect(4 + 5).to.be.equal(9);
expect(4 + 5).to.be.not.equal(10);
expect(foo).to.be.deep.equal({ bar: 'baz' });

// 布尔值为true
expect('everthing').to.be.ok;
expect(false).to.not.be.ok;

// typeof
expect('test').to.be.a('string');
expect({ foo: 'bar' }).to.be.an('object');
expect(foo).to.be.an.instanceof(Foo);

// include
expect([1, 2, 3]).to.include(2);
expect('foobar').to.contain('foo');
expect({ foo: 'bar', hello: 'universe' }).to.include.keys('foo');

// empty
expect([]).to.be.empty;
expect('').to.be.empty;
expect({}).to.be.empty;

// match
expect('foobar').to.match(/^foo/);

По сути, ожидание утверждений записывается одинаково. Голова — это метод ожидания, а хвост — метод утверждения, например, «равно», «а/ан», «ок», «совпадение» и т. д. Используйте to или to.be для связи между ними. Если ожидание утверждения терпит неудачу, выдается ошибка. На самом деле тестовый пример проходит до тех пор, пока не будет выдано никаких ошибок.

it('1 加 1 应该等于 2', function() {});

В приведенном выше тестовом примере кода внутри нет, потому что ошибка не выдается, поэтому она будет пропущена.

Karma

На основе некоторого общего модуля проверки кармы

Установка модуля

# 基础测试库
npm install karma-cli -g
npm install karma mocha karma-mocha --save-dev

# 断言库
npm install should --save-dev
npm install karma-chai --save-dev

# 浏览器相关
npm install karma-firefox-launcher --save-dev
npm install karma-chrome-launcher --save-dev

настроить

Конфигурация здесь в основном касаетсяkarma.conf.jsсоответствующая конфигурация. Если вы хотите использовать карму и мокко, лучше пройтиnpm install karma-cli -gУстановить глобальноkarma-cli.Конкретные инструкции по настройке конфигурации

Два поля на заметку:

• singleRun: если значение равно true, браузер автоматически завершит работу и закроет окно браузера после того, как браузер завершит выполнение теста. Значение singleRun может быть назначено динамически в соответствии с рабочей средой и может быть добавлено к команде запуска.NODE_ENVПеременная.

• браузеры: конфигурация браузера (можно настроить несколько браузеров); если браузер не может быть запущен, необходимо выполнить соответствующую настройку браузера. При настройке самозапускающегося браузера, если браузер не запускается, вам может потребоваться установить для него значение--no-sandboxмодель.

  { "browsers": ["Chrome", "ChromeHeadless", "ChromeHeadlessNoSandbox"], "customLaunchers": { "ChromeHeadlessNoSandbox": { "base": "ChromeHeadless", "flags": ["--no-sandbox"] } } }

или

{
  "browsers": ["Chrome_travis_ci"],
  "customLaunchers": {
    "Chrome_travis_ci": {
      "base": "Chrome",
      "flags": ["--no-sandbox"]
    }
  }
}

Шаги для проекта GitHub для доступа к Travis.ci для интегрированного автоматизированного тестирования

• Создание и завершение проекта можно проверить в GitHub. Вот полная необходимость выполнения основных функций проекта и тестового кода.

• Настройте travis-ci для распознавания прочитанного файла конфигурации, чтобы при подключении travis-ci мог знать некоторые конфигурации во время тестирования.

• github и travis-ci — это сайт, другими словами, если эти две вещи можно связать. Пользователям необходимо войти в систему travis-ci и авторизовать доступ к вашему проекту github, а также выполнить соответствующие настройки проекта.

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

Создание проекта, доработка функционала проекта и тестового кода.

• Требования к проекту: реализация метода суммирования
• тест проходятmochaпроверить завершенный метод суммирования.

Ниже приведена структура проекта.После создания проекта перейдитеnpm i mocha -DУстановитьmochaмодуль. затем запустить локальноnpm testПосмотрим, сможешь ли ты пройти испытание. Если он может пройти тест, это означает, что мы можем перейти к следующему шагу.

Создайте тестовый профиль travis-ci

Создайтеtravis-ciконфигурационный файл.travis.yml, содержание документа. Более подробную информацию о конфигурационных файлах можно найти на официальном сайте travis.

language: node_js
node_js:
  - "node"
  - "8.9.4"

На этом процесс разработки проекта и написания тестового кода в основном завершен, и следующим шагом будет доступ кtravis-ciпроверено.

Доступ к travis-ci

Войдите на официальный сайт travis-ci через GitHubwww.travis-ci.org/

Найдите проект, который вы только что создали на GitHub, который необходимо протестировать, и запустите тест.

Наблюдайте за процессом тестирования и вовремя находите проблемы.

Проверьте, прошел ли тест статус теста, и если он не пройден, устраните проблему и повторно измените его; если он пройден, вы можете добавить отметку о прохождении теста в документ проекта.

Суммировать

В начале года я пошел на собеседование в компанию.Это была начинающая компания.Руководителем был г-н Линь Шидин, бывший главный архитектор Baidu.Компания называлась Aiyun School. Вопрос, который интервьюер задал мне в тот день, произвел на меня наибольшее впечатление: какой фреймворк и рабочий процесс вы использовали для модульного тестирования, когда занимались интерфейсом? Честно говоря, в то время я был настолько сбит с толку, что даже не знал, что такое юнит-тестирование во фронтенде? Что тестировать? Какой инструмент вы использовали? Какое-то время я говорил, что никогда не использовал его раньше и не проводил интерфейсное тестирование. На тот момент интервьюер был явно немного разочарован, но конечным результатом было то, что компания наняла меня.Когда я говорил причину этого опыта, я на самом деле хотел донести смысл: текущая фронтенд-разработка больше не является вырезка, реализация спецэффектов и визуальное исполнение. Текущий фронтенд-разработчик — это скорее должность, которая теоретически (фактически, фактически) ближе всего к пользователю во всей команде разработки продукта проекта, и не должна ограничиваться только реализацией чисто традиционного фронтенда. функции, но также должны быть основаны на понимании клиентов.Исходя из требований, должна быть скоординирована хорошая связь между интерфейсом и сервером, а функции интерфейса должны быть точными. Согласно моему собственному опыту собеседования при приеме на работу, содержание интерфейсного модульного тестирования, обсуждаемое здесь сегодня, может не понадобиться в некоторых проектах компании, но, поскольку это одна из самых быстрорастущих областей ИТ, фронтенд-инженеры осваивают интерфейсный модуль. В будущем тестирование может требовать только все более и более жестких требований, а не оставаться в категории необязательных знаний, потому что оно тесно связано с тенденцией развития фронтенд-разработки.

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