Пытаюсь разбираться с азами тестирования и включать их в рабочий процесс.

Обнаружил, что всё-таки есть и обсуждались штуки, от которой я начал думать от большой лени.

Лень эта заключается в том, что писать дублирующиеся штуки, например, планы/спецификации для постановки задачи и документацию к коду после её исполнения мне дюже лениво. Так же как и думать "а правильно ли оно работает, или всё надо переделать?".

Рецепт частично известен - требования в виде Use Cases (и всех их производных и потомков-мутантов) отлично преобразуются в документацию. Agile-метОды позволяют максимально сократить и объем письменных требований, полагаясь на живую коммуникацию, код и всё такое. Только если посмотреть в базовые требования к этим подходам, везде там требуется вовлечённость эксперта из предметной области, заказчика/стейкхолдера или каких-нибудь их ипостасей вроде продакт-оунеров, в идеале - фул-тайм. А если эксперт ленив, злобен, любит пить чай больше, чем объяснять свои требования, и, кроме того, ничего не понимает в этом вашем программировании? Ну, положим, сформулировать требования в виде коротенькой истории на кусочке туалетной бумаги с перфорацией ещё можно (с треском). Но вот заниматься докмуентированием и мучительной оценкой корректности реализации -- ну право слово, я так занят, у меня пятки чешутся и нос не прочищен.

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

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

Есть решения, однако, и для такого случая: самый известный из них это, наверное, BDD - Behavior-Driven Development гражданина по имени Dan North. И даже инструменты, позволяющие человечьим почти языком реализовывать это всё тоже есть (и много). Pyccuracy и MoreliaViridis, например, для Python.

В детали пока вдаваться не будем. Важно, что это попытка дополнить тесты, проверяющие техническую работоспособность/корректность кода, acceptance/приёмочными тестами (поэтому концепт еще называется ATDD - ну да, Acceptance Tests-Driven Development), фиксирующими ожидания пользователей и, в идеале, автоматизирующими проверку приложения на соответствие этим ожданиям - идеал ленивца!

Инструменты для этого всего любопытны и весьма остроумны, отдельного рассказа заслуживает то, как там обходятся проблемы тестирования соответствия бизнес-правилам/считальным алгоритмам. Любопытна и попытка (идея, в общем, лежит на поверхности) совместить это всё с Use Cases, которая предпринята гражданином Michael Dowling в его Spectacular, который я надеюсь найти время посмотреть поближе.

Вместе с тем, некоторые особенности нашего конкретно проекта, позволяют надеяться (глубоко втянув в себя добрую порцию оптимизма из специально запасённой ёмкости), что мы обойдемся на первых порах для этого всего без особых инструментов, используя джентельменский набор питониста: доктесты + Sphinx.

Предпосылки:

  1. мы делаем что-то похожее издалека и зажмурившись на RESTful приложение, так что оно, чёрт побери stateless;
  2. архитектура приложения проста и деление на слои (с берега) видится прозрачным
  3. благодаря пункту 1, интерфейс прост, инкапсуляция прилична

Отсюда, как мне кажется, следует, что customer-level (acceptance) тесты должны быть не особо замысловаты в реализации и, скорее всего, доктестов будет для них достаточно. Хотя, возможно, придется и что-то более замысловатое использовать: во-первых, для проверок, требующих работы непосредственно с самим API (что-то в этом духе?), а во-вторых, надо будет крепко подумать над принципом тестирования бизнес-правил, которых у нас не мало.

Ну, как-то так. Если осилю поправки-обновления-дополнения, то продолжим.