Рубрика «tdd»

Аннотация

Статья рассказывает о нетрадиционном, но полезном виде тестов, а также подводит итоги семилетней работы в разработке тестов.

Зачем нужны компонентные тесты?

Ведь есть, скажем, юнит-тесты, которые подробно тестируют потроха компонентов. Они досконально проверяют, что компонент работает в соответствии с замыслом разработчика. Но часто это проверка "пуговиц", а не того, как сидит костюм в целом. И не всегда поведение, задуманное программистом, совпадает с тем что хотел заказчик.

А еще есть, например, приемочные тесты. И они устраняют все указанные недостатки. Но, к сожалению, вносят новые. Они медленные, часто нестабильные, и обычно ручные. При этом они только свидетельствуют о проблеме, но не локализуют ее.

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

Читать полностью »

Пирамида тестов на практике - 1Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

«Пирамида тестов» — метафора, которая означает группировку тестов программного обеспечения по разным уровням детализации. Она также даёт представление, сколько тестов должно быть в каждой из этих групп. Несмотря на то, что концепция тестовой пирамиды существует довольно давно, многие команды разработчиков по-прежнему пытаются неправильно реализовать её на практике должным образом. В этой статье рассматривается первоначальная концепция тестовой пирамиды и показано, как её воплотить в жизнь. Она показывает, какие виды тестов следует искать на разных уровнях пирамиды, и даёт практические примеры, как их можно реализовать.

Содержание

Примечания

Читать полностью »

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

Тестирование ПО: автоматизация, оценка и… утопичность - 1

Читать полностью »

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология

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

Антипаттерны тестирования ПО - 1

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

Читать полностью »

Ранее на хабре публиковалась статья о том, как в теории выглядит Xp/Tdd в Пивотал Лабс, и были вопросы о том, возможнонужно ли это в действительности. Я попытаюсь объяснить, как это выглядит на практике и почему это может быть (внезапно) хорошо.

В последние полгода мне пришлось поработать в одном из больших банков на проекте с Pivotal Labs, в их нью-йоркском офисе. Это очень отличается от всей энтерпрайс-разработки, которую мне приходилось видеть до этого.
Читать полностью »

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

Читать полностью »

Введение

Хорошо известна возможность интеграции Python и C / C++. Как правило, этот прием используется для ускорения программ на Python или с целью подстройки программ на C / C++. Я хотел бы осветить возможность использование python для тестирования кода на C/C++ в IDE без поддержки системы организации тестов в IDE. С моей точки зрения это целесообразно применять в сфере разработки программного обеспечения для микроконтроллеров.

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

При разработке программ для микроконтроллеров, я сталкивался с отсутствием стандартного ввода / вывода (конечно можно переопределить функции ввода вывода и в симуляторе, выводить данные через UART — но часто UART уже задействован, да и симулятор работает не всегда корректно) и большими рисками вывести из строя аппаратное обеспечение ошибочной бизнес логикой. На стадии разработки, я реализовывал отдельные проекты, тестирующие части программы и далее на меня ложилась ответственность за запуск всех тестовых приложений после внесения изменений. Конечно, это все можно автоматизировать. Так можно работать, но я нашел способ лучше.
Читать полностью »

Тестирование глазами разработчика: инструменты, мифы, ситуации - 1

Евгений Сафронов, Senior Developer, DataArt

«Тестирование можно использовать для того, чтобы доказать наличие ошибок в программе, и никогда — для того чтобы доказать их отсутствие!»
Эдсгер Дейкстра

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

Тестирование — это проверка работоспособности программы, предмета или любой промышленной разработки. Как и в любом деле, здесь есть свои тонкости и своя философия. Она, наверное, ближе тестировщикам, которые на произведенные нами вещи смотрят деструктивно — они с самого начала думают о том, как сломать предложенный разработчиками продукт. Это не очень типично для пользователей, которые более предсказуемы и обычно находят ошибки, случайно пытаясь сделать с нашей программой что-то нетипичное. У разработчиков подход к программам в принципе другой, но мы должны помнить: тестировщики должны ломать то, что мы создали — это их хлеб.Читать полностью »

Привет! Представляю вашему вниманию перевод статьи Test Contra-variance

От переводчика: честно говоря, выбор слов ко-/контравариантность, по отношению к дизайну тестов, немного странен. Семантика конечно прослеживается, но весьма метафорична. Скорее всего, просто для красного словца и заголовка, привлекающего внимание, поэтому не сильно придирайтесь. В остальном — прекрасная заметка на тему TDD в формате диалога. Рассказано почему TDD это так больно, как сделать из юнит-тестов приятный инструмент и не относится к ним как к обязательно ломающемуся насилию над свободой самовыражения.

Читать полностью »

image
Simon Stålenhag — Tyrannosaurus (http://www.simonstalenhag.se)

“Будьте осторожны с использованием следующего кода — я лишь доказал, что он работает, но я не тестировал его” Дональд Кнут

Техника “Сначала Тест” (Test-First Design, далее TSD) появилась вместе с экстремальным программированием (Extreme Programming, далее XP, кстати, эта абревиатура никак не связана с Windows) и является одним из основных подходов этой методологии. Впервые книжное упоминание этой техники было в Extreme Programming Explained 1999 K.Beck
Читать полностью »