Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
Тестирование — это способ узнать о разнообразных проблемах, которые могут возникнуть во время разработки вашего проекта. В лекции рассмотрены различные виды тестирования и различные практики, которые позволят вам узнавать о проблемах заранее.
Наталья Чуфырина, Mail.Ru Group, «Как создать команду по автоматизации тестир...Mail.ru Group
Существует мнение, что от разработчиков системы автоматизированных тестов требуется высокая квалификация в области разработки программного обеспечения и солидный багаж знаний. Обычно таких людей в команде тестирования не много. Но можно начать работы по качественной автоматизации тестирования, даже не имея такого опыта. В докладе речь пойдет о:
отборе рекрутов в программу обучения автоматизации тестирования;
первичном пороге для вхождения в рекруты;
составлении учебной программы;
промежуточном контроле и испытаниях;
начале работы над реальными проектами;
подводных камнях и ошибках, которые можно допустить.
Применение этих знаний на собственном опыте позволило компании получить высокое покрытие проекта тестами и достичь результатов, когда каждый из команды разрабатывает и поддерживает автотесты, а также самостоятельно автоматизирует новые проекты.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
Автоматическое тестирование и с чем его едятMarina Peregud
Agenda
Автоматизация? Какая еще автоматизация? Автоматическое тестирование ПО. Зачем вообще?
Отличие от мануального тестирования ПО, или Ручник vs человек разумный.
Имею желание, но не имею возможности, или какие знания были бы полезны в этой области.
Когда стоит внедрять автоматизацию.
ROI и другие непонятные слова на три буквы.
Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
Тестирование — это способ узнать о разнообразных проблемах, которые могут возникнуть во время разработки вашего проекта. В лекции рассмотрены различные виды тестирования и различные практики, которые позволят вам узнавать о проблемах заранее.
Наталья Чуфырина, Mail.Ru Group, «Как создать команду по автоматизации тестир...Mail.ru Group
Существует мнение, что от разработчиков системы автоматизированных тестов требуется высокая квалификация в области разработки программного обеспечения и солидный багаж знаний. Обычно таких людей в команде тестирования не много. Но можно начать работы по качественной автоматизации тестирования, даже не имея такого опыта. В докладе речь пойдет о:
отборе рекрутов в программу обучения автоматизации тестирования;
первичном пороге для вхождения в рекруты;
составлении учебной программы;
промежуточном контроле и испытаниях;
начале работы над реальными проектами;
подводных камнях и ошибках, которые можно допустить.
Применение этих знаний на собственном опыте позволило компании получить высокое покрытие проекта тестами и достичь результатов, когда каждый из команды разрабатывает и поддерживает автотесты, а также самостоятельно автоматизирует новые проекты.
*Netpeak Talks — это серия ивентов от Netpeak Group в Одессе (при поддержке ассоциации продуктовых компаний IT-Products Odessa).
В рамках этих встреч есть возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
______________________
Тема #11: Как работать с legacy проектом, которому больше 10 лет?
Спикер: Денис Воскобойник — Team Lead отдела разработки внутренних продуктов в Netpeak Agency.
Тезисы видео:
✔ Построение процессов разработки.
✔ Подготовка команды к проекту.
✔ Внедрение / обновление стека технологий.
✔ Как рефакторить?
✔ Как понять, что нужно вынести отдельно и нужно ли это?
✔ Как тестировать то, что никогда не тестировалось?
✔ Code Review.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
Сайт: http://netpeak.group/talks
Facebook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
Автоматическое тестирование и с чем его едятMarina Peregud
Agenda
Автоматизация? Какая еще автоматизация? Автоматическое тестирование ПО. Зачем вообще?
Отличие от мануального тестирования ПО, или Ручник vs человек разумный.
Имею желание, но не имею возможности, или какие знания были бы полезны в этой области.
Когда стоит внедрять автоматизацию.
ROI и другие непонятные слова на три буквы.
Задорная презентация, посвещенная введению в разработку через тестирование. В частности, рассмотрены такие методологии как TDD (Test-Driven Development) и BDD (Behavior-Driven Devopment), их несомненные достоинства и недостатки, а также практическое применение.
Презентация подготовлена по материалам прошедшей 10.10.2013 конференции "Developers Software Conference 2013" в Витебске, организатором которой выступила компания "EPAM Systems".
Behavior Driven Development - подход к разработке ПО, основывающийся на ориентации на business value и исполняемых спецификациях, написанных на человеческом языке
“Обезьянье тестирование” в мобильных проектах, Роман Подолян
Хотите уйти от проторённых путей, проверить приложение самыми разнообразными, случайными последовательностями действий? Задать ему встряску чтобы проверить его на выносливость? Сделать с ним то, что даже не собирались? Отдайте его “обезьяне”.
Keyword-driven testing is a software testing methodology that uses predefined keywords to describe test cases instead of natural language. Keywords represent common testing actions and are associated with code that implements those actions. This allows testers to write automated test cases without extensive programming knowledge. The document discusses how to implement keyword-driven testing using the Maveryx test automation tool, including identifying keywords, writing test cases with keywords, implementing keyword code, and executing automated tests.
Проблемы автоматизации крупных проектов: TestComplete, Дмитрий Марков
Дмитрий в своем докладе рассмотрит следующие вопросы:
Инструмент TestComplete. В чем сила?
Чем отличается автоматизация мелкого, среднего, крупного проекта?
Нужно ли что-то дополнительно делать при автоматизации крупного проекта?
Ошибки на начальных стадиях автоматизации
Раз говорим об ошибках, то также поговорим о том, как можно построить все так, чтобы этих ошибок избежать
Практические набитые шишки автоматизатора
Keyword-driven testing, Геннадий Алпаев
Keyword-driven подход к автоматизации тестирования был описан в литературе более 10ти лет назад, однако в русскоязычных источниках по этой теме информации довольно мало. В докладе Геннадий расскажет о том, в чем заключается подход, когда применяется, его достоинства и недостатки, а также покажет пример практической реализации Keyword-driven подхода для простого тестируемого приложения с помощью TestComplete и SilkTest.
Data-driven testing is a methodology where test input and output values are read from external data sources like files or databases. A single test script can be used to execute multiple test cases by varying the test data. Maveryx is a tool that supports data-driven testing through features like intelligent object recognition, separation of test logic from data, and reading test data from sources like Excel. The document provides an overview of data-driven testing and examples of how to create a data-driven test script using Maveryx.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
В статье рассмотрен ряд вопросов связанных с тестированием 64-битного программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик ресурсоемких 64-битных приложений, и пути их преодоления.
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17OdessaFrontend
Если еще несколько лет назад фронтенд это часто был простой и понятный интерфейс между пользователем и бекендом, то на сегодняшний день с учетом обилия фреймворков, либ и все возможных новшеств, фронтенд уже можно считать полноценным отдельным приложение со своей логикой и множеством подводных камней именно по этом сегодня как никогда важно задумываться о том, а как обеспечить простой и понятный процесс тестирования вашего фронта?
Как сделать так чтоб покрытие авто тестами не стало для вас болью или не для вас, но всё еще болью? Дмитрий Хименес обращает ваше внимание на несколько простых моментов, которые стоит учитывать при разработке фронтенда, чтобы сохранить возможность безболезненно сопровождать его автотестами.
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Tatyanazaxarova
В результате появления на рынке персональных компьютеров 64-битных процессоров перед разработчиками программ возникает задача переноса старых 32-битных приложений на новую платформу. После переноса кода приложения высока вероятность его некорректной работы. В статье рассмотрены вопросы, связанные с верификацией и тестированием программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик 64-битных Windows приложений и пути их преодоления.
Glib Rybalko, GlobalLogic’s Test Lead, consultant and trainer was among 26 known Ukrainian and international experts who took a word on IT Weekend Ukraine 2013. Glib discussed features of automated software testing, benefits and feasibility of using this approach on various projects. During his speech, Glib pointed all necessary steps of automated testing implementation and gave homework for those who were interested in this field and wanted to implement it in their projects.
Слады для выступления на GDG DevFest Бишкек, 2014.
https://plus.google.com/events/cgschph5k60ua1ldq0b06i3o3r8
Выступление сделано по книжке "Как тестируют в Google"
Регулярное использование статического анализа кода в командной разработкеTatyanazaxarova
Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.
В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода PVS-Studio.
Рефакторинг и второе рождение проекта на примере Zend Framework 2.0
Ошибки начинающих Tdd практиков, плюсы применения
1. Ошибки начинающих TDD-практиков
Начнем с того, что большинство разработчиков неправильно понимает идею TDD. Можно
выделить три способа применения модульных тестов разработчиками:
• Традиционный – когда разработка ведется полностью через тесты,
один тест за раз, при этом активно применяется рефакторинг.
Первоначальная реализация рабочего кода обычно является
нарочно упрощенной, конечный дизайн кода получается
последовательно и только исходя из появления новых тестов. Это и
есть TDD.
• Активный – отличается от традиционного тем, что разработчик
сначала обдумывает дизайн рабочего кода, а затем начинает
целенаправленно идти к этому дизайну через тесты. (test-first
development).
• Приемочный - вместо того, чтобы писать небольшие тесты,
разработчик пишет сразу конечный тест, который реализует
конечную функциональность. Далее он продумывает дизайн
реализации, и всю несуществующую функциональность забивает
мок-объектами, стараясь запустить тесты как можно раньше. После
этого постепенно убирает мок-объекты, заменяя их реальными
классами. Это скорей приемочные тесты.
2. Запахи тестового кода
• Медленные тесты
• Хрупкие тесты
• Сложный тест или тест-«спагетти»
• «Эхо в горах»
• Набор тестов не срабатывает без подключения к сети
• Чрезмерное доверие мокам
• Недостаточное доверие мокам
3. Медленные тесты
Один из самых очевидных признаков загнивания проекта. Кратко описать идею можно так -
требуется слишком много времени для выполнения теста. Когда вы разрабатываете
приложение, то должны иметь возможность выполнять весь набор тестов (TestSuite)
неограниченное количество раз и не должны ждать тесты слишком долго. Почему это так важно:
• Медленные тесты запускаются реже, из-за этого снижается отдача
от тестов, ошибки находятся позднее, их исправление занимает
много времени. Вы должны иметь возможность проверить все
приложение при малейшем подозрении, что текущие изменения
могут оказать влияние на другие части приложения.
• Медленные тесты - это признак плохой изоляции тестируемого
класса от других классов. Здесь может быть 2 причины: 1) или
разработчик не умеет пользоваться продвинутыми методиками
тестирования, такими как моки и стабы, 2) или же архитектура
приложения не позволяет этими техниками пользоваться, что
говорит о больших зависимостях между компонентами архитектуры.
Во втором случае - это признак загнивающего проекта.
4. Хрупкие тесты
Этот запах часто является отговоркой новичков, почему они не пишут тесты. Якобы тесты
слишком часто ломаются при изменении кода, поэтому они значительно увеличивают нагрузку
на разработчика. Существует несколько причин появления этого запаха:
• Чаще всего причиной этому становятся медленные тесты. Если
полный набор выполнять долго, то разработчики начинают выби-
рать, когда и как часто запускать полный набор, а все остальное
время будут запускать тесты только для того кода, над которым они
работают в текущий момент. Запускайте тесты чаще и они ломаться
будут реже!
• Другая причина - неправильное тестирование. Тест «знает»
слишком много деталей тестируемого кода, из-за этого при малей-
ших изменениях в тестируемом коде тесты ломаются. Приходится
править и тесты, и тестируемый код. Относиться к этому можно
двояко - 1) если вы меняете поведение класса, то изменение в
тестах прогнозируемы, 2) а вот если вы проводите рефакторинг кода
без изменения функциональности, а тесты постоянно ломаются -
значит есть повод подумать, как переделать тесты.
• Еще одна причина - это дизайн системы, который не позволяет
писать изолированные тесты. В этом случае тесты дают понять, что
код требует рефакторинга.
5. Сложный тест или тест-"спагетти"
Данная проблема часто возникает у разработчиков, которым не терпится протестировать
некоторую функциональность досконально, исчерпывающе проверяя всевозможные внутренние
состояния. Есть несколько причин появления этого запаха:
• Тесты должны как можно меньше опираться на внутреннее
состояние тестируемой сущности и скорее относится к ней, как к
некоторому черному ящику. Тем самым разработчик
гарантированно огораживает себя от трудности дальнейшей
поддержки и модификации тестов при рефакторинге кода.
• Тесты должны тестировать модули именно так, как это будет
делать остальной код в реальном приложении. Нет
необходимости тестировать все мыслимые комбинации, если класс
никогда не будет таким образом использован. Помните принцип
YAGNI (You Aren't Gonna Need It) и цените свое время.
• Эта проблема часто возникает из-за неправильного внутреннего
дизайна разрабатываемой функциональности и является
первым звонком для переработки(рефакторинга) как
разрабатываемого, так и тестового кода.
6. "Эхо в горах"
Если вы тестируете что-либо в одном месте и только в этом месте, тогда одна внесенная
логическая ошибка в тестируемый код должна приводить к поломке только в одной части
набора тестов. Причины появления эха:
• Ваш набор тестов содержит большой набор дублирующих
друг друга проверок. При разработке тестов нужно четко
представлять, что же именно вы тестируете, и избегать подобных
дублирующих проверок, чтобы не создавать себе дополнитель-
ной работы. Помните основной принцип прагматичного
программиста Don't repeat yourself - DRY.
• Еще одна причина - это дизайн системы. Если дублирующих
проверок избежать не удается, тогда стоим задуматься о
рефакторинге дизайна системы, которую вы тестируете.
7. Набор тестов не срабатывает без
подключения к сети
Большинство приложений уровня предприятия требуют подключения к внешним приложениям
для различных целей. Это могут быть платежные системы, серверы аутентификации и т.д. В
идеале модульные тесты должны работать с консольном режиме, без web-сервера и базы
данных (не обязательно), без дополнительных библиотек и проч. Там, где это можно и
целесообразно, нужно использовать моки и заглушки. Причины:
• Вы очевидно вышли за границы модульного тестирования и
приблизились к системному тестированию. Такие тесты должны
быть перенесены в приемочные тесты и исключены из набора
модульных тестов. Это подтолкнет вас к выделению классов,
которые взаимодействуют с внешними ресурсами, снижению
зависимостей от этих классов, использованию заглушек и моков.
• Слабое использование моков и заглушек.
8. Чрезмерное доверие мокам
Если вы окружили свой тестируемый код плотным кольцом моков и заглушек, то есть риск
забыть про реальное применение класса и снова попасть в ловушку. Лежащие в основе
использования моков предпосылки заключаются в том, что они действуют во многом именно
так, как действовали бы реальные объекты. Очень часто мы сталкиваемся с ситуацией, когда
весь набор модульных тестов низкого уровня срабатывает, а приемочные тесты - нет. Причина
ошибок часто заключается в том, что тесты были изолированны моками, поведение которых
уже более не соответствует реальному поведению классов, которые они заменяют. Решение:
• Аккуратно использовать моки, только там, где это уместно.
• Обязательно иметь в наличии функциональные тесты или
модульные тесты высших уровней, которые реализованы без
использования моков и заглушек. Путь эти тесты будут не такими
подробными и быстрыми, зато они помогут отловить те ошибки,
которые остались незамеченными при модульном тестировании.
9. Недостаточное доверие мокам
Очевидно, что это противоположная сторона предыдущего запаха. Если вы чаще предпочитаете
использовать реальные классы в тестах, где тестируемый класс зависит от других классов, то
это прямой путь в тестовый ад с раздутыми, медленными и хрупкими тестами, которые часто
ломаются, медленно работают и которые очень трудно писать и понимать. Признак:
• Большой и сложный метод setUp().
• В конце концов, если один тест проверяет, что база может
вернуть набор A по запросу B, разве мы не может
предположить, что она сделает то же самое в десяти других
тестах вашего тестового набора, которые зависят все от того же
запроса B?
• Но, Правильное использование моков зависит от опыта
разработчика и сложившейся ситуации. Необходимо слушать свой
код, как тестируемый, так и тестовый, для того, чтобы не попадать ни
в одну их этих ловушек.
10. Преимущества модульного тестирова-
ния или почему нужно тестировать код
• Тесты предотвращают появление ошибок в новом
коде
• Тесты позволяют рефакторить код без риска его
сломать
• Тесты могут использоваться в качестве
документации
• Тесты улучшают дизайн кода
• Тесты способствуют повышению квалификации
разработчиков
• Тесты ускоряют процесс разработки
11. Тесты предотвращают появление
ошибок в новом коде
• Тесты являются сами ранними клиентами кода и
позволяют выявлять многие ошибки сразу.
• Тесты заставляют разработчика идти мелкими
шагами и более пристально уделять внимание
коду, который он пишет. Если разработчик
чрезмерно ускоряется - то шанс нарваться на красную
полоску значительно повышается.
• Тесты позволяют убедиться в работоспособности
кода на самых ранних этапах разработки, когда
другие части системы еще не готовы.
В результате ошибки выявляются и исправляются в самом начале разработки, а количество
ненайденных багов в новом коде сокращается .
12. Тесты позволяют рефакторить код без
риска его сломать
• При внесении изменений в хорошо протестированный
код, риск появления новых ошибок значительно ниже.
Если новая функциональность приводит к
ошибкам, тесты, если они конечно есть, сразу же это
покажут. При работе с кодом, на который нет
тестов, ошибку можно обнаружить спустя значительное
время, когда с кодом работать будет намного сложнее.
• Хорошо протестированный код легко переносит
рефакторинг. Уверенность в том, что изменения не
сломают существующую функциональность, придает
уверенность разработчикам и увеличивает эффективность
их работы. Если существующий код хорошо покрыт
тестами, разработчики будут чувствовать себя намного
свободнее при внесении архитектурных решений, которые
призваны улучшить дизайн кода.
13. Тесты могут использоваться в качестве
документации
• Хороший код расскажет о том, как он работает, лучше
любой документации. Документация и комментарии в
коде могут устаревать. Это может сбивать с толку
разработчиков, изучающих код. А документация, в отличие
от тестов, не может сказать, что она устарела.
• Когда программисты изучают API, они обычно ищут
примеры кода. Тесты являются хорошими примерами в
этом смысле, так как они показывают как можно
использовать классы, через какой API, какие у классов
есть зависимости и т.д.
• Стоит также отметить, что тест может играть роль ТЗ.
Вы пишете функциональный тест на компонент и отдаете
этот тест человеку, который должен будет сделать
реализацию. Когда тест сработает - задание может
считаться выполненным, и его дополнительно проверять не
нужно.
14. Тесты улучшают дизайн кода
• Тесты заставляют вас делать свой код более
приспособленным для тестирования. Например, отказываться
от глобальных переменных, одиночек (singletons), делать классы
менее связанными и легкими для использования. Сильно
связанный код или код, который требует сложной инициализации,
будет значительно труднее протестировать.
• При добавлении новой функциональности или
рефактиринге, тесты заставляют подумать о том, что именно
должен делать код. Начиная с теста, вы сразу же видите
клиентский код. В результате получается чистый и простой
дизайн, который делает именно то, что нужно и ничего лишнего.
• Модульное тестирование способствует формированию
четких и небольших интерфейсов. Каждый класс будет
выполнять определенную роль, как правило небольшую. Как
следствие, зависимости между классами будут снижаться, а
зацепление повышаться.
15. Тесты способствуют повышению
квалификации разработчиков
• Тесты заставляют разработчика по-другому
посмотреть на наследование и делегирование, чаще
применять шаблоны проектирования, искать
оптимальные пути организации кода. Как следствие, вы
будете более интенсивно использовать шаблоны
проектирования.
• По мере роста опыта в TDD вы самостоятельно
придете к пониманию сути таких базовых принципов
ООП как «инверсия зависимостей», «отделение
интерфейсов», «открытие-закрытие».
• Автоматизированное тестирование, в отличие от
ручного, заставляет разработчика глубже «копать» код.
Ему становятся понятными многие решения, примененные
к коду. При этом разработка через тестирование обычно
ведется в парах, поэтому такие знания распространяются
быстрее.
16. Тесты ускоряют процесс разработки
• Тесты защищают от ошибок. Поэтому время,
затрачиваемое на отладку, снижается многократно.
• Тесты позволяют различным группам
разработчиков легко действовать параллельно, не
ожидая результатов труда друг друга.
• Тесты сокращают количество кода, необходимого
для удовлетворения требованиям клиента.
• Уверенность в том, что все работает как надо
после изменений, позволяет выпускать версии
продукта горазда раньше и чаще. Немаловажен и
тот факт, что автоматизированное тестирование
сокращает по продолжительности бета-тестирование.