Методики построения качественного ПО и сопровождения ПО Традиционный цикл разработки Проектирование ? Кодирование ! Тестирование ? отладка ! Главный закон качества ПО Повышение качества системы снижает затраты на ее разработку и сопровождение Отладка и исправление неверного кода занимает около 50% времени Методики повышения качества ПО Защитное программирование Обзоры кода Проектирование Тестирование Экстремальное программирование

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

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

Существующие системы тестирования в 1С Конфигурация «Сценарное тестирование» Непригодна к реальному использованию Не продается отдельно от 1С:КИП Тестирование метаданных и форм в подсистеме «Инструменты разработчика» devtool1c.ucoz.ru infostart.ru/public/15126/ devtool1c.ucoz.ruinfostart.ru/public/15126/ Тестирование интерактивных изменений форм. Но не все виды таких изменений. Тестирование событий интерактивных изменений

Существующие системы тестирования в 1С (2) Публикации на сайте «Инфостарт» Тестирование конфигурации на открытие форм объектов - infostart.ru/public/21489/ infostart.ru/public/21489/ Неудобно использовать в реальной работе Модуль юнит-тестирования - infostart.ru/public/22168 / infostart.ru/public/22168 / Нет развития, в реальном тестировании не используешь FuncTest.v8 - infostart.ru/public/19631/infostart.ru/public/19631/ Интересна, но удалена автором. Не до конца продумана система тестирования Тестирование (внешняя обработка) infostart.ru/public/82718/ infostart.ru/public/82718/ Функциональное тестирование Интересная разработка Нет развития

Существующие системы тестирования в 1С (3) Система юнит-тестирования для 1С 7.7 для разработки в 1С и ВК 1С++ и FormEx Реально помогает в 7.7 Удобно использовать для TDD для 7.7 Система функционального тестирования Functest для 1С 7.7 1c.alterplast.ru/functest/ 1c.alterplast.ru/functest/ Удобно использовать при разработке внешних отчетов/обработок Проверка пользовательских данных Собственная система функционального тестирования Functest для 1С 8.1/8.2 infostart.ru/public/15492/ infostart.ru/public/15492/ Устарела, но еще можно использовать Система юнит-тестирования SnowTest для 8.1/ Удобно использовать для TDD в 8.2

Автоматизированное тестирование в 8.3 Система тестирования интерфейса у платформы 8.3 v8.1c.ru/overview/Term_ htm v8.1c.ru/overview/Term_ htm Шаги в нужном направлении Только Управляемое приложение Имитация действий пользователя осуществляется при помощи набора объектов встроенного языка, предоставляющих доступ к логической модели интерфейса клиентского приложения и элементов форм.встроенного языкаклиентского приложенияэлементов форм При автоматизированном тестировании между собой взаимодействуют два клиентских приложения. Это менеджер тестирования и клиент тестирования.клиентских приложения

Автоматизированное тестирование в 8.3 (2) Схема взаимодействия Пример вызова приложения-теста

Автоматизированное тестирование в 8.3 (3) В качестве менеджера тестирования может выступать толстый или тонкий клиент.толстыйтонкий клиент Клиентом тестирования может быть любое из клиентских приложений: толстый клиент, тонкий клиент или веб-клиент.клиентских приложенийтолстый клиенттонкий клиентвеб-клиент Результат выполнения автоматизированного теста может контролироваться визуально, либо программно. Есть возможность автоматической записи интерактивных действий пользователя в XML файл. Клиентское приложение запускается в специальном режиме, в котором можно записать журнал действий пользователя. Клиентское приложение Минус - пока нет общей среды тестирования.

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

Использование инвариантов/утверждений (2) Обработчик ошибок в программе должен проверять некорректные входные данные из внешних источников, предусмотренные программистом, а утверждения – только ошибки в самой программе. Утверждения должны останавливать программу – вызываем метод «ВызватьИсключение» Утверждение не нужно обрабатывать в коде, за исключением специальных отказоустойчивых приложений. Используйте утверждения для проверки предусловий и постусловий.

Тестирование разработчиком Затруднение у разработчиков Цель тестирования отлична от других этапов разработки Тестирование никогда не доказывает отсутствия ошибок Тестирование требует поиска ошибок в своем коде Тестирование можно использовать для начальной оценки надежности системы Тестирование должно быть автоматизированным Тестирование должно быть быстрым

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

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

TDD – цикл тестирования/кодирования Напишите один тест Откомпилируйте его. Компиляция теста не пройдет Напишите код, чтобы прошла компиляция теста Запустите тест и убедитесь, что он не срабатывает Напишите столько кода, сколько нужно только для срабатывания теста Запустите тест и убедитесь, что он корректно отработал Выполните рефакторинг для «чистоты» кода и устранения дублирования Повторите последовательность сначала Используйте короткие циклы

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

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

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