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

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

Здравствуйте, bul, Вы писали:

bul>Допустим, мы имеем большой проект, с высокой степенью юнит-тестирования.
bul>Как относится время компиляции самого проекта к времени на компиляцию и запуск юнит-тестов? Хотя бы порядок?

bul>Это нужно знать для того, чтобы решить, делать ли тесты отключаемыми в общей компиляции, или нет.


Пример:

ASP.NET application

45 модулей

Code coverage — 65,36%

Compile time:

Release configuration: 20 sec
Debug configuration: 35 sec
Code analyze debug configuration: 2 min 25 sec

Tests running time (417 tests): 1 min 17 sec

В составе тестов не только Unit Tests, но и функциональные тесты

Метрика LOC по проекту (Lines of Code) — 9517

C уважением, Алексей

Здравствуйте, AlekseyAntonov, Вы писали:

AA>ASP.NET application

AA>45 модулей

...

AA>Метрика LOC по проекту (Lines of Code) — 9517

Ничего не напутали? 1 модуль — 200 строк?

А зачем на каждую компиляцию тесты гонять?

У нас перед комитом в репозиторий требуется прогнать + сервер для каждого билда прогоняет все тесты — в обоих случае не так важно время на прогон тестов.

A>А зачем на каждую компиляцию тесты гонять?
Наверное, единственный резон — тестировать код в разных условиях (разные ОС, разные процессоры, разный установленный софт(хотя это не должно влиять) у разработчиков). И еще — это в большей степени гарантирует прогон теста перед вливанием измененного кода в репозитарий, чем в случае отключаемых тестов.
И, кроме того, если это не долго, то почему бы не гонять?

AA>ASP.NET application

AA>45 модулей

...

AA>Метрика LOC по проекту (Lines of Code) — 9517

>> Ничего не напутали? 1 модуль — 200 строк?

Все правильно. Проект еще находится на ранней стадии разработки. Часть библиотек — чистые заглушки, в них нет еще кода вообще.

>> А зачем на каждую компиляцию тесты гонять?

>> У нас перед комитом в репозиторий требуется прогнать + сервер для каждого билда прогоняет все тесты — в обоих случае не так важно время на
>> прогон тестов.

Все правильно. Плюс идеология XP/TDD говорит, что участок кода является работоспособным, если тест для этого участка
отработал успешно. Как это проверить, не запуская тесты после компиляции?

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

Все правильно. Дополнительное тестирование является частью процесса QA.