Рубрика «unit-testing»

Привет! Меня зовут Василий Косарев, я Java‑разработчик в CDEK. Много раз мы слышали о необходимости писать модульные тесты, о том, что весь код должен быть ими покрыт. При этом мне не встречалось списка: какие именно методики лучше использовать при тестировании кода.

Я задумался: есть ли чек‑лист/ руководство, который облегчил бы генерацию тестовых сценариев и помог выявлять серьёзные ошибки? Чтобы вдумчиво подходить к тестированию и не тратить ресурсы впустую, сводя к минимуму количество необходимых тестов.

Читать полностью »

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

Загрузчик

Загрузчик нужен для обновления прошивки без специализированного оборудования типа программаторов. Загрузчик обязательно должен уметь обновлять по UART. Остальные интерфейсы обновления по обстоятельствам.

Компонент управления логированием

Читать полностью »

Часто слышал мнение, что в embedded программировании в принципе не может быть никакого DevOps(а).  Якобы вот есть GUI(ня) в IAR и там надо много мышкой водить. "Ты же не будешь ставить шаговые двигатели для сдвигания мышки" и т. п.

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

1. Репозиторий с кодом (репа)

Читать полностью »

КПДВ

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.

Читать полностью »

Как оценивать качество тестов? Многие полагаются на самый популярный показатель, известный всем, — code coverage. Но это количественная, а не качественная метрика. Она показывает, какой объём вашего кода покрыт тестами, но не то, как хорошо эти тесты написаны. 

Один из способов разобраться в этом — мутационное тестирование. Этот инструмент, внося небольшие правки в исходный код и заново прогоняя после этого тесты, позволяет выявить бесполезные тесты и низкокачественное покрытие.

На Badoo PHP Meetup в марте я рассказывал, как организовать мутационное тестирование для PHP-кода и с какими проблемами можно столкнуться. Видео доступно по ссылке, а за текстовой версией добро пожаловать под кат.

Мутационное тестирование в PHP: качественное измерение для code coverage - 1
Читать полностью »

Три года автотестов: как повысить скорость и не только - 1

Привет, я Алексей, full-stack разработчик платформы Vimbox. Когда я пришел в Skyeng, здесь решали, стоит ли тратить время на систему автотестов и попросили меня поделиться опытом с предыдущей работы. А такой опыт у меня был: к моменту ухода с предыдущего места мы написали на php и крутили больше 3 тысяч тестов. В итоге я сделал небольшую внутреннюю презентацию, рассказывающую о граблях, на которые успел наступить за несколько лет разработки этих автотестов, борьбы за их скорость, читабельность кода и общую эффективность. Презентация показалась коллегам полезной, поэтому я переложил ее в текст, чтобы оказаться полезным также и более широкой аудитории.

Для начала – термины, о которых пойдет речь в статье:

  • Приемочный тест – end-to-end тест: здесь браузер или эмулятор браузера исполняет сценарий
  • Модульный тест (юнит тест) – тест метода
  • Функциональный тест – тест контроллера или компонента, если речь о фронтенде
  • Фикстура – состояние тестового окружения, необходимое для работы теста (глобальные переменные, данные в БД и прочие участники сценария теста)

Читать полностью »

Вначале была функция и вызывали ее в одном месте. Потом мы захотели вызвать ее в другом месте с новыми возможностями и обновили ее. Нам эта ф-ия так понравилась, что мы вызвали ее в третьем месте и еще сделали функциональные правки и… в первом месте что-то пошло не так. А как узнать? Проверять во всех местах где мы использовали эту функцию, все ли правильно работает? Можно, но лучше использовать unit тесты.

image

Всем привет. На связи аноним из песочницы. Как правильно тестировать свой код вы можете найти в первых строчках поисковика, а вот с настройкой окружения приходится повозиться. Так вот сегодня я хочу помочь начинающим разработчикам настроить окружение для unit тестирования своего кода.

Читать полностью »

TDD в геймдеве применяют довольно редко. Обычно проще нанять тестировщика, чем выделить разработчика для написания тестов — так экономятся и ресурсы, и время. Поэтому каждый успешный пример использования TDD становится интереснее. Под катом перевод материала, где эту технику разработки применили при создании передвижения персонажей в игре ElemenTerra.

TDD в геймдеве или «кроличий ад» - 1
Читать полностью »

Как часто бывало так, что написав рабочий юнит-тест, ты смотришь на его код, а он… плохой? И ты такой думаешь: «Это же тест, оставлю так…». Нет, %username%, так оставлять не надо. Тесты — это значимая часть системы, которая обеспечивает поддерживаемость кода, и очень важно, чтобы эта часть также была поддерживаемой. К несчастью, у нас не так много способов обеспечить это (не будем же мы писать тесты на тесты), но парочка всё-таки есть.

Волшебная фея для юнит-тестов: DSL в C# - 1

Читать полностью »

Принимая удобство в использовании юнит тестов на моем любимом С++, я попытался перенести свой опыт на TSQL, тем более что новый работодатель любит полезную инициативу на местах и раздает плюшки за оное.

Просмотрел несколько известных фреймворкoв я пришел к выводу, что, как правило они громоздки и приносят дополнительных синтаксис, который надо изучать дополнительно.

Некоторые фреймворки работают красиво и радуют глаз менеджера, которому их показывают, но имеют ряд ограниченией, которые мне не понравились.

Мне же хотелось все реализовать на чистом кошерно-халяльно-православном TSQL.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js