![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Чем похожи Диабет и Юнит-Тестирование?
May. 21st, 2016 12:49 pmПогодите хвататься за голову, изображая фейспалм, есть очень мощная параллель у таких очень разных вещей.
Сходство в том, что в обоих случаях, одно слово означает две разные вещи
Есть диабет Первого Типа, и диабет Второго Типа. Один из них - тяжелая болезнь, второй - нет. Но обе штуки называются одним словом диабет.
Аналогично с Юнит-Тестированием.
Eсть Юнит Тестирование, когда вы ломаете инкапсуляцию сущности, вытаскиваете на поверхность прайвет методы, и пишете, не думая нужно это или нет, а просто из принципа (как зубы утром чистите, не думая, надо сегодня чистить или не надо) - юнит тест на ЛЮБОЙ чих, на любой, самый простейший уан-лайнер. В результате, если тест красный, вы знаете сразу, какая функция сломалась, не надо разбираться. Минусы - ваша жизнь состоит наполовину из написания бойлерплейта тестов и на постоянную их адаптацию при рефакторинге.
А есть Юнит Тестирование, когда тестируются интерфейсы логически обособленных сущностей, на предмет выполнения контракта этих сущностей. А их внутренняя имплементация - НЕ тестируется напрямую. Она тоже тестируется, но ЧЕРЕЗ публичные методы сущности. Достоинства этого метода в том, что вам не нужно переписывать ваши тесты, когда меняется внутрення имплементация в рамках рефакторинга. Presumable минус метода в том, что если тест красный, вам нужно потратить некоторое время на то, чтобы понять где именно ошибка.
Можно быть горячим адвокатом Юнит тестирования, но только второго типа. Вот например, человек говорит что даже сам Кент Бек, который ТДД придумал, типа тоже за такое ЮТ с "человеческим лицом".
http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
If we follow TDD as originally envisaged though, the tests will naturally fall mainly on our public interface, not the implementation details, and we will find it far easier to meet the goal of changing the impementation details (safe change) and not the public interface (unsafe change)
Для ЮТ первого типа я предлагаю название ISIS-style Unit Testing (прим. ИГИЛ - организация, запрещенная в РФ)
Поверьте мне на слово, это ОЧЕНЬ РАЗНЫЕ вещи. Не менее разные, чем диабет первого и второго типа. Хотя слово одно и то же.
Сходство в том, что в обоих случаях, одно слово означает две разные вещи
Есть диабет Первого Типа, и диабет Второго Типа. Один из них - тяжелая болезнь, второй - нет. Но обе штуки называются одним словом диабет.
Аналогично с Юнит-Тестированием.
Eсть Юнит Тестирование, когда вы ломаете инкапсуляцию сущности, вытаскиваете на поверхность прайвет методы, и пишете, не думая нужно это или нет, а просто из принципа (как зубы утром чистите, не думая, надо сегодня чистить или не надо) - юнит тест на ЛЮБОЙ чих, на любой, самый простейший уан-лайнер. В результате, если тест красный, вы знаете сразу, какая функция сломалась, не надо разбираться. Минусы - ваша жизнь состоит наполовину из написания бойлерплейта тестов и на постоянную их адаптацию при рефакторинге.
А есть Юнит Тестирование, когда тестируются интерфейсы логически обособленных сущностей, на предмет выполнения контракта этих сущностей. А их внутренняя имплементация - НЕ тестируется напрямую. Она тоже тестируется, но ЧЕРЕЗ публичные методы сущности. Достоинства этого метода в том, что вам не нужно переписывать ваши тесты, когда меняется внутрення имплементация в рамках рефакторинга. Presumable минус метода в том, что если тест красный, вам нужно потратить некоторое время на то, чтобы понять где именно ошибка.
Можно быть горячим адвокатом Юнит тестирования, но только второго типа. Вот например, человек говорит что даже сам Кент Бек, который ТДД придумал, типа тоже за такое ЮТ с "человеческим лицом".
http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
If we follow TDD as originally envisaged though, the tests will naturally fall mainly on our public interface, not the implementation details, and we will find it far easier to meet the goal of changing the impementation details (safe change) and not the public interface (unsafe change)
Для ЮТ первого типа я предлагаю название ISIS-style Unit Testing (прим. ИГИЛ - организация, запрещенная в РФ)
Поверьте мне на слово, это ОЧЕНЬ РАЗНЫЕ вещи. Не менее разные, чем диабет первого и второго типа. Хотя слово одно и то же.
