Запуск unit тестов по изменению исходного кода

unittest
c
framework
Теги: #<Tag:0x00007fedc7438480> #<Tag:0x00007fedc74382f0> #<Tag:0x00007fedc74380e8>

(Oleksandr Pylkevych) #1

Добрый день,

Есть большой проект написанный на C. Также есть большое количество unit тестов. После каждого изменения в исходном коде проекта должны запускаться не все тесты, а только тесты, которые тестирует измененный код. Есть ли готовые инструменты?


(Виталий Коряков) #2

А если измененный код затрагивает другую функциональность? )))


(Денис Тучин) #3

А в чём проблема, что запускаются все тесты? Сколько по времени они отрабатывают? Действительно ли они настоящие модульные, т.е. изолированные от других классов: застабленнные, замокированные?


(Maxim Shulga) #4

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

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

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

Автомат по запуску сейчас что из себя представляет?


(Денис Тучин) #5

Ещё хороший подход есть который решит проблему запуска большого числа тестов и скорее всего другие проблемы, которые есть в проекте. Монолитность проекта - почти всегда плохо: сложно поддерживать, долго выкатывать на продашен и т.д. Поэтом есть смысл распилить проект на подсистемы, и тогда при изменении в 1-2 подсистемах, можно будут запускать только те тесты, которые относятся к этим подсистемам. Как предельный случай такого подхода: микросервисная архитектура.


(Oleksandr Pylkevych) #6

спасибо, хорошая идея


(Дмитрий Жарий) #7

По сути, методика получение затронутых тестов по коммиту достаточно проста:
для этого, вначале, нужно прогнать все тесты с измерением покрытия кода и сохранить иформацию, какие методы приложения вызывались входе конкретного теста. А после коммита, выбрать те тесты, которые обеспечивают наибольшее покрытие затронутых методов.

К сожалению, это просто, видимо, только на словах. Тем не менее, есть инструменты которые умеют такое делать. И возможно, эти примеры, помогут найти то что нужно для C++.

TFS -- Recommended Tests нужно пробовать, вполне может быть что это работает и для C++. Я знаю, что для .NET проблем нет. Единственная проблема -- это сам TFS, который мне очень не нравится (после 3х лет работы )

NCrunch и ContinousTest
http://www.continuoustests.com/
http://www.ncrunch.net/

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

Все это работает в .NET, и возможно у вас получится найти альтернативу для C++, отталкиваясь от этих примеров.