Автоматическое тестирование via C# и JS

Зачем писать автоматические тесты?

Удостовериться, что код работает
А также, что он продолжает

Первый тест

C# NUnit

JS Mocha

Результаты теста

Результаты теста

Результаты теста

Тесты как спецификация

Что тестируем (SUT System Under Tests)
Что ожидаем (expectation)
(Опционально) При

Тесты как спецификация

Что тестируем (SUT System Under Tests)
Что ожидаем (expectation)
(Опционально) При

Тесты как спецификация

Calculator Specification
Add
Should add given number to accumulated value
Should fail

Тесты как спецификация

Calculator Specification
Add
Should add given number to accumulated value
Should fail

C# реализация

JS реализация

Результаты тестов

Результаты тестов

Структура теста. AAA

Подготовка (Arrange)
Действие (Act)
Проверка (Assert)

Возможные ошибки

Возможные ошибки

Возможные ошибки

Тест работает только на машине разработчика
System.IO.DirectoryNotFoundException : Не удалось найти

Возможные ошибки

Возможные ошибки

Тест ничего не проверяет. Перманентно зеленый. Даже если изменится значимое

Возможные ошибки

Тест проверяет слишком много

Expected: True
But was: False

???

Тест проверяет слишком много. Нет

Устраняем дублирование

Параметризованные тесты (Data Driven Tests)
Выделение общей фазы Arrange, а также

Data Driven Tests C#

Data Driven Tests C#

Data Driven Tests C#

Data Driven Tests C#

Data Driven Tests JS

Data Driven Tests JS

Настройка окружения

Выполнить что либо перед запуском всех тестов SUT
Выполнить что либо

Настройка окружения C#

Настройка окружения C#

OneTimeSetUp
SetUp
test1
TearDown
SetUp
test2
TearDown
OneTimeTearDown

Настройка окружения JS

Настройка окружения JS

before
beforeEach
test1
afterEach
beforeEach
test2
afterEach
after

Делаем тесты читабельнее

C# FluentAssertions http://fluentassertions.com
(2 + 2).Should().Be(4);
array.Should().HaveCount(3);
complexObject.ShouldBeEquivalentTo(anotherObject);
JS Chai http://chaijs.com
(2+2).should.be.equal(2);
[1,2,3].should.to.have.lengthOf(3)
complexObject.should.be.to.deep.equal(anotherObject);

Test Driven Development

Не всегда после написания кода его легко протестировать.
Не всегда

Test Driven Development

Не всегда после написания кода его легко протестировать.
Не всегда

Test Driven Development

Не всегда после написания кода его легко протестировать.
Не всегда

Test Driven Development

Плюсы:
Код делает только то, что нужно и делает это

Test Driven Development

Наилучшие Use Cases:
Сложная задача
Исправление бага (сначала нужно показать, что

Практика. Игра жизнь

Правила:
Дано клеточное поле размера N на M с заданной

Итоги

Тесты - хорошо
Доверие к работоспособности
Легкость изменения (быстрая обратная связь о