Хотелось бы побольше конкретики. А пока только голословные высказывания по поводу недопустимости объединения тестов разного вида под одним термином. Было бы интересно узнать, почему Вы считаете, что мои три пункта правомерны для тестов одного типа и неправомерны для другого, с убедительной аргументацией.
Почему такое ироничное отношение к стартовым версиям продуктов? Любая сложная система начиналась с такого вот куличика.
Шансы кода попасть в продакшн - по сути вероятность, она растет с приближением финиша проекта. Предсказать попадание туда какого-либо кода однозначно нельзя. Какие особенные переделки требуются в нормальной архитектуре, чтобы к ней можно было применить юнит-тестирование? Переделки потребуются если почти вся функцинальность сосредоточена в нескольких громадных классах с громадными методами - ну так это плохой дизайн, и даже без расчета на последующее юнит-тестирование не следует такую архитектуру использовать.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2007-05-08 04:30 pm (UTC)Почему такое ироничное отношение к стартовым версиям продуктов? Любая сложная система начиналась с такого вот куличика.
Шансы кода попасть в продакшн - по сути вероятность, она растет с приближением финиша проекта. Предсказать попадание туда какого-либо кода однозначно нельзя. Какие особенные переделки требуются в нормальной архитектуре, чтобы к ней можно было применить юнит-тестирование? Переделки потребуются если почти вся функцинальность сосредоточена в нескольких громадных классах с громадными методами - ну так это плохой дизайн, и даже без расчета на последующее юнит-тестирование не следует такую архитектуру использовать.