Привет, Хабр! Я учусь в Российско-Таджикском Славянском университете, собственно у нас в университете действует так называемая кредитно-бальная система.
Для просмотра количества набранных баллов и так далее, у нас есть приложение которое было разработано университетом.
Оно доступно для Android.
Однажды в мое поле зрения попал проект заказной разработки, который команда безуспешно пыталась сдать в течение двух лет. Полностью сдано было около 5% проекта, однако дальнейшая сдача заканчивалась неудачами то на стадии приемки функционала заказчиком, то на стадии внутреннего тестирования, то разработчики срывали сроки при внесении изменений в код.
За время проекта два раза поменяли команду и заказчика.
Аудит процесса производства с точки зрения time2market показал, что: долго вносятся изменения в код, долго выполняется ручное тестирование и часто после тестирования код возвращается на доработку
Первопричиной низкого time2market являлось то, что команда не владела практикой coding kata, о которой я подробно расскажу в данной статье на примере задачи "Позолоченная роза".
После применения приемов, описанных в этой статье, оставшиеся 95% проекта команда реализовала и сдала за 6 месяцев вместо прогнозируемых 48 лет, что эквивалентно сокращению time2market в 96 раз.
Blade Runner 2049, Warner Bros. Pictures
Я видел не во сне, а наяву атакующие корабли, пылающие под четырьмя вложенными if-else, и лучи CI с кучей сканирований у ворот Тангейзера, вызывающие лютую боль разработчиков. Меня зовут Максим Морев, и я техлид в Газпромбанке.
То, что вы сейчас увидите, выросло из внутреннего стайлгайда, к которому мы пришли через тернии многочисленных код-ревью и разработанных сервисов. Я постарался собрать здесь все основные и просто интересные грабли, которые нам попадались, и показать решения с примерами и обзором возможных трудностей в процессе внедрения.
В рамках проекта цифровой модернизации для одного из наших клиентов возникла задача миграции данных из одной модели хранения в другую. Для тестирования такого решения мы обратились к BDD практикам и виртуализации зависимостей с помощью контейнеров. В данном посте мы рассмотрим как можно организовать тестирование подобного решения с помощью pytest-bdd и testcontainers на python.
Думаю, большинство читателей согласится, что автоматизированное тестирование - полезный, а во многих областях даже необходимый, этап создания программ. А так как программисты - народ ленивый, то и инструментов, облегчающих этот этап существует немало. Одним из таких инструментов является AutoFixture - средство для генерации тестовых экземпляров. Этот инструмент уже не раз упомянался на Хабре, например тут. Далее я расскажу о том, с какой проблемой столкнулся в попытке применить AutoFixture в своей работе и как решил эту проблему.
В этом тексте перечислены основные способы отлаживать и диагностировать проекты на микроконтроллерах.
Для аналогии буду каждому методу отладки метафорично приводить в соответствие аналогию из медицины.
Сегодня я расскажу тебе, достойна ли книга Роберта Мартина “Идеальный программист” внимания. Стоит ли её читать, если ты уже опытный программист, прошедший большой путь и многое познавший? А если ты только начинаешь свою нелегкую дорогу в мир разработки? Быть может ты находишься где-то по середине и не знаешь, как дальше развиваться? Может ты вообще до этого не читал никакой технической литературы и боишься к ней подступиться? На все эти вопросы ты найдешь ответ в этой краткой статье.
В этой статье я покажу, как писать более читабельные и выразительные юнит-тесты. И почувствовать себя писателем красивого произведения, а не скучного, тяжело понятного кода.
? Доступна также видео версия данной статьи.
Привет! Меня зовут Владислав Сединкин, я работаю iOS-разработчиком в СберМаркете. Сегодня я расскажу, как мы проводим юнит-тестирование, с какими сложностями сталкивались при написании тестов и как их решали.
Я выступал с этим докладом на iOS Meetup | СберМаркет Tech, здесь его сжатая версия.
Привет, в данном посте вы найдете перевод статьи 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 кажется многим безумной. Но давайте вспомним все предыдущие достижения Бека — и заметим, что многие из них тоже когда-то казались людям совершенно непрактичными, а потом оказались очень осмысленными.
