Sergei Calabonga

В концепции "Плохо", "Хорошо" и "Правильно" Плохо если… Я не могу писать unit-тесты. Я не могу написать тест, потому что метод является статичным, или не возвращает результат, или приватный (static/void/private). Мои тесты выполняются слишком долго. Мои тесты не проходят если база данных, или web-сервис, или другая система (database/web-service/system) выключены или не доступны. Хорошо если… Unit-тесты выполняются быстро (fast). Unit-тесты изолированы от каких-либо внешних зависимостей (isolated). Unit-тесты легко повторяются (repeatable). Unit-тесты должны быть сами себя контролировать (self-checking). Unit-тесты должны быть «уместными», то есть не должны требовать много времени на поддержку работоспособности (timely). Правильно Если писать тесты: Ваш код будет покрыт «проверочным кодом». Вы будете знать как писать код «правильно», то есть код будет менее связанным. Вы упростите интеграцию нового функционала. Вы защищены от регрессии при написания кода. У вас появится дополнительная защита при публикации (CI/DC). Сокращается время на функциональное тестирование. Ваша совесть будет чиста :) Если писать правильные тесты: Именование тестов: 1) имя тестируемого метода; 2) сценарий в котором выполняется тестирование; 3) ожидаемое поведение при вызове сценария Arrange, Act, Assert: Меньше путаницы Минимализм при написание тестов – признак мастерства: 1) тесты более устойчивы к изменениям; 2) ближе к тестированию поведения чем к реализации. Именование переменных в тестах: упрощение понимания при чтении.

Есть готовый API для сайта "Музей Юмора". Есть Single Page Application фреймворк, который называется Aurelia.io. В этой подборке видео роликов создадим frontend для существующего API.