Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С

Основные этапы разработки в 1С

• Проектирование
• Кодирование
• Тестирование
• Отладка

Проектирование в 1С очень часто пропускается. Если оно и происходит, то только в достаточно небольшом объеме, и то только у серьезных команд. Чаще всего, оно происходит в уме (где-то,  как-то).

Очень многие, особенно небольшие группы разработки, новички – сразу приступают к следующему этапу – этапу кодирования.

Дальше идет следующий этап – это этап тестирования. То есть, тестирование – это мы проверяем требования заказчика (требования, которые мы должны выполнить).

Дальше идет поиск ошибок, отладка.

Как правило, я сам проходил эти этапы. Тестированием занимаются очень немногие. Еще меньше число тех, кто вообще представляет, что же такое «тестирование».  Для большинства разработчиков цикл разработки представляет собой совокупность только двух этапов —  процесса кодирования и отладки. Причем отладка занимает очень много времени.

Есть такой закон, который я, например, прочитал у Макконелла – Главный закон качества ПО:

Повышение качества программного обеспечения снижает затраты на разработку и сопровождение системы.

Что это означает? Это означает, что чем лучше у нас написана система, чем лучше она спроектирована, чем лучше обоснованы связи, тем легче мы сможем ее дорабатывать, исправлять и т.д.

Пример правильности этого закона: Отладка и исправление неверного кода занимает около 50 % времени. То есть – 50 % времени всей разработки мы тратим на поиск ошибок.

Есть еще одно следствие, что чем раньше найдена ошибка, тем легче ее исправить. Это правило действует всегда — если ошибка допущена на этапе проектирования, то на этапе непосредственно внедрения очень дорого будет ее исправить.

Это касается как крупных проектов, так и мелких. Методик, чтобы снизить свои затраты и не допустить ошибок, очень много – главный принцип, которого нужно придерживаться в разработке, используя разные методики, — это просто их использовать (использовать комбинации методик, использовать одну методику, а не просто писать свой код не думая над ним, не исправляя его).

Методики разработки

• Защитное программирование
• Обзоры кода
• Проектирование
• Тестирование
• Экстремальное программирование

Я лично пользуюсь всеми перечисленными методиками.

1. Защитное программирование –  это методика, когда мы ведем разработку и само написание кода помогает нам не допускать ошибок. То есть, в этом случае мы что делаем? Мы проверяем данные.
   Элементарный пример – у нас есть какая-то функция, которая принимает входные параметры определенного типа, определенных значений. Мы можем в функции сделать предположение  (так называемый инвариант или утверждение) и проверить эти предположения. То есть, мы не пишем, как 1С привыкла: параметр и в комментариях пишем, что тип такой-то, значения такие-то, варианты  и так далее…  Мы можем прямо написать утверждение – вот этот параметр должен быть такого типа. Если это утверждение не выполняется, программа просто выдает исключение и останавливает свою работу, потому что это является ошибкой разработки.
2. Следующая методика – это «Обзоры кода». То есть, мы можем читать чужой код. То есть, один кто-то написал код, мы можем попросить соседнего разработчика, руководителя посмотреть и проанализировать ошибки, которые были допущены в этом коде. Это методика очень эффективна.
   Я люблю читать чужой код, люблю свой код пересматривать. Таким образом находится достаточное число ошибок.
3. Следующая методика — проектирование. Чем лучше мы построим программу, чем лучше продумаем связи, чем лучше продумаем архитектуру, интерфейсы взаимосвязей, тем лучше наша система будет работать, тем удобнее нам ее будет исправлять.
4. Методика, которая известна лучше всех предыдущих – это тестирование. Фактически, каждый разработчик выполняет эту функцию, применяет методику тестирования. Но очень многие проверяют в уме. То есть этот код должен получить такие-то результаты… Мы проверяем какой-то один вариант, проверяем два варианта, проверяем три варианта…  А на самом деле в сложных системах вариантов очень много и их нужно проверять достаточно большое количество. И когда вариантов очень много для проверки, фактически получается, что они не проверяются все. У меня есть пример, есть система, идет цикл разработки, система отдается на проверку пользователю. У пользователя стоит тестирование – проверить 40 разных пунктов – релиз выпускается, например, раз в два месяца (или в месяц). Пользователь должен перед выпуском каждого релиза проверить 40 пунктов – это тяжело и он никогда практически не будет этого делать. Он будет помнить, что он это проверял в прошлый раз – и сегодня он этого делать не будет, потому что тогда на это придется потратить весь день. Как правило, отдельный тестировщик на проекте есть очень редко, обычно человек должен выполнить функцию тестировщика и выполнить свою основную функцию. В итоге функции тестировщика, как правило, пропускаются и тестирование не выполняется в полном объеме.
   Дальше я еще потом на тестировании остановлюсь…
5. Следующая – очень эффективная методика – это методика экстремального программирования. Это методика свежая, буквально начала-середины 90-х годов. На западе очень сильно распространена, очень много информации по ней. У нас применяется не так много. Иногда эту методику называют «гибкие методики разработки», иногда – экстремальное программирование.

Экстремальное программирование

У него есть несколько принципов:

• Единая команда
• Совместное владение кодом системы
• Обзоры кода и парное программирование
• Разработка через  тестирование (TDD)
• Функциональное тестирование
• Рефакторинг
• Простота
• Короткие циклы
• Непрерывная интеграция
• Улучшение дизайна, постоянное планирование

Расскажем о них поподробнее:

1. Первый принцип – это единая команда. Единая команда – это означает, то команда работает вместе. Каждый член команды осведомлен о целях проекта, о задачах, которые необходимо выполнить, как идет проект, на какой стадии он находится.
2. Есть еще такое понятие в экстремальном программировании  – я его даже не стал тут выделять, потому что это достаточно сложно для понимания – есть такое понятие – «метафора». То есть, у проекта, который находится в экстремальном программировании, должна быть единая метафора, единое простое представление, что делает система. Эта метафора может не относиться к какой-нибудь конкретной задаче, ее можно именно представить в уме – команда просто должна представлять себе, что это такое – небольшим набором слов (одна-две фразы). Но эта метафора должна быть.
3. Из единой команды есть следствие, что код, на котором пишется система – общий код не должен являться чьей-то собственностью. Код должен быть совместным. То есть – любой разработчик может исправить любое место кода. Это очень важный принцип и очень часто он нарушается. То есть – у нас пример – есть какой-то разработчик, который обладает большими знаниями, большими способностями, знает какую-то конкретную методику или знает предметную область, которую должен решить и он не пускает никого в свой код. Фактически для проекта это плохо.
   Этот разработчик владеет полностью своим кодом и проект полностью в этом месте может заморозиться. Он зависит только от этого разработчика. Для проекта это очень  вредно.
   Совместное владение кодом влечет за собой возможность гибко менять проект, возможность единого владения всеми членами команды знаниями о коде. В результате мы не зависим от конкретных людей (человек заболел, ушел, уволился) – у нас система проекта остается в работе и вся команда дальше работает вместе.
4. Есть еще соответственно методика — парное программирование или обзоры кода. По парному программированию, это – фактически работают два пользователя, два разработчика. Один разработчик пишет непосредственно код, проектирует, второй сидит рядом и выдает ему комментарии, что ты здесь сделал неправильно, ты здесь сделал ошибку и т.д. Строго говоря: один пишет – один контролирует.
   Это единственная методика, которую я не применял, то есть у меня к ней подозрения – не могу ее рекомендовать, потому что не проверял.
   Обзоры кода, как я уже сказал – я применял – то есть, это очень полезная методика.
5. Дальше – следующая методика, которая используется в экстремальном программировании – это разработка через тестирование (TDD). Смысл этой методики я раскрою дальше, расскажу пока что очень кратко.
   Сначала пишутся тесты. Потом пишется код под эти тесты. После того, как тесты проходят – код считается завершенным.
   Цикл:  тест – код – тестирование.
   Код никогда не пишется до тестов.
6. Дальше – есть функциональное тестирование, иногда называется «Приемочные тесты». Это то тестирование, которое выполняет заказчик.
   Обязательно, как я уже говорил – единая команда, заказчик всегда участвует в команде. Он принимает участие во всех этапах проекта. Готовит сам тесты. То есть – заказчик обязательно должен участвовать – это тоже одно из требований экстремального программирования.
7. Очень важный фактор экстремального программирования – это рефакторинг.
   Рефакторинг – это изменение кода (важное условие – изменение работающего кода).
   То есть, не добавление какого-либо функционала – только исправление работающего кода для того, чтобы увеличить его качество, упростить связи, интерфейсы и так далее.
8. Также очень важный параметр экстремального программирования – это простота. Проект стремится быть максимально простым по дизайну, по реализации. Не придумывается никаких лишних дополнений/допущений. Проект работает «на сегодня». Он не работает на будущее – через 10 лет, через 5 лет. Он, как правило, работает на сегодня. То есть – у нас есть требования, мы, в общем-то, продумываем эти требования, думаем о масштабировании, об увеличении, но стараемся писать, стараемся выполнять проект только для текущих задач.
9. Следующее понятие – это короткие циклы. То есть, итерации проекта несут очень маленький характер. Если один разработчик – 5-10 минут, написал тест, код, проверил – идем дальше.
   В результате коротких циклов у нас есть уверенность в том, что система работает и все тесты проходит. Но это – опять же, все основано на тестах.
10. Есть еще такое понятие – непрерывная интеграция. Для  1С  это, в общем-то, не так часто используется, но – тем, кто работает в коллективной разработке, с хранилищем, это должно быть известно,  —  то есть, изменения в основное хранилище должны вноситься очень часто.
    Разработчик добавил какой-то функционал в свой небольшой участок, протестировал его и обязательно занес  в основной код.
    Не через месяц, не через неделю – а часто, раз в день (так называемые «ночные сборки»). То есть, в течение дня выполняется работа. Ночью происходит «ночная сборка». Это можно автоматическими средствами выполнять. Выполняются тесты – например, ночные тесты — полностью все тесты. Если система полностью прошла все тесты – значит, наутро мы признаем, что функционал у нас принимается – делаем новую сборку системы.
11. Еще одно важное требование экстремального программирования – это улучшение дизайна.
    Всегда каждый разработчик думает о дизайне системы. Думает, как улучшить систему, как устранить дублирование, какие части кода не нужны в системе. Постоянно планирует. Заказчик в этом тоже непосредственно участвует, как я уже говорил.

Вернемся к тестированию. Будем говорить только о тестировании.

Виды тестирования

• Модульное тестирование (юнит-тестирование)
• Функциональное тестирование
• Тестирование методом черного ящика и методом белого ящика
• Нагрузочное тестирование
• Тестирование разработчиком и специальными тестерами
• Самый проблемный вид тестирования – тестирование пользовательского интерфейса

Теперь об этих видах тестирования подробнее:

1. Самое основное, про которое я буду в дальнейшем рассказывать – это юнит-тестирование или так называемое модульное тестирование. То есть, это тестирование частей системы, компонентов, модулей. Это самое простое, что может делать разработчик – любой причем разработчик 1С – как один человек, так и команда. Это самое простое – здесь нет никаких дополнительных проблем. Все зависит от разработчика и от той системы тестирования, которую он использует.
2. Дальше – есть такой термин – функциональное тестирование или приемочные тесты или – там несколько названий – это тесты всей системы в целом.
   То есть – смотря что мы разрабатываем – если мы пишем какой-то отчет, это может быть формирование отчета – какие данные из него получаем. Если это проект в целом – то это проверка всего пользовательского интерфейса.
3. Есть тестирование методом белого и черного ящика.
   Методом черного ящика – это соответственно, мы ничего не знаем о системе, как она функционирует. Мы знаем только то, что подается на вход системы и то, что подается на выход системы. И можем проверить только эти соотношения. Это, как правило – тестируют специальные тестировщики. То есть, вот например, функциональное тестирование очень часто тестируют именно методом черного ящика.
   Есть метод белого ящика – то есть, мы опять же знаем, что у нас внутри, как организован проект, какие идут связи и можем более точно построить тесты, например, предположить, что на каких-то граничных условиях наши тесты могут падать.
4. Следующий вид тестирования – это нагрузочное тестирование или стрессовое тестирование. 
   Это проверка на какие-то граничные факторы системы, например, на работу с очень большим количеством пользователей, или работу с условием – мало памяти, мало места на жестком диске и т.д.
5. Также тестирование может выполняться разработчиком или специальными тестерами.
   Но в своей работе, как правило, я видел, что тестирований специальными тестерами выполняется либо мало, потому что средств тестирования очень мало, либо они очень дорогие.
   То есть, организацию тестирования специальными тестерами сделать довольно сложно. Тестирование разработчиком – это самое простое, потому что это может выполнить любой  1С-ник независимо от своего уровня.
6. Самый проблемный вид тестирования – это тестирование пользовательского интерфейса. То есть, здесь очень сложно организовать, потому что, например, в 1С8 построено все на собственной оконной системе, значит, сторонние какие-то программы не могут получить информацию о том, что происходит в 1С.
   А в 1С до недавнего времени не было возможности обратиться и протестировать интерфейс.
   Но – есть уже система тестирования интерфейса в 8.3 и есть система, которая называется «Тест-Комплит», которая позволяет протестировать пользовательский интерфейс, но ее цена – 2500 долларов. Эта система позволяет тестировать любые приложения — .NET приложения, Web-приложения, 1С-приложения (в 7.7 – я лично проверял), но очень дорогое, конечно, лицензирование.

Сейчас немного коснусь существующих систем тестирования

Существующие системы тестирования

1. Первое, с чем мы знакомы, когда говорим «Тестирование 1С» — это, конечно конфигурация «Сценарное тестирование» (входит в пакет 1С:КИП).
   Мое мнение вкратце – не пригодно оно к реальному использованию.
   Оно сделано больше для функционального тестирования и очень сильно зависит от изменений в программе.
   Если в форме добавился какой-то реквизит, Сценарное тестирование может вылетать, если в форме удалился какой-то реквизит – Сценарное тестирование может вылетать.
   Нет возможности исключить ошибки, прогнать все тесты за исключением ошибок. Если есть ошибка, тест остановится весь.
   Кроме этого, неприятным моментом является то, что конфигурация «Сценарное тестирование» не продается отдельно от пакета конфигураций «Корпоративный инструментальный пакет». А цена этого пакета очень велика.
   Хотя – лично мое мнение, что тестирование в 1С должно быть бесплатным.
2. Есть очень хорошая подсистема (автор — Сергей Старых) – называется Подсистема «Инструменты разработчика».
   В этой подсистеме недавно появилось тестирование. Были введены начальные понятия тестирования – тестируются все формы и часть метаданных, то есть, тестируется открытие всех форм, которые есть в конфигурации, для документа тестируется проведение документа, запись документа, удаление документа и т.д.
   Самое интересное – тестируются события и интерактивные изменения форм.
   Например, тестируется ввод пользователем. Как будто пользователь вручную вносит данные. Это очень важно.
   Не в одной из систем, о которых я расскажу далее, нет тестирования этих интерактивных изменений. Например, там можно протестировать поиск по форме (по списку). То есть, как будто пользователь набирает символы, и подсистема это отрабатывает. Очень полезный инструмент.
3. Еще есть некоторые публикации на сайте «Инфостарт».

3.1. Тестирование конфигураций на открытие форм – //infostart.ru/public/21489/ 

Одна из самых первых разработок, поэтому я о ней упомянул. 
Она неудобная и непродуманная на самом деле.

3.2. Есть модуль юнит-тестирования – //infostart.ru/public/22168/ (2024 — Автор удалил свою разработку, ссылка недействительна)

Это опять же, зачаточный такой модуль, просто пример того, как это можно организовать в 1С.

3.3. FuncTest.v8 — infostart.ru/public/19631/ (2024 — Автор удалил свою разработку, ссылка недействительна)

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

3.4. Очень интересная разработка Тестирование (//infostart.ru/public/82718 ) Содержит:

• Функциональное тестирование на обычных формах
• Можно подключать различные алгоритмы
• Можно тестировать запросы и т.д.
• Недостатки: Нет управляемых форм и нет дальнейшего развития

1. Дальше я укажу те системы, которые я сам реально использовал, с которых мое знакомство с системами тестирования для 1С началось:

4.1. Есть система юнит-тестирования для 1С 7.7 – это в свое время я и другие мои товарищи использовали при разработке ВК 1С++ и FormEx (www.1cpp.ru )

• Эта система реально позволяет использовать разработку через тестирование (TDD) для 7.7
• В свое время, благодаря использованию этой системы юнит-тестирования разработка ВК 1С++ стала намного более стабильной, и мы смогли получить стабильные, непадающие версии ВК

4.2. Есть также система Functest для 7.7 (автор Федор Езеев и я там тоже немножко дорабатывал в свое время) (http://1c.alterplast.ru/functest/ )

• До сих пор тоже очень удобно использовать при разработке внешних отчетов/обработок
• Проверка пользовательских данных. Например, проверка оборотно-сальдовой ведомости. Фиксируем некоторый набор данных – данные прошлого года, например. Если через полгода изменятся данные, значит, кто-то что-то изменил. Главное – нам удобно это отслеживать.

4.3. Собственная система Functest для 8.1/8.2 (//infostart.ru/public/15492 )

• Я ее в 8.2 до сих пор успешно использую.
• Недостатки:  немного устарела, нет управляемых форм

4.4. Предпоследняя система – это система юнит-тестирования SnowTest для 8.1/8.2  (www.1cpp.ru/forum/YaBB.pl?num=1267016427/0 ). Автор тоже Федор Езеев.

• Ее как раз тоже можно использовать при разработке через тестирование (TDD) в 8.2

4.5. В новой платформе 8.3 наконец-то появилось более продвинутое тестирование, чем сценарное тестирование. Это система тестирования интерфейса  (http://v8.1c.ru/overview/Term_000000816.htm )

• Шаги в нужном направлении
• Только Управляемое приложение

В этом тестировании используется два клиентских приложения. Одно приложение является тестером, другое приложение является клиентом.

То есть, толстый клиент или тонкий клиент менеджер тестирования взаимодействует (общается) с клиентом тестирования (толстым, тонким или Web-клиентом).
То есть – пишется тест на языке 1С. И заданные действия выполняются в клиенте тестирования.

Пример вызова приложения-теста

На данном скриншоте красная стрелка как раз показывает – есть вариант вызова записи действий пользователя, то есть в 8.3 можно использовать следующую схему работы:

• Пользователь, который знает систему или разработчик может выполнить самостоятельно необходимые действия и записать эту последовательность действий в специальный файл, чтобы в дальнейшем производить этот файл уже в системе тестирования.
• Один минус – пока 1С сделала только надстройку над платформой для записи этого XML файла.
  Среды тестирования пока что нет. То есть те результаты, которые мы можем получить, никоим образом системой 1с не обрабатываются, не анализируются.
• Значит, мы должны написать код для системы тестирования сами
  Возможно, 1С сделает на следующем этапе свою систему тестирования, возможно, она переработает сценарное тестирование. Пока неизвестно. 1С молчит по этому поводу.

Рекомендуемая система для тестирования в 1С

(я фактически ее product-owner и один из авторов) — 

https://github.com/xDrivenDevelopment/xUnitFor1C/wiki (2012-2024 гг.)

В ней огромное количество возможностей, поддержка от 8.2.13 — до 8.3.5.ХХХ, запуск из командной строки, работа с build-серверами, есть хорошая документация, есть много примеров и тестов, есть видеотренинги и видео-примеры.

Есть генерация тестовых данных из боевой базы. Тесты при этом будут работать как в пустой, так и в заполненной тестовой базе.

Система активно развивается как после первой конференции Инфостарт-2012

Защитное программирование

Защитное программирование – очень важный этап применения методики тестирования

На своем опыте — а я общался с разными программистами, специалистами — очень мало народу почему-то использует утверждения. А этот метод очень удобен в разработке.

Использование инвариантов/утверждений

• Утверждения (assertion) – это код (метод или макрос), с помощью которого проверяется правильность заданного условия. В случае, если условие не выполняется, просто выбрасывается исключение – программа прекращает свою работу
• Утверждения можно использовать только для проверки инвариантов, то есть постоянных условий – событий, которые никогда не должны произойти(считаются недействительными)
  • Пример вызова:
                   C++        assert (value !=0);
                   1C           артТесты. ПроверитьЗаполненность (парамКонтрагент, «Метод1::Не задан контрагент»);
  • В 1С в связи с тем, что нельзя получить контекст выполнения, приходится делать более сложный код – поэтому здесь утверждение принимает два параметра – первый параметр — это данные, которые нужно проверить, а второй параметр – это сообщение для анализа.
  • Главная задача утверждений – выявить противоречивые допущения, некорректные значения и условия в ходе разработки программы
  • Утверждение должно останавливать программу. Это – самое главное. Никаких проверок, никаких обработчиков – только останавливать – вызываем метод «ВызватьИсключение».

Обработчик ошибок в программе должен проверять некорректные входные данные из внешних источников, предусмотренные программистом, а утверждения – только ошибки в самой программе. Никаких проверок дополнительных не должно быть, только ошибки в программе — это проверка только для разработчика.

Потому что иногда начинают использовать утверждения для передачи данных во внешнюю систему – это неправильно. Это уже не утверждение.

Я использую утверждения для разных случаев – у меня есть функция, например, в которой я знаю, что должен быть передан параметр, например СправочникСсылка.Номенклатура. Я так и пишу в коде:
                 Тесты.ПроверитьТип(Параметр, СправочникСсылка.Номенклатура)

И все. То есть, если я в дальнейшем изменю интерфейс этой функции, точнее, решу использовать какой-то другой параметр, мне система – моя программа, скажет – ты не прав, товарищ. Переработай свой модуль, потому что программа у тебя остановится и выдаст ошибку. И я уже четко буду знать, что мне нужно будет исправить этот модуль. Я не забуду, как это в большинстве случаев происходит при переделке.

Теперь – самое интересное: Тестирование разработчиком и разработка через тестирование. 

Тестирование разработчиком

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

• Затруднение у разработчиков (Цель тестирования отлична от других этапов разработки, Тестирование требует поиска ошибок в своем коде)
  Тестирование разработчиком вызывает затруднения, потому что цель тестирования отлична от цели разработки. То есть от разработки мы хотим получить правильный код, который правильно работает, получает верные результаты, содержит минимум ошибок и т.д. А в тестировании мы должны найти ошибки, наоборот. Иногда бывает это трудно. Разработчику бывает лень искать ошибки. Разработчик не понимает, что ошибки нужно искать и т.д.
• Тестирование никогда не доказывает отсутствия ошибок.
  Но наличие тестов – это лучше, чем отсутствие тестов.

Что еще можно сказать об основных требованиях к тестированию:

Два главных требования тестирования:

• Тестирование должно быть автоматизированным. А еще лучше – автоматическим 100%. Если тестирование не будет автоматизированным, его никто никогда выполнять не будет.
• Тестирование должно быть быстрым.
   Если тесты будут выполняться медленно, их опять же никто не будет делать. Это все из опыта. 

Разработка через тестирование (TDD)

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

Результаты использования TDD

• Быстрое нахождение ошибок и исправление ошибок
  В результате того, что мы используем тесты до разработки, мы быстро находим ошибки. Потому что пишется тест – потом небольшой кусок кода  — проверяется.
  Если тест упал – значит, вот у нас ошибка – в этом коде из 15-20 строк, и мы легко ее находим – на надо искать несколько часов в модуле из 20 экранов.
• Отладка становится очень простой либо вообще не используется
  Я отладку использую очень редко. Потому что у меня все в тестах, как правило. В крайнем случае я пишу отладочные сообщения. Это более эффективно, чем ходить по коду, искать ошибки и т.д.
• Уверенность в качестве ПО
  У того, кто применяет методику TDD, появляется уверенность в качестве ПО. Он видит, что система работает. Видит, как у него проходят тесты. У него появляется психологическая уверенность.
• Простота доработки/рефакторинга
  Соответственно, поскольку у нас есть тесты – нам легко дорабатывать свою систему. Мы легко можем вносить изменения согласно требованиям заказчика и т.д.
• Выбор проектных решений, например, интерфейсов взаимодействий и дизайна программы.
  Тестирование позволяет нам также заранее принимать проектные решения, т.е. интерфейсы, связи различных модулей, дизайн программ. Например, я вот работаю так – у меня есть задача сделать какую-то выгрузку. Я сначала делаю тесты, продумываю эту выгрузку. Когда мы пишем тесты, мы фактически продумываем дизайн программы. То есть я не рисую ничего в формах – все делается в модуле. Продумываю и только потом, когда моя программа проходит все тесты, которые я сам для себя определил, только после этого я рисую форму, в которой использую только нужные мне данные, которые нашел в результате тестов. То есть, в тестах у меня задан дизайн программы – это очень важно и это на самом деле удобно.
• Разработка через тесты позволяет нам создать слабосвязанные модули.
  Когда мы пишем тест, если модули очень сильно связаны между собой, очень сложно написать хороший тест. Приходится городить неизвестно что. В результате тест не проходит, потому что у нас есть много связей. Приходится облегчать эти связи, т.е. переписывать код, переписывать тест. Зато в результате мы получаем слабосвязанную программу. И это правильно.
• Еще один важный фактор, про который забывают – это создание документации.
  Очень часто у нас документация не связана с программой, т.е. происходит изменение в программе, документация, как правило, отстает от программы. А тесты всегда соответствуют программе. То есть – тесты выступают как всегда актуальная и доступная документация. То есть, если я возвращаюсь через полгода к проекту, который я выполнил на тестах, я первым делом смотрю в тесты и вижу, как все сделано. Если мне нужно доработать, я уже дорабатываю в соответствии с тестами.

Здесь указаны основные принципы, как надо выполнять разработку через тестирование (TDD).

Принципы (правила) разработки через тестирование

• Основные принципы:
  • Не пишите код, пока не будет написан автономный тест, который не проходит
  • Не пишите тест в объеме большем, чем нужно для отказа
  • Не пишите код больше, чем необходимо для прохождения теста
  • Устраняйте дублирование
  • Используйте утверждения для проверки теста
  • Используйте автоматизированную среду запуска тестов
  • Запускайте тесты часто
  • В случае успеха нужна простая «зеленая» полоса. Иногда начинающие пишут много различных сообщений – это путает.
  • Подробные сообщения и «красная» полоса нужны только при отказе теста (для неверных тестов)

Все просто:

1. 1.       Пишем тест, только тест, не пишем код. Причем только в том объеме, который нужен для отказа. Потом пишем код, но тоже только в том объеме, который нужен для теста.
2. Последний принцип, про который иногда забывают – это устранение дублирования. То есть, в тесте и в коде не должны быть использованы одинаковые механизмы.
3. Еще одно требование, которое я предлагаю использовать всем – это использование утверждений. Просто пишем, если тест должен проверять какую-то функцию, которая должна быть выполнена и возвращать какое-то значение, мы должны проверить это значение и все. Больше ничего нам не нужно.
   Просто пишем:
                                  Тесты.ПроверитьИстину(Условие)
4. Как я уже говорил, тесты должны запускаться автоматически, поэтому должна быть какая-то среда. Тесты не должны запускаться вручную.
5. Тесты должны запускаться часто. Если они не будут запускаться часто, мы напишем очень много кода. Напишем много кода – будет много ошибок.

Здесь у меня представлен цикл тестирования. Он очень простой:

TDD — цикл тестирования/кодирования

• Пишем тест. Компилируем. В 1С под компиляцией понимается успешное прохождение проверки синтаксиса.
• Запускаем тест. Убеждаемся, что он не проходит в режиме выполнения.
• Пишем код в том объеме, который нужен для успешного срабатывания теста в режиме выполнения.
• Запускаем тест и убеждаемся, что он корректно отработал
• Обязательно выполняем рефакторинг  для «чистоты» кода, устраняем дублирования. Исправляем свой тест, чтобы он стал проще, легче. Исправляем свой код.
• Повторяем последовательность сначала
• Главное — использовать короткие циклы в разработке, чтобы поиск ошибок был наиболее упрощенным

TDD – принципы написания тестов

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

Выводы:

• Для построения качественного ПО нужно использовать различные методики, а также комбинации различных методик
• Используйте утверждения для повышения качества кода
• Использование тестирования снижает затраты на разработку и сопровождение
• Тестирование не гарантирует нахождение всех ошибок
• TDD и тестирование повышают надежность ПО и качество системы
• Работа разработчика становится более эффективной
• Работа в режиме TDD приносит больше положительных эмоций
• Вход в TDD не так сложен, как кажется тем, кто не знаком с TDD
•  

Литература

• С.Макконнел. Совершенный код
• К.Бек. Экстремальное программирование
• К.Бек. Экстремальное программирование: разработка через тестирование
• М.Фаулер. Рефакторинг — улучшение существующего кода
• Р.С.Мартин, М.Мартин. Принципы, паттерны и методики гибкой разработки на языке C#
• К.Ауэр, Р.Миллер. Экстремальное программирование. Постановка процесса с первых шагов и до победного конца.
• Р.С.Мартин. Чистый код

*****************

Приглашаем вас на новую конференцию INFOSTART EVENT 2024 INCEPTION.