Привет, Хабр! Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.
В статье поделимся опытом работы с техдолгом. Сначала определим, что это, затем подумаем, как решать. Пишите в комментариях свой опыт — подискутируем.
Мы покрываем код тестами, когда хотим быть уверенными, что в негативных сценариях он сработает надёжно. Хочется, чтобы тесты были не бланковой заглушкой, а полезной нагрузкой, которая позволит считать, что наше поведение достаточно валидное. Так мы можем обеспечить корректное взаимодействие системы с пользователем.
Меня зовут Максим Вишневский, я Senior Frontend-разработчик в Циан. В этой статье поделюсь историей, как наша команда реформировала подходы к тестированию: как мы отказались от 100% покрытия и unit-тестов, чем их заменили и какой получили результат. Поговорим о проблемах с Enzyme, пользе Playwright, мокинге данных для бэка и взаимодействии с QA.
Если вы задумывались, какие практики использовать, чтобы писать код на Go быстро и качественно, этот материал для вас. Руководитель группы разработки подсистем Геннадий Ковалев и эксперт по разработке ПО Даниил Подольский обсуждают пять способов повысить эффективность разработки в команде Go-программистов: они расскажут, как называть переменные, составлять документацию и продумывать архитектуру так, чтобы специалистам в команде и смежных отделах было легко работать с написанным кодом.
Статья будет полезна начинающим специалистам и командам, которые недавно работают вместе. Опытных разработчиков приглашаем в комментарии — расскажите, какие практики для повышения эффективности кода используете вы.
А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код.
Ниже описаны основы использования OCUnit — фреймворка для создания юнит-тестов, интегрированного в Xcode. Чтобы наглядно попробовать описываемые вещи, код можно скачать сразу. Писал до эпохи Xcode 4, поэтому картинки немного устарели.
Полгода назад на моем проекте было примерно около 0% покрытие кода юнит-тестами. Простых классов было достаточно мало, создавать для них юнит-тесты было легко, но это было относительно бесполезно, так как на самом деле важные алгоритмы находились в сложных классах. А сложные, с точки зрения поведения, классы было трудно юнит-тестировать так как такие классы были завязаны на другие сложные классы и классы конфигурации. Создать объект сложного класса и тем более его протестировать юнит-тестами было невозможно.
Некоторое время назад я прочёл "Writing Testable Code" в Google Testing Blog .
Ключевая идея в статье заключается в том, что C++ код, пригодный для юнит-тестирования, пишется совсем не так, как привычный C++ код.
Довольно часто при обсуждении средств статического анализа для C# проектов программисты пишут о том, что в этом нет необходимости, потому что с помощью юнит-тестирования они отлавливают большинство ошибок. Я решил проверить, насколько хорошо протестирован один из самых известных юнит-тест фреймворков — NUnit, и посмотреть найдёт ли там что-нибудь наш анализатор.
Будучи консультантом по тестированию, я за годы работы прочитал массу статей по QA. Большинство из них — это в какой-то степени полезные, но часто случайные материалы, которые не всегда стоят времени. Но иногда я натыкался на удивительно хорошие статьи, которые действительно могут помочь улучшить навыки написания тестов. Я отобрал эти статьи и написал к ним аннотации. Половина из них относится непосредственно к JavaScript / Node.js, вторая половина охватывает общие концепции тестирования, которые применимы в любом языке.
Привет! Меня зовут Сергей, я работаю фронтенд-разработчиком в Тинькофф на одном из внутренних приложений в направлении Compliance. Последние полгода я активно занимался повышением стабильности и качества продукта, в том числе увеличивал покрытие приложения юнит-тестами. За это время я написал более 500 юнит-тестов, а тестовое покрытие удалось увеличить примерно на 30% с учетом того, что бизнес-задачи продолжали выполняться. В ходе работы над тестами я получил новый опыт и пришел к интересным выводам, которыми хочу поделиться с вами.
Для тестирования Java-приложений создано столько полезных инструментов, что в них немудрено запутаться. Вместе с тем с помощью каждого из них можно решить строго определенный круг прикладных задач. Меня зовут Константин Шибков, я старший Java-разработчик CDEK и программный директор курсов по Java в Skillbox. Сегодня расскажу о практике использования фреймворка для модульного тестирования JUnit 5, а также покажу на конкретных примерах, как проводятся стандартные юнит-тесты и параметризованные тесты. Вы сможете самостоятельно повторить их, воспользовавшись подготовленным репозиторием с готовыми примерами тестов на Java.
Ура! Наконец-то вы написали столько строк кода, что можете позволить себе дом на берегу моря. Вы нанимаете лучшего архитектора, который уверяет, что у него появилась отличная идея по поводу вашего дома.
И вот вы приезжаете на торжественное открытие, и что вы видите? Ваш новый дом представляет собой внушительную пятиэтажную громадину из стали, бетона и стекла. Вы проходите через вращающиеся двери, и на роскошном мраморном полу остается песок. Внутри обнаруживаете стойку администратора, за которой находится лифт. Наверху — спальня и три гостевые комнаты в виде смежных офисных кабинок.
Часто разработчики программного обеспечения подходят к юнит-тестированию с подобным ошибочным мышлением. Они механически применяют все «правила» и лучшие практики, которые они усвоили из опыта написания продакшен кода, не проверяя, подходят ли они для написания тестов. В результате они строят небоскребы на пляже. О причинах этого явления и главное, как это изменить, в этой статье.
Продакшен код может быть неидеальным, и это подразумевает риск или долг, которым команды управляют различными способами. Для кода тестов риск гораздо более значителен — они могут просто исчезнуть. Сотни часов кодирования и встреч могут просто пропасть.
Вы сталкивались с подобным?
В этой статье мы поговорим о том, как сократить время, затрачиваемое на решение проблемы сложности тестов — важной составляющей стратегии тестирования.
