Сегодня речь пойдет про тесты… Про юнит-тесты. Думаю, что почти все слышали про юнит-тесты, пробовали их писать, и, возможно бросали это «гиблое дело» как только сталкивались с непониманием того, что тестировать на фронтенде.
Дизайн превью: Марина Четвертакова
Тесты, как в случае с цементированием стали, могут упрочнить код, а могут как в случае железобетона создать прочную громоздкую конструкцию, с которой ничего уже нельзя будет сделать, только "демонтировать" или приделать "пристройку".
Хочу поделиться своим подходом по тестированию бизнес логики реализованной с помощью библиотеки MediatR. Тесты пишутся вперёд реализации, причём слой тестов достаточно тонкий, чтобы не заблокировать возможный рефакторинг.
Привет, Хабр! Я учусь в Российско-Таджикском Славянском университете, собственно у нас в университете действует так называемая кредитно-бальная система.
Для просмотра количества набранных баллов и так далее, у нас есть приложение которое было разработано университетом.
Оно доступно для 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 Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.
Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.
