Зрелость тестирования

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

Начальная стадия

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

Повторяемая стадия

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

Установленная стадия

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

Уровень 1.

Пишутся тесты для простейших классов и методов. С одним входом и выходом.

Уровень 2.

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

Уровень 3.

Тестовые данные разбиваются на фикстуры и каждый тест запускается в изолированной среде.

Уровень 4.

Взаимодействие с внешним миром тестируется при помощи стабов и моков.

Уровень 5.

Тестируется пользовательский интерфейс?

Пишутся интеграционные тесты?

Управляемая стадия

Видел одним глазом. Запрет на внесение нового функционала без покрытия тестами и документирования внесенного кода.

Оптимизированная стадия

1. Magic

2. ???

3. Profit

Темный рыцарь: возрождение легенды

Сходили вчера на “Темного рыцаря”. Фильм был долгий, и, вцелом, понравился, на часы я не посмотрел ни разу - одна из моих главных метрик.

А дальше будут спойлеры.

CodeFest Mini

За день до поездки собрались поиграть в Империал 2030. Изначально планировалось лечь не позднее часа, но прокопались и начали только в полночь. Долго разбирались с правилами и закончили игру в пятом часу. А выезд был запланирован на половину пятого.

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

Монах наоборот

Один монах прослыл странным методом написания кода. Встретившись с проблемой, он сначала писал много автоматических тестов, чтобы убедиться, что еще не написанный код верен. И тесты, естественно, проваливались. Только после написания всех тестов монах начинал работать непосредственно над кодом, усердно продвигаясь вперед, пока все тесты не пройдут.

Его браться высмеивали этот процесс, поскольку монах писал вполовину меньше кода, чем его братья, еще и с большим опозданием. Братья звали его Луохоу — Монах наоборот.

Джава мастер Банзен, услышав об этом, заявил: я разберусь.

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

На вершине прыгательной скалы старший из монахов взглянул вниз и отскочил. Монах закричал: Мастер, кто-то разобрал дамбу; вся вода ушла из пруда; внизу нас ждут только водоросли и острые камни!

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

The Codeless Code 

QTception

Понадобилось написать десктопный клиент и рассматривали различные варианты написания оного. Хотелось кроссплатформенности и, поэтому, рассматривалась Swing и QT. В качестве варианта QT рассматривался запуск браузера который будет показывать нашу веб-аппликуху. Главным аргументом был высокий скилл в вебе, главным контр-аргументом - полная неясность как из сервера достучаться до клиента пробив все слои абстракции.

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

А уровней у нас было много: между сервером и браузером находились Vaadin и GWT. И если с первыми тремя элементами было все относительно просто и понятно: по классу на виджет и обертку, то как пронзить песочницу в обе стороны было неизвестно даже возможно ли такое впринципе.

Быстро выяснилось, что можно расширить объектную модель движка плюсовыми классами и вызывать методы внутри JavaScript из приложения. В обратную сторону можно добавить javascript обработчики событий. Обработчики успешно выводили алерты, но вызвать нативный метод из браузера после сигнала с сервера никак не удавалось.

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

К концу третьего дня, когда отчаяние достигло максимума, созерцая обфусцированный gwt-шный javascript, заметил отсутствие ";".