ТЕСТИРОВАНИЕ JAVASCRIPT КОДА. ИНСТРУМЕНТЫ, ПРАКТИКИ, ТРЕНДЫ

Евгений Сафронов

Senior developer

25.03.2017

evgeniy.safronov@outlook.com

skype: lambda.omega1

Тестирование, как инженерная практика, появилось раньше чем программирование

Здесь тоже есть своя философия

Здесь тоже есть своя философия

ЭДСГЕР ДЕЙКСТРА

«Тестирование программ можно использовать для того, чтобы показать наличие ошибок и никогда — для того чтобы показать их отсутствие!»

Почему тестировать программы так важно?

Как правило, самые дорогостоящие ошибки вызваны изменением одного символа.

Ivan

Ivanov

i.ivanov

First name:

Last name:

Login:

0..255

0..255

0..20

a-z, A-Z

a-z, A-Z

a-z, A-Z, 0-9, . - % $

Количество возможных ситуаций > 52255 + 52

255 + 3620

25.18% Структурные

22.14% Данных

16.19% Реализация функциональности

9.88% Конструирования

8.98% Интеграции

8.12% Функциональных требований

2.76% Определение и выполнение тестов1.14% Архитектура ПО

4.71% Другие

9

Типы ошибок в проектах

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2K 8K 32K 128K 512K

Конструирование Проектирование Выработка требований

Статистика ошибок на стадиях разработки

Правило Парето работает и в тестировании ПО: 80% дефектов локализированы лишь в 20% вашего кода.

Т.е. если тестами покрыто 50% кода нельзя утверждать, что удалось предотвратить 50% возможных дефектов

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

Классификация

Тестирование может выполнятся разработчиками, тестировщиками, заказчиками и т.д.

Тестирование черного и белого ящиков

Классификация по цели:

• Регрессионное

• Нагрузочное

• UX - тестирование

• Тестирование защищенности и надежности

• Обнаружение дефектов

Какие тесты пишут разработчики?

• Модульные тесты

• Функциональные тесты

• Интеграционные

• End-to-end

Модульное тестирование

• Быстрота (Fast) - Если тесты выполняются медленно, вам не захочется их

запускать.

• Независимость (Independent) - Один тест не должен создавать условия

для выполнения следующего теста. Все тесты должны выполняться

независимо и в любом порядке.

• Повторяемость (Repeatable) - Тесты должны давать повторяемые

результаты в любом окружении.

• Очевидность (Self-Validating) - Результатом выполнения теста должен быть

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

своевременно.

• Своевременность (Timely)

F.I.R.S.T.

TDD и BDD

TDD процесс

suite('#factorial()', function (){test('equals 1 for sets of zero length', function (){

assert.equal(1, factorial(0));});test('equals 1 for sets of length one', function (){

assert.equal(1, factorial(1));});test('equals 2 for sets of length two', function (){

assert.equal(2, factorial(2));});test('equals 6 for sets of length three', function (){

assert.equal(6, factorial(3));});

});

TDD стиль написания тестов

describe('#factorial()', function (){it('should return 1 when given 0', function (){

factorial(0).should.equal(1);});it('should return 1 when given 1', function (){

factorial(1).should.equal(1);});it('should return 2 when given 2', function (){

factorial(2).should.equal(2);});it('should return 6 when given 3', function (){

factorial(3).should.equal(6);});

});

BDD стиль написания тестов

Особенности модульного тестирования

• дает возможность писать много тестов, причем

достаточно быстро

• необходимость изолировать участки кода

(mocks, stubs, spies)

• требует понимания кода, который нужно

тестировать (тестирование белого ящика)

Существует много инструментов которые позволяют выполнять модульное тестирование JS кода

QUnit

Это библиотека от разработчиков jQuery, позволяющая писать unit-

тесты в TDD стиле и имеющая свой механизм assert-ов.

QUnit.test( "hello test", function( assert ) {assert.ok( 1 == "1", "Passed!" );

});

Mocha

Фреймворк для тестирования, позволяющий писать тесты в TDD и

BDD формате

describe('User', function() {describe('#save()', function() {

it('should save without error', function(done) { var user = new User('Luna');user.save(function(err) {

if (err) done(err);else done();

});});

});});

Chai

Очень популярная библиотека assert’ов

assert.typeOf(foo, 'string');assert.equal(foo, 'bar');assert.lengthOf(foo, 3;assert.property(tea, 'flavors');assert.lengthOf(tea.flavors, 3);

expect(foo).to.be.a('string');expect(foo).to.equal('bar');expect(foo).to.have.lengthOf(3);expect(tea).to.have.property('flavors').with.lengthOf(3);

foo.should.be.a('string');foo.should.equal('bar');foo.should.have.lengthOf(3);tea.should.have.property('flavors').with.lengthOf(3);

Sinon

Инструмент для создания Mocks, stubs, spies

function () {var myAPI = { method: function () {} };var spy = sinon.spy();var mock = sinon.mock(myAPI); mock.expects("method").once().throws(); PubSub.subscribe("message", myAPI.method); PubSub.subscribe("message", spy); PubSub.publishSync("message", undefined); mock.verify();assert(spy.calledOnce);

}

Jasmine

Популярный в экосистеме Angular’a, BDD фреймворк

describe("A suite is just a function",function() {

var a;it("and so is a spec", function() {

a = true;expect(a).toBe(true);

}); });

• Тестирование - это долго и дорого. Разумеется тестирование

увеличивает время на разработку, но уменьшает время,

затраченное на рефакторинг и багфикс.

• Писать тесты – это скучно и нудно. Написание тестов позволяет

еще раз взглянуть на вашу архитектуру и принять правильные

решения

• 100%-ое покрытия. Тестов необходимо ровно столько, сколько

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

• Тестирование не позволяет писать код без багов.

Мифы

• Заказчик не поддерживает и не принимает идею unit-тестов в

проекте

• Тесты пишутся только для наличия и метрик, а «чистоте» тестов

не уделяется должное внимание

• Вы пишите тесты намного позже создания кода. Тесты не

актуализируются

Ситуации бывают разные

?

Спасибо!

F O O T E R H E R E 38