Привет, Хабр! На связи участница профессионального сообщества NTA Александра Грушина.
Поговорим о важности написания тестов к своему коду, о магии подхода test-driven development. Я расскажу о своём пути: от первого знакомства с концепцией TDD до умелого использования инструментов тестирования на Java (Junit 5 + Mockito).
Привет, Хабр! Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кейсом, как Test Driven Development помогает мне разрабатывать мою RTS игру.
Время от времени необходимо пересматривать свои методы TDD и напоминать себе, каких моделей поведения следует избегать.
Процесс TDD концептуально прост, но по мере его выполнения вы обнаружите, что он бросает вызов вашим навыкам проектирования. Не путайте это с тем, что TDD - это сложно, сложно именно проектирование!
В этой статье приводится ряд антипаттернов TDD и тестирования, а также способы их устранения.
Преимущество программного обеспечения заключается в том, что оно может изменяться. Именно поэтому его называют "soft" обеспечение - оно более податливо, чем аппаратное обеспечение. Отличная команда инженеров должна быть замечательным активом компании, создавая системы, которые могут развиваться вместе с бизнесом, чтобы продолжать приносить пользу.
Так почему же мы так плохо справляемся с этой задачей? Сколько проектов, о которых вы слышали, полностью проваливаются? Или становятся "наследием", и их приходится полностью переписывать (и переписывать тоже часто неудачно!).
Как вообще происходит "отказ" программной системы? Разве ее нельзя просто менять до тех пор, пока она не станет правильной? Именно это нам и обещают!
Многие люди выбирают Go для создания систем, потому что в нем сделан ряд решений, которые, как можно надеяться, сделают его более устойчивым к наследию.
Эта глава является продолжением главы "Введение в приёмочные тесты". Готовый код этой главы можно найти на GitHub.
Приёмочные тесты очень важны, они напрямую влияют на вашу способность уверенно развивать систему с течением времени при разумной стоимости изменений.
Кроме того, они являются прекрасным инструментом для работы с устаревшим кодом. Если вы столкнулись с плохой кодовой базой без тестов, не поддавайтесь искушению начать рефакторинг. Вместо этого напишите несколько приёмочных тестов, которые позволят вам свободно изменять внутреннее устройство системы, не затрагивая её функциональное внешнее поведение. Приёмочные тесты не должны заботиться о внутреннем качестве, поэтому они отлично подходят для таких ситуаций.
Прочитав эту статью, вы поймете, что приёмочные тесты полезны для верификации, а также могут быть использованы в процессе разработки, помогая нам изменять систему более обдуманно и методично, сокращая напрасные усилия.
Сегодня речь пойдет про тесты… Про юнит-тесты. Думаю, что почти все слышали про юнит-тесты, пробовали их писать, и, возможно бросали это «гиблое дело» как только сталкивались с непониманием того, что тестировать на фронтенде.
Дизайн превью: Марина Четвертакова
Тесты, как в случае с цементированием стали, могут упрочнить код, а могут как в случае железобетона создать прочную громоздкую конструкцию, с которой ничего уже нельзя будет сделать, только "демонтировать" или приделать "пристройку".
Хочу поделиться своим подходом по тестированию бизнес логики реализованной с помощью библиотеки 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% под нашу компанию. Давайте рассмотрим, как выглядит профиль.
