Привет, в данном посте вы найдете перевод статьи Mangabo Kolawole, в которой пойдет речь о Test-Driven Development. Мы создадим крайне простое приложение на React по всем правилам TDD.
Первое правило Test-Driven Development (TDD) – это написание тестов перед написанием кода. Это звучит более интуитивно, когда мы говорим о разработке для бэкенда, если честно, но работает ли данная схема для фронтенда, в частности для React, что же, посмотрим.
Каждый разработчик рано или поздно сталкивается с необходимостью повторного использования собственного кода. В проектах PHP для этих целей создаются пакеты, устанавливаемые с помощью Composer. При этом пакеты могут быть абстрагированы от каких-либо фреймворков, либо могут быть предназначены для использования в конкретном PHP-фреймворке. В данной статье рассказывается о том, как создать PHP-пакеты для фреймворка Laravel, но материал будет полезен и тем, кто собирается разрабатывать любые другие PHP-пакеты (как публичные, так и приватные).
Для лучшего понимания данного материала рекомендуется ознакомиться с разделом о разработке пакетов в официальной документации Laravel. А для более детального изучения темы будет полезен данный ресурс.
Данная статья в большей мере ориентирована на начинающих разработчиков.
Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.
Это следующие причины:
● Рост группы тестирования. Появилась необходимость в установке целей в любой момент года, а не только 1 раз в начале каждого квартала.
● Не всегда было очевидно, какие пробелы в знаниях и опыте есть у сотрудника.
● Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.
Все эти проблемы помог решить переход к практике построения целей на основе профиля тестировщика. Другое название для профиля — матрица компетенций. Профиль позволяет оценить свой уровень знаний и опыта по большому количеству разнообразных навыков, которые нужны в тестировании. На основе списка этих навыков и оценок удобно планировать цели по развитию.
Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.
Тестирование программного обеспечения – одно из быстроразвивающихся направлений, которое пользуется большим спросом в IT-сфере. Тестировщикам открыты возможности от тестирования работы внутренних систем сложных платформ до тестирования мобильных приложений или сайтов.
Я всегда говорю: “Тестировщиком может стать любой”. Всё зависит от мотивации, исходной базы знаний и скорости восприятия информации. Если вы решите выбрать тестирование как профессию, то сможете повысить свои компетенции в разных сферах, выбрав подходящее направление для роста.
В IT-сфере существуют стереотипы насчет профессии тестировщика. Многие стереотипы сильно обобщены и не имеют под собой основы. Я – Илюся Усманова, старший инженер по тестированию. На 4 курсе университета я ещё не знала, чем именно в IT буду заниматься. Но мои глаза загорелись, как только начался курс по тестированию. Я поняла, что делать качественное ПО для меня интереснее, чем писать код и общаться с заказчиками. В роли QA я уже 7 лет, и за это время сталкивалась с разными мнениями как внутри команды, так и в сообществах тестировщиков. Давайте рассмотрим самые популярные из них.
При написании тестов мы сравниваем данные, возвращаемые тестируемой функцией, с их ожидаемыми значениями. Действительные значения мы получаем из результата вызова функции, а ожидаемые значение традиционно указываем в коде теста. Зачастую ожидаемое значение является массивом, а иногда очень большим массивом. Кроме того, тестируемая функция может требовать большой массив данных в качестве входного параметра. И все эти большие массивы должны так или иначе присутствовать в коде теста.
Так, при разработке API нашей команде довелось сверять в тестах многомерные массивы, которые занимают несколько экранов. Наличие этих массивов в коде теста сделало бы разработку и чтение тестов крайне неудобными, поэтому появилась необходимость вынести тестовые данные из кода теста. При этом вынести их надо недалеко от самого теста, чтобы разработчику было удобно просматривать и редактировать эти данные.
В результате был написан скрипт, который позволяет извлекать массивы данных из php-файлов, а также из обычных текстовых файлов, и подставлять эти данные в код теста. Позже этот скрипт был оформлен в php-пакет test-data-provider.
Привет, Хабр!
В октябре мы провели онлайн-митап по тестированию, в котором спикеры из Badoo, Skillbox, Почтатех и SuperJob поговорили о своем опыте перехода от ручного тестирования к автоматизации, рассказали о подходах к стабилизации тестов для мобильных приложений и многом другом. Встречу посетили более 600 участников, а QA Lead SuperJob Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.
Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.
Эта статья является переводом материала «TDD: What went wrong or did it?».
В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (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, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
