TDD *

Кент Бек сделал для IT столько, что его имя упоминается на Хабре в сотнях разных постов. Но при этом до сих пор не было хабрапоста о нём самом. Исправим это упущение.

Во вторник Кент выступит на нашей онлайн-конференции по тестированию Heisenbug. Там этот человек, когда-то популяризовавший подход TDD, поговорит о куда более новой концепции TCR («Test && Commit || Revert»). То есть даже к 60 годам он не стал жить былыми заслугами, а продолжает предлагать новое.

Идея TCR кажется многим безумной. Но давайте вспомним все предыдущие достижения Бека — и заметим, что многие из них тоже когда-то казались людям совершенно непрактичными, а потом оказались очень осмысленными.

Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.

Вступление

Привет, Хабр. Сегодня я расскажу вам про Record-and-Replay подход к тестированию т. к. я его понимаю. Оговорка про мое понимание не случайна. Про этот подход не так много общедоступных материалов, чтобы иметь некий common agreement относительно значения этого термина. Многое из того, что я опишу, является моими личными оригинальными находками, но, тем не менее, фраза record-and-replay, на мой взгляд, наилучшим образом описывает применяемые мной решения. Так что я буду использовать именно ее.

Чтобы было проще понять, какие проблемы решает RnR, в ходе этого разговора мы сначала обсудим некоторые другие подходы к написанию тестов (юнит-тестирование, интеграционное тестирование и т. д.). И отталкиваясь от их недостатков перейдем к варианту с RnR, я расскажу, что же это собственно такое, как это работает, и каким образом решает озвученные ранее проблемы. Поговорим про подводные камни, которые могут свести пользу от внедрения всего этого дела к нулю. Ну и, конечно, обсудим недостатки или границы применимости этого подхода.

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

Ключевой постулат

Итак без лишних предисловий к ключевой идее статьи. В ней будет немало оценочных суждений, и думаю необходимо сразу сказать, в свете какой идеи я делаю эти оценки. Итак… Ключевой постулат - «Ресурсы на тестирование ограничены».

Привет, Хабр! На написание этого поста меня вдохновил другой пост TDD есть опиум для народа, где обсуждаются спорные моменты в подходе TDD и в принципе делается вывод о его несостоятельности (хотя и признается необходимость тестов в любом случае). С автором я был полностью согласен... раньше, пока не понимал действительную суть TDD. Поэтому, я счел своим долгом рассказать суть Test Driven Development от лица человека, который пробовал писать тесты до реализации, разочаровался из-за сложностей, и только через некоторое время, уловив основную мысль, увидевшего новые возможности в разработке через тестирование.

Замечание: я всего лишь junior, и опыта разработки у меня не так много. Но надеюсь, что мне удастся донести мысль до читателя, а ошибки помогут исправить в комментариях. Примеры будут на Kotlin, мне кажется, это не должно стать помехой, язык достаточно хорошо читаемый. Несмотря на довод о слишком упрощенных примерах (наподобие калькулятора) в оригинальной статье, здесь я также не иду в дебри реальных повседневных задач, ограничиваясь кустарным примером. Да простит меня читатель, я не хочу заставлять сильно вникать в код, хочу просто объяснить идею.

Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.

Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.

Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.

Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.

Перевод статьи "Why most unit testing is waste?"

Автор: James O Coplien, Перевод: Епишев Александр  

1.1 Наши дни

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

Laravel – классный PHP-фреймворк, мы им постоянно пользуемся в компании. Но как известно, ничто в мире не идеально, можно всегда предложить улучшения.

Несколько недель назад я попытался сделать одно маленькие улучшение по части тестов в Laravel, открыл два пулл-реквеста (#1 и #2). Оба пулл-реквеста были отклонены автором фреймворка Тейлором, но в итоге он сам в этот же день опубликовал собственную реализацию того же функционала, о чём даже в твиттере похвалился. И, о боги, реализацию ужасную!

Да, вы не ослышались – именно так! В IT-сообществе прочно укоренилось мнение, что все эти тесты вам хоть как-то помогают, но так ли это на самом деле? Вы сами пробовали мыслить критически и анализировать это расхожее мнение? Хипстеры придумывают кучу парадигм – TDD, BDD, ПДД, ГИБДД – лишь чтобы создать иллюзию бурной деятельности и хоть как-то оправдать свою зарплату. Но задумайтесь, что будет, если вы (либо ваши программисты) начнете все свое время уделять исключительно написанию кода? Для тестирования есть отдельное направление и целые подразделения. Вы же не заставляете программистов писать требования, так? Тогда почему они должны писать тесты? Всех согласных и несогласных прошу проследовать внутрь поста, где я вам наглядно покажу, что юнит (и интеграционные) тесты – великое зло!

Шон Престридж – старший инженер по применению (FAE), руководитель группы FAE американского подразделения IAR Systems – в статье «Move fast and break things? Not so fast in embedded», рассказывает о специфике разработки программного обеспечения для встраиваемых систем, уделяя особое внимание вопросам качества кода и тестирования.

«Двигайся быстрее и ломай преграды» — это подход, озвученный Марком Цукербергом, который он внедряет в культуру разработки Facebook. Несмотря на то, что он чудесно звучит, когда мы говорим о быстром создании и запуске новых функций (даже если они не идеальны), все же он теряет свою красоту, если попытаться применить его к разработке программного обеспечения для встраиваемых систем.

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

Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.

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

Тестов много не бывает. И речь идёт не только о наращивании их количества (что само по себе, конечно, тоже хорошо) — речь идёт о разнообразии самих видов тестов. Даже не напрягая воображение можно вспомнить несколько способов протестировать ваше приложение: Unit-тесты, интеграционные тесты, API-тесты, системные тесты… и это не вспоминая о том, что тесты ещё бывают функциональными, нагрузочными, направленными на отказоустойчивость...

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

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

Я часто собеседую кандидатов на позиции .Net разработчиков в Retail Rocket. В прошлом работал в компаниях с различными командами. И далеко не один раз встречал и продолжаю встречать мнение, что “автотесты хорошо, но на них нет времени, писать их дорого, тестировать должны тестировщики”. Такое мнение не у всех, но встречается нередко (не исключаю, что мне так «везет»). В связи с этим хочу поделиться нашим подходом к автоматическому тестированию и обеспечению качества. Расскажу путь, который мы в Retail Rocket прошли за последние 3-4 года, к чему пришли сейчас, и —  главное — что дают нам автотесты и для чего мы их пишем. Надеюсь, статья кого-нибудь сподвигнет писать автотесты, кого-то — писать больше автотестов, а кому-то, возможно, поможет избежать ошибок, с которыми мы сталкивались.

Если Вы разрабатываете более-менее сложный программный продукт, то Вам должна быть знакома ситуация, когда системные (end-to-end) тесты по тем или иным причинам автоматизировать не удаётся. На это могут быть разные причины, я приведу несколько примеров:

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

Эти и многие другие ситуации приводят к худшему кошмару любого разработчика — ручному тестированию. Самое неприятное заключается в том, что нельзя провести тестирование один раз и забыть о нём. Нет, нам приходится перед каждым релизом (а может и чаще) раскатывать виртуалки, устанавливать туда тестируемое приложение и тыкать по кнопкам снова и снова, чтобы убедиться, что мы не словили регрессию.

Если Вы ищете решение этой проблемы — то прошу под кат.