Привет, в данном посте вы найдете перевод статьи Mangabo Kolawole, в которой пойдет речь о Test-Driven Development. Мы создадим крайне простое приложение на React по всем правилам TDD.
Первое правило Test-Driven Development (TDD) – это написание тестов перед написанием кода. Это звучит более интуитивно, когда мы говорим о разработке для бэкенда, если честно, но работает ли данная схема для фронтенда, в частности для React, что же, посмотрим.
TDD *
Разработка через тестирование
Новости
Laravel: разработка пакетов
Каждый разработчик рано или поздно сталкивается с необходимостью повторного использования собственного кода. В проектах PHP для этих целей создаются пакеты, устанавливаемые с помощью Composer. При этом пакеты могут быть абстрагированы от каких-либо фреймворков, либо могут быть предназначены для использования в конкретном PHP-фреймворке. В данной статье рассказывается о том, как создать PHP-пакеты для фреймворка Laravel, но материал будет полезен и тем, кто собирается разрабатывать любые другие PHP-пакеты (как публичные, так и приватные).
Для лучшего понимания данного материала рекомендуется ознакомиться с разделом о разработке пакетов в официальной документации Laravel. А для более детального изучения темы будет полезен данный ресурс.
Данная статья в большей мере ориентирована на начинающих разработчиков.
Практика обучения в QA отделе. Профиль тестировщика
Добрый день! Я – Елена Поплоухина, руководитель группы тестирования в компании Usetech. В предыдущей статье я рассказывала про опыт построения обучения в группе тестирования на основе практики квартальных целей. 3,5 года мы пользовались этим подходом, но в итоге решили всё переделать. Почему так получилось? Для этого было несколько причин, и о них я расскажу в этой статье.
Это следующие причины:
● Рост группы тестирования. Появилась необходимость в установке целей в любой момент года, а не только 1 раз в начале каждого квартала.
● Не всегда было очевидно, какие пробелы в знаниях и опыте есть у сотрудника.
● Периодически не устраивал период выполнения цели в 3 месяца. На квартал могли выпадать и новогодние праздники, и отпуск сотрудника. В таком случае времени на выполнение цели не хватало. Требовалось варьировать период выполнения целей с учётом как их сложности, так и других факторов.
Все эти проблемы помог решить переход к практике построения целей на основе профиля тестировщика. Другое название для профиля — матрица компетенций. Профиль позволяет оценить свой уровень знаний и опыта по большому количеству разнообразных навыков, которые нужны в тестировании. На основе списка этих навыков и оценок удобно планировать цели по развитию.
Базовая версия профиля тестировщика была получена нами на одном из курсов по тест-менеджменту и переработана на 50% под нашу компанию. Давайте рассмотрим, как выглядит профиль.
TEGRUS подтверждает, что корпоративная почта Mailion выдерживает нагрузку в 600 тысяч пользователей
В ноябре прошлого года МойОфис представила корпоративную почту нового поколения Mailion, разработанную при грантовой поддержке РФРИТ. Это тиражируемое решение для крупных организаций, которое разворачивается на собственных серверах клиента или на базе инфраструктуры доверенного партнера. Благодаря Cloud Native микросервисной архитектуре Mailion гарантирует высокую отказоустойчивость, быстрое самовосстановление и масштабируемость в период колебания нагрузок.
Инженеры компании TEGRUS, российского системного интегратора полного цикла, провели нагрузочное тестирование почты Mailion и подтвердили её применимость в структурах с 600 тысячами пользователей. В ходе тестирования проверялась корректность исполнения сценариев нагрузки, которые эмулируют рабочий день организации и описывают типовое поведение сотрудников крупного предприятия при работе с электронной почтой.
О том, как проходило тестирование и какие результаты мы получили — читайте под катом.
8 стереотипов, с которыми сталкиваются тестировщики
Тестирование программного обеспечения – одно из быстроразвивающихся направлений, которое пользуется большим спросом в IT-сфере. Тестировщикам открыты возможности от тестирования работы внутренних систем сложных платформ до тестирования мобильных приложений или сайтов.
Я всегда говорю: “Тестировщиком может стать любой”. Всё зависит от мотивации, исходной базы знаний и скорости восприятия информации. Если вы решите выбрать тестирование как профессию, то сможете повысить свои компетенции в разных сферах, выбрав подходящее направление для роста.
В IT-сфере существуют стереотипы насчет профессии тестировщика. Многие стереотипы сильно обобщены и не имеют под собой основы. Я – Илюся Усманова, старший инженер по тестированию. На 4 курсе университета я ещё не знала, чем именно в IT буду заниматься. Но мои глаза загорелись, как только начался курс по тестированию. Я поняла, что делать качественное ПО для меня интереснее, чем писать код и общаться с заказчиками. В роли QA я уже 7 лет, и за это время сталкивалась с разными мнениями как внутри команды, так и в сообществах тестировщиков. Давайте рассмотрим самые популярные из них.
Организация PHP-тестов с большими массивами данных
При написании тестов мы сравниваем данные, возвращаемые тестируемой функцией, с их ожидаемыми значениями. Действительные значения мы получаем из результата вызова функции, а ожидаемые значение традиционно указываем в коде теста. Зачастую ожидаемое значение является массивом, а иногда очень большим массивом. Кроме того, тестируемая функция может требовать большой массив данных в качестве входного параметра. И все эти большие массивы должны так или иначе присутствовать в коде теста.
Так, при разработке API нашей команде довелось сверять в тестах многомерные массивы, которые занимают несколько экранов. Наличие этих массивов в коде теста сделало бы разработку и чтение тестов крайне неудобными, поэтому появилась необходимость вынести тестовые данные из кода теста. При этом вынести их надо недалеко от самого теста, чтобы разработчику было удобно просматривать и редактировать эти данные.
В результате был написан скрипт, который позволяет извлекать массивы данных из php-файлов, а также из обычных текстовых файлов, и подставлять эти данные в код теста. Позже этот скрипт был оформлен в php-пакет test-data-provider.
Практика обучения в QA отделе. Квартальные цели
О личном опыте в обучении тестировщиков и использовании SMART
Какие тесты выбрать для облака? Сравниваем варианты
Q&A по QA: разбираем вопросы митапа по автоматизации тестирования
Привет, Хабр!
В октябре мы провели онлайн-митап по тестированию, в котором спикеры из Badoo, Skillbox, Почтатех и SuperJob поговорили о своем опыте перехода от ручного тестирования к автоматизации, рассказали о подходах к стабилизации тестов для мобильных приложений и многом другом. Встречу посетили более 600 участников, а QA Lead SuperJob Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.
Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.
TDD: Что пошло не так?
Эта статья является переводом материала «TDD: What went wrong or did it?».
В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).
Как это возможно, что одна и та же техника, которая так выгодна для стольких разработчиков, так губительна для других? В этой статье Владислав Кононов расскажет о трех заблуждениях, которые могли бы объяснить это явление.
Кент Бек: отец экстремального программирования, паттернов проектирования, JUnit и TDD
Кент Бек сделал для IT столько, что его имя упоминается на Хабре в сотнях разных постов. Но при этом до сих пор не было хабрапоста о нём самом. Исправим это упущение.
Во вторник Кент выступит на нашей онлайн-конференции по тестированию Heisenbug. Там этот человек, когда-то популяризовавший подход TDD, поговорит о куда более новой концепции TCR («Test && Commit || Revert»). То есть даже к 60 годам он не стал жить былыми заслугами, а продолжает предлагать новое.
Идея TCR кажется многим безумной. Но давайте вспомним все предыдущие достижения Бека — и заметим, что многие из них тоже когда-то казались людям совершенно непрактичными, а потом оказались очень осмысленными.
Путь к автоматизации тестирования в SuperJob: инструменты, проблемы и решения
Привет, Хабр! Меня зовут Антон Шкредов, я QA Lead в SuperJob. В День тестировщика хочу поделиться историей о том, как около четырех лет назад мы с командой перешли от ручного тестирования к автоматизации UI и какой профит в итоге получили. Внутри подробности про усталость от ручных тестов, с чего начали автоматизацию, какие инструменты использовали, а также про сложности и бонусы от внедрения.
Record-and-Replay тестирование — сочетание достоинств юнит и интеграционных тестов
Вступление
Привет, Хабр. Сегодня я расскажу вам про Record-and-Replay подход к тестированию т. к. я его понимаю. Оговорка про мое понимание не случайна. Про этот подход не так много общедоступных материалов, чтобы иметь некий common agreement относительно значения этого термина. Многое из того, что я опишу, является моими личными оригинальными находками, но, тем не менее, фраза record-and-replay, на мой взгляд, наилучшим образом описывает применяемые мной решения. Так что я буду использовать именно ее.
Чтобы было проще понять, какие проблемы решает RnR, в ходе этого разговора мы сначала обсудим некоторые другие подходы к написанию тестов (юнит-тестирование, интеграционное тестирование и т. д.). И отталкиваясь от их недостатков перейдем к варианту с RnR, я расскажу, что же это собственно такое, как это работает, и каким образом решает озвученные ранее проблемы. Поговорим про подводные камни, которые могут свести пользу от внедрения всего этого дела к нулю. Ну и, конечно, обсудим недостатки или границы применимости этого подхода.
Примеры кода в статье на Java, но язык простой, так что на чем бы вы не программировали, у вас вряд ли возникнут проблемы с их пониманием. Тем более что они несут больше иллюстративную функцию. Сама философия статьи применима ко многим стэкам.
Ключевой постулат
Итак без лишних предисловий к ключевой идее статьи. В ней будет немало оценочных суждений, и думаю необходимо сразу сказать, в свете какой идеи я делаю эти оценки. Итак… Ключевой постулат - «Ресурсы на тестирование ограничены».
Правильное TDD
Привет, Хабр! На написание этого поста меня вдохновил другой пост TDD есть опиум для народа, где обсуждаются спорные моменты в подходе TDD и в принципе делается вывод о его несостоятельности (хотя и признается необходимость тестов в любом случае). С автором я был полностью согласен... раньше, пока не понимал действительную суть TDD. Поэтому, я счел своим долгом рассказать суть Test Driven Development от лица человека, который пробовал писать тесты до реализации, разочаровался из-за сложностей, и только через некоторое время, уловив основную мысль, увидевшего новые возможности в разработке через тестирование.
Замечание: я всего лишь junior, и опыта разработки у меня не так много. Но надеюсь, что мне удастся донести мысль до читателя, а ошибки помогут исправить в комментариях. Примеры будут на Kotlin, мне кажется, это не должно стать помехой, язык достаточно хорошо читаемый. Несмотря на довод о слишком упрощенных примерах (наподобие калькулятора) в оригинальной статье, здесь я также не иду в дебри реальных повседневных задач, ограничиваясь кустарным примером. Да простит меня читатель, я не хочу заставлять сильно вникать в код, хочу просто объяснить идею.
TDD есть опиум для народа. Так ли хороша технология, как ее описывают адепты?
Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.
Реализация алгоритма Минимакс на примере игры «Крестики-Нолики»
Для того чтобы сделать игру непобедимой, было необходимо создать алгоритм, который может рассчитать все возможные ходы для «компьютерного» игрока. Далее, нужно использовать некоторую метрику, чтобы определить, какой ход является предпочтительным. После долгих исследований стало понятно, что алгоритм Минимакс, был тем, что мне нужно.
Понимание основ алгоритма и реализация игры заняли некоторое время. Я нашел много примеров кода и объяснений, тем не менее это оказалось не такой уж простой затеей. Надеюсь этот пост поможет некоторым из читателей оценить элегантность этого алгоритма.
Может ли автоматизированное тестирование заменить ручное?
Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.
Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.
Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.
Retrofit: удобные разработка и тестирование API
Если вы занимались крупными Java-проектами, то вы, наверное, помните старый добрый WSDL (Web Services Description Language, язык описания веб-сервисов), за которым стоят IBM и Microsoft. WSDL — это язык описания веб-сервисов, основанный на XML. А, может, вы всё ещё пользуетесь этим языком? WSDL и его брат-близнец — язык XML Schema, относятся к тем стандартам W3C, которые являются излюбленным объектом ненависти бывалых программистов. Файлы спецификаций WSDL не особенно легко читать людям, а об удобстве их ручного составления лучше и не говорить. Но, к счастью, работать с подобными файлами вручную и не нужно. Они могут быть сгенерированы конечной точкой сервера и переданы прямо в кодогенератор для создания объектов переноса данных (DTO, Data Transfer Object) и стабов сервиса.
Почему большинство юнит тестов — пустая трата времени? (перевод статьи)
Перевод статьи "Why most unit testing is waste?"
Автор: James O Coplien, Перевод: Епишев Александр
1.1 Наши дни
Во времена FORTRAN, когда функция была функцией, иногда заслуживающей функциональных проверок, юнит-тестирование было одним из главных составляющих. Компьютеры производили вычисления, в то время как функции и процедуры представляли собой вычислительные блоки. В те времена доминирующий подход в дизайне предполагал создание комплексной внешней функциональности из более мелких кусков, которые, в свою очередь управляли еще более мелкими, и так далее, вплоть до уровня хорошо понятных примитивов. Каждый слой поддерживал находящийся над ним слой. В целом, у вас были большие шансы отследить, как функциональность на самом дне, так называемые функции и процедуры, были связаны с требованиями, выраженными в доступном человеку интерфейсе. Можно было рассчитывать, что хороший дизайнер поймет бизнес цель той или иной функции. Такими же возможными для понимания были и взаимосвязи в дереве вызовов, как минимум в хорошо структурированном коде. Вы могли мысленно смоделировать выполнение кода во время код-ревью.
Пишем unit тесты так, чтобы не было мучительно больно
Любую задачу в программировании можно выполнить массой разных способов, и не все они одинаково полезны. Хочу рассказать о том, как можно накосячить при написании модульных тестов. Я пишу мобильные приложения уже 6 лет, и в моем «багаже» много разных кейсов. Уверен, что кому-то будет полезно.
Вклад авторов
-
asolntsev 303.2 -
tangro 148.0 -
sody 96.0 -
BurundukXP 77.4 -
AlexanderByndyu 69.0 -
Unrul 59.0 -
Tiendil 56.0 -
Igmat 53.0 -
headfire 53.0 -
ETman 52.0