Представьте себе: вы отлаживаете новый баг в сложном многослойном приложении (например, на Spring). Чтобы воспроизвести проблему, приходится взаимодействовать со всей системой end-to-end: отправлять запрос на эндпоинт или что-то кликать в UI. Юнит-теста, который бы изолировал нежелательное поведение до уровня злополучного сервиса или утилиты, нет. А хотелось бы, чтобы он был: во-первых, воспроизводить баг было бы проще (особенно если UI кликает QA, а не вы), а во-вторых, его потом можно было бы легко превратить в регрессионный и улучшить стабильность системы.
Рубрика «юнит-тесты»
Не LLM едиными: генерируем юнит-тесты из реального исполнения на лету
2025-09-17 в 12:54, admin, рубрики: explyt, IntellijIDEA, java, kotlin, llm, spring, автоматизация тестирования, интеграционные тесты, тестирование веб-приложений, юнит-тестыГенерация юнит-тестов с LLM: если бы посуда мылась сама
2025-06-24 в 15:14, admin, рубрики: llm, юнит-тесты
Грязный код
2024-12-09 в 13:01, admin, рубрики: htmx, ruvds_переводы, интеграционные тесты, принцип единой ответственности, чистый код, юнит-тесты
«Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code
В этом эссе я хочу рассказать о том, как пишу код. Я буду называть свою методику «грязным кодом», потому что часто нарушаю рекомендации «чистого кода» — популярной концепции написания кода.
Вообще, я на самом деле не считаю свой код абсолютно грязным: местами он немного уродлив, но по большей части я им доволен, и он достаточно прост в поддержке, обеспечивая при этом разумные уровни качества.
Кроме того, я не пытаюсь своим эссе убедить вас писать грязный код. Скорее, я хочу показать, что таким способом можно писать достаточно успешное ПО, и, надеюсь обеспечить некий баланс в обсуждениях методологий разработки ПО.
Я программирую уже довольно давно и видел разнообразные подходы к обеспечению работоспособности ПО. Кто-то любит объектно-ориентированное программирование (я тоже), другие умные люди его ненавидят. Кому-то нравится выразительность динамических языков, кого-то она бесит. Кто-то успешно выпускает программы, строго следуя концепции Test Driven Development, другие добавляют в конце проекта несколько сквозных тестов, а многие остаются где-то посередине этих крайних точек.
Я был свидетелем проектов, выпускавших и поддерживавших успешное ПО на основе всех этих разнообразных подходов.
Поэтому повторюсь, что моя цель не убедить вас, что мой способ кодинга единственно возможный, а показать вам (и в особенности начинающим разработчикам, которых легко запугать терминами наподобие «чистого кода»), что можно иметь успешную карьеру программиста, пользуясь множеством различных подходов, и что мой — один из них. Читать полностью »
Как писать качественные unit-тесты: процент покрытия, мутанты и работа с моками
2024-10-30 в 5:15, admin, рубрики: golang, gomock, qa, testing, качество, моки, мутационное тестирование, юнит-тестыПривет! Меня зовут Марина, я Backend-инженер в компании Авито. Сегодня я хочу поделиться собственными рекомендациями, к которым удалось прийти при работе над качеством тестового покрытия сервисов нашей команды.
Итак, дело было давным-давно, у нас было пять сервисов, около 70% покрытия, интеграционные тесты... и всё равно баги оставались неуловимыми. Шутка, конечно, все куда проще. Процент покрытия и правда выглядел неплохо, но почему тогда мы решили что-то менять?
В чём подвох процента покрытия?
TDD: Что пошло не так?
2021-10-31 в 7:00, admin, рубрики: tdd, автоматическое тестирование, Анализ и проектирование систем, Программирование, Проектирование и рефакторинг, Тестирование IT-систем, юнит-тестирование, юнит-тестыЭта статья является переводом материала «TDD: What went wrong or did it?».
В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).
Record-and-Replay тестирование — сочетание достоинств юнит и интеграционных тестов
2021-08-22 в 12:10, admin, рубрики: java, mockito, tdd, wiremock, интеграционное тестирование, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, тесты, юнит-тесты
Юнит-тесты переоценены
2020-07-13 в 8:02, admin, рубрики: Блог компании QIWI, Программирование, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, управление разработкой, юнит-тестыПредлагаем вам перевод поста «Unit Testing is Overrated» от Alex Golub, чтобы подискутировать на тему юнит-тестов. Действительно ли они переоценены, как считает автор, или же являются отличным подспорьем в работе? Опрос — в конце поста
Результаты использования юнит-тестов: отчаяние, мучения, гнев
Важность тестирования в современной разработке ПО сложно переоценить. Для создания успешного продукта недостаточно выпустить его и сразу забыть, это долгий итеративный процесс. После изменения каждой строки кода программа должна сохранять свою функциональность, что подразумевает необходимость тщательного тестирования.
В процессе развития отрасли разработки ПО совершенствовались и методики тестирования. Они постепенно сдвигались в сторону автоматизации и повлияли на саму структуру ПО, порождая такие «мантры», как «разработка через тестирование» (test-driven development), делая упор на такие паттерны, как инверсия зависимостей (dependency inversion), и популяризируя построенные на их основе высокоуровневые архитектуры.
Сегодня автоматизированное тестирование настолько глубоко связано в нашем сознании с разработкой ПО, что одно сложно представить без другого. И поскольку оно, в конечном итоге, позволяет нам быстро создавать ПО, не жертвуя при этом его качеством, то трудно спорить о полезности тестирования.
Однако, несмотря на существование различных подходов, современные «best practices» в основном подталкивают разработчиков к использованию конкретно юнит-тестирования. Тесты, область контроля которых находится в пирамиде Майка Кона выше, или пишутся как часть более масштабного проекта (часто совершенно другими людьми), или полностью игнорируются.
Преимущество такого подхода часть поддерживается следующим аргументом: юнит-тесты обеспечивают в процессе разработки наибольшую полезность, потому что способны быстро отслеживать ошибки и помогают применять упрощающие модульность паттерны разработки. Читать полностью »
Юнит-тесты в uVision Keil (и не только)
2020-06-09 в 12:52, admin, рубрики: C, c++, embedded, KEIL, tdd, unit-testing, велосипедостроение, программирование микроконтроллеров, юнит-тестирование, юнит-тесты
Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?
Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".
Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.
Онлайн-холивар: новый формат обмена опытом. В эту субботу
2020-04-08 в 10:20, admin, рубрики: tdd, Блог компании Skyeng, интеграционные тесты, Программирование, Разработка веб-сайтов, Тестирование IT-систем, юнит-тестыЧасто самое интересное на митапах начиналось, когда несколько человек увлеченно спорили вокруг какой-то темы, а ты мог включиться с вопросом или добавить свои “пять копеек” опыта.
Мы с Алексеем anzem Землянским и Григорием eyeofhell Петровым подумали перенести эту механику в онлайн. Хотим попробовать 11 апреля в 11 часов по Москве — в формате интерактивной ютуб-трансляции и открытых дискуссий в зуме* за эфиром. Надеемся, у вас найдется полтора часа на протестировать формат с нами.
В качестве темы для первого холивара взяли TDD.
Читать полностью »