Обычно тесты не популярны в СНГ. Многие считают их дорогими и тормозящими разработку. Часто это говорят те, кто за разработку принимает написание кода сразу в прод и забывают о нем навсегда

https://habr.com/ru/post/709228/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709228

Часто в РФ приходится слышать мнение, что в Embedded разработке якобы в принципе не может быть никакого модульного тестирования. Инженеры за 40 в (7 случаях из 10) даже никогда не слышали термина unit testing. В России бытует даже расхожее мнение

Не нужны никакие тесты. Если программист хороший, то и код он пишет без ошибок.

Попробуем разобраться какие есть плюсы и минусы в модульном тестировании и понять надо это или нет.

https://habr.com/ru/post/698092/?utm_source=habrahabr&utm_medium=rss&utm_campaign=698092

Привет! Меня зовут Алёна Луцик, я QA-инженер в команде Авито. За время работы я много раз убеждалась, что разработчик и тестировщик смотрят на код по-разному. Это заметно, когда нужно обеспечить покрытие unit-тестами.

Разработчику выгоднее написать один большой тест, который зайдёт в максимальное число ветвлений и покажет, как работают разные функции. При этом QA-инженеру нужны автотесты, которые выявят ошибки в бизнес-логике и помогут улучшить продукт в целом.

Договориться, какими будут unit-тесты, лучше заранее. Рассказываю, какие простые шаги я делаю, чтобы прийти к взаимопониманию с коллегами-разработчиками.

https://habr.com/ru/post/692940/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692940

Для начала разберемся что же такое unit тестирование. Cогласно википедии:

Модульное тестирование, иногда блочное тестирование или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки.

Честно говоря, описание из википедии кажется мне абстрактным. Так как не передаёт важное отличие интеграционных тестов от unit.

Я бы дал следующее определение для unit тестирования:

Unit тестирование - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, который работает в оперативной памяти и не взаимодействует с внешними источниками (файловая система, база данных, сеть и т.д).

https://habr.com/ru/post/692456/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692456

В этом тексте я предлагаю порассуждать, что же должно быть в нормальном взрослом firmware репозитории безотносительно к конкретному проекту.

То есть перечислить самые универсальные и переносимые программные компоненты (кирпичики), которые могут пригодиться в практически любой сборке.

https://habr.com/ru/post/689542/?utm_source=habrahabr&utm_medium=rss&utm_campaign=689542

По непроверенным данным, половина несчастных случаев происходит после слов "смотри, как я умею", другая же половина — после "ерунда, смотри, как надо".

Тут один приятель, увидев фокус с тестами без тестов с использованием обобщенных аттрибутов из preview версии C# и особенностей экосистемы NUnit, отметил, что все сделано транс-ректально, а сам бы он применил Fody, и вышло бы гораздо лучше. Демонстрировать, к сожалению, ничего не стал. А мне вспомнился комментарий к описанию другого преодоления концептуального ограничения языка. Тогда руки не дошли попробовать, а сейчас вот решил глянуть, что это за птица, и проверить, поможет ли она написать более элегантное решение.

https://habr.com/ru/post/684056/?utm_source=habrahabr&utm_medium=rss&utm_campaign=684056

https://habr.com/ru/post/666196/?utm_source=habrahabr&utm_medium=rss&utm_campaign=666196

Привет! Меня зовут Владислав Сединкин, я работаю iOS-разработчиком в СберМаркете. Сегодня я расскажу, как мы проводим юнит-тестирование, с какими сложностями сталкивались при написании тестов и как их решали.

Я выступал с этим докладом на iOS Meetup | СберМаркет Tech, здесь его сжатая версия.

https://habr.com/ru/post/665512/?utm_source=habrahabr&utm_medium=rss&utm_campaign=665512

Часто слышу мнение, что unit-тесты не нужны для мобильной разработки: в приложении должно быть минимум логики, основная работа с UI, а его сложно тестировать, да ещё и тесты отнимают время, которое можно было бы потратить на написание фич.

За этим мнением скрывается простая правда — люди, которые так говорят, не умеют писать тесты. Не умеют писать их быстро; писать там, где нужно; писать так, чтобы была ощутимая польза для бизнеса. Я тоже был таким — понимал, что тесты нужны, но не понимал какие, где и как их писать.

Рассказываю, что поменялось спустя 2 года и 4 тысячи тестов.

https://habr.com/ru/post/661741/?utm_source=habrahabr&utm_medium=rss&utm_campaign=661741

В этом тексте я намерен пофантазировать каким мог бы быть абстрактный процесс разработки firmware с точки зрения DevOps. И перечислить атрибуты такого процесса.

https://habr.com/ru/post/656449/?utm_source=habrahabr&utm_medium=rss&utm_campaign=656449

В iOS-приложении Авито куча UI-тестов — вы это уже наверняка знаете, потому что мы говорим про них постоянно. Это позволяет нам релизиться раз в неделю, причём регрессионное тестирование с ручными проверками мы проводим раз в две недели. Между ними в релиз идёт приложение, которое протестировано только нашими UI- и unit-тестами.

Чтобы поддерживать такие масштабы автотестирования, мы написали тест-раннер Emcee, который умеет скейлиться в ширину по физическим машинкам.

https://habr.com/ru/post/650223/?utm_source=habrahabr&utm_medium=rss&utm_campaign=650223

Когда я писал свой первый gradle-плагин, я проверял его работоспособность следующим образом:

1. Опубликовал версию n в plugins.gradle.org
2. Проверил опубликованный плагин вручную на тестовом проекте
3. Нашел ошибку/доработал, увеличил версию n=n+1, затем снова пункт 1

Такой вот PDD (Publish Driven Development). Сегодня поговорим о том, как писать эффективные тесты на собственные gradle плагины.

https://habr.com/ru/post/599429/?utm_source=habrahabr&utm_medium=rss&utm_campaign=599429

В прошлой статье, я описывал как тестировать компонент. Теперь же коснемся вопроса тестирования сервиса.

https://habr.com/ru/post/593501/?utm_source=habrahabr&utm_medium=rss&utm_campaign=593501

Как ни странно, тема автоматизированного тестирования приложений iOS не так уж популярна среди разработчиков. Сложно судить о причинах такого положения дел, но сегодня я постараюсь пролить немного света на эту тему. В этой статье-туториале рассказывается, как лучше начать работать с фреймворком для тестирования Quick и метчером Nimble, как организовать код тестов, чтобы их было легко читать и поддерживать, как избежать дублирования проверок и сделать тесты более выразительными. Если вы хотите начать писать тесты под iOS, но не готовы тратить на их поддержку и написание много времени, — эта статья для вас.

https://habr.com/ru/post/582762/?utm_source=habrahabr&utm_medium=rss&utm_campaign=582762

Disclaimer.

Статья не содержит описание новомодных технологий или прорывы на поприще разработки. Рассматривайте её как рассказ об опыте открытия для себя мира unit тестирования.

Если вы раньше не писали unit-тесты, но хотите начать, не уверены как тестировать вашу БД и нужно ли это, не знаете как использовать моки, и для чего они, то эта статья может стать началом вашего пути.

А ещё здесь есть драконы - и это нормально.

https://habr.com/ru/post/572640/?utm_source=habrahabr&utm_medium=rss&utm_campaign=572640