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