Комментарии 5
Иначе огромное число юнит-тестов получится хрупкими. При большом рефакторинге затрагивается много классов — неизбежно упадут тесты
Но почему? Юнит тесты как раз стабильные, при рефакторинге они и не упадут. А вот функциональные могут и просыпаться, т.к. изменятся условные зависимости.
Upd. Понял, что не донёс мысль.
Функциональный тест чаще всего затрагивает всю систему, поэтому они потенциально хрупкие.
А вот unit тесты обычно пишутся для каких то атомарных операций, которые вряд ли сильно меняются
Привет, что такое рефакторинг? Это улучшение кода, при котором функциональность остается неизменной, т.е. ни бизнес ни тестировщики не должны заметить каких-либо изменений после рефакторинга. Также здесь надо определиться, что именно мы понимаем под названием "функциональные" тесты. У нас это высокоуровневые тесты, которые работают на уровне интерфейсов системы - контрактов апи-точек и контрактов событий. При рефакторинге внешние контракты системы остаются неизменными. Но контракты внутренние, т.е. контракты классов могут изменяться произвольный образом. В процессе рефакторинга классы могут изменяться или вообще исчезать, методы и конструкторы могут получать или терять параметры. В этом случае юнит тесты неизбежно упадут, т.к. юнит тест хоть и не знает про внутрянку класса, но входящие параметры (контракт) он знает. Функциональный же тест при рефакторинге не упадет, т.к. он более высокоуровневый, для него весь код - один черный ящик. При рефакторинге функциональный тест вообще никак упасть не может, он не заметит изменений также как и тестировщик, т.к. внешний контракт системы остается неизменным.
В теории всё так, а на практике не совсем так. На практике контракт подразумевает не только очевидные части (декларация функций и API), но и всякие неявные части (порядок вызовов, выбрасываемые исключения и т.д.), которые формально никак не описаны, но влияют на работу системы.
И хрупкость и проблема интеграционных тестов заключается в том, что после массивного рефакторинга, формально контракт может остаться соблюден, но тесты при этом будут падать.
И в случае модульных тестов, если они написаны как нормальныен модульные тесты и падают при рефакторинге, найти причину очень просто, как правило, и исправить можно очень быстро. В случае же интеграционных тестов, причину искать можно долго, особенно если в коде завелся какой-то мерцающий баг, который зависит от порядка вызовов, времени или состояния луны.
Привет, проблема падения функциональных тестов после рефакторинга иногда возникает, спорить не буду, но это больше исключение нежели правило. С другой стороны то, что юнит-тесты падают после рефакторинга - это не исключение, а неизбежное явление, если конечно, рефакторинг не ограничился одним классом. При этом да, большое число юнит тестов помогает точно локализовать проблему, тогда как функциональные тесты не позволят это сделать. Собственно пирамида тестов и подразумевает большое число юнит-тестов. Но у нас она не реализована и это плохо.
Т.е. если говорить именно про хрупкость - то юнит тесты более хрупкие, но как-бы это и подразумевается их сутью
Функциональные тесты на проекте: жизнь до и после (на примерах)