Сообщение Re[4]: Тестирование приватных методов класса - за/против? от 07.08.2015 16:34
Изменено 07.08.2015 16:35 another_coder
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, another_coder, Вы писали:
_>>Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
PD>Ради тестирования нарушать структуру классов ? Метод сортировки должен быть там, где ему по логике положено быть, а не по соображениям удобства тестирования. Если ему по логике действительно нужно быть в отдельном классе — туда ему и дорога. Но не по соображениям тестирования.
Все логично. Либо он является частью внутренней логики и неявно тестирует через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:
1) методу не место внутри класса из-за более сложной логики, чем требуется
2) какие-то случаи являются лишними и написаны лишние тесты
3) публичные методы недостаточно качественно протестированны
Тут ваша мысль абсолютна понятна. Зачем выделять в какой-то класс, когда можно написать вызов приватного метода через рефлексию и посмотреть как оно работает. Тут больше речь идет о том, чтобы держать свои инструменты, рабочий стол, код, документацию и пр. в порядке. Да, можно и так, как говорите вы, но вероятность проблем будет ниже, если держать все в чистоте. Все очень банально. Если рефакторить раз в неделю и писать сразу нормально, то это не сложно. Если рефакторить раз в месяц, а в остальное время костыли — то легко не получится. С этим никто не спорит.
PD>Здравствуйте, another_coder, Вы писали:
_>>Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
PD>Ради тестирования нарушать структуру классов ? Метод сортировки должен быть там, где ему по логике положено быть, а не по соображениям удобства тестирования. Если ему по логике действительно нужно быть в отдельном классе — туда ему и дорога. Но не по соображениям тестирования.
Все логично. Либо он является частью внутренней логики и неявно тестирует через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:
1) методу не место внутри класса из-за более сложной логики, чем требуется
2) какие-то случаи являются лишними и написаны лишние тесты
3) публичные методы недостаточно качественно протестированны
Тут ваша мысль абсолютна понятна. Зачем выделять в какой-то класс, когда можно написать вызов приватного метода через рефлексию и посмотреть как оно работает. Тут больше речь идет о том, чтобы держать свои инструменты, рабочий стол, код, документацию и пр. в порядке. Да, можно и так, как говорите вы, но вероятность проблем будет ниже, если держать все в чистоте. Все очень банально. Если рефакторить раз в неделю и писать сразу нормально, то это не сложно. Если рефакторить раз в месяц, а в остальное время костыли — то легко не получится. С этим никто не спорит.
Re[4]: Тестирование приватных методов класса - за/против?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, another_coder, Вы писали:
_>>Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
PD>Ради тестирования нарушать структуру классов ? Метод сортировки должен быть там, где ему по логике положено быть, а не по соображениям удобства тестирования. Если ему по логике действительно нужно быть в отдельном классе — туда ему и дорога. Но не по соображениям тестирования.
Все логично. Либо он является частью внутренней логики и неявно тестируется через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:
1) методу не место внутри класса из-за более сложной логики, чем требуется
2) какие-то случаи являются лишними и написаны лишние тесты
3) публичные методы недостаточно качественно протестированны
Тут ваша мысль абсолютна понятна. Зачем выделять в какой-то класс, когда можно написать вызов приватного метода через рефлексию и посмотреть как оно работает. Тут больше речь идет о том, чтобы держать свои инструменты, рабочий стол, код, документацию и пр. в порядке. Да, можно и так, как говорите вы, но вероятность проблем будет ниже, если держать все в чистоте. Все очень банально. Если рефакторить раз в неделю и писать сразу нормально, то это не сложно. Если рефакторить раз в месяц, а в остальное время костыли — то легко не получится. С этим никто не спорит.
PD>Здравствуйте, another_coder, Вы писали:
_>>Если все так, то метод сортировки необходимо вытащить в отдельный модуль (класс с экстеншенами, или класс сортирвки — это зависит от Вашего случая, как удобнее). И тестировать отдельно модуль с сортировкой, проверяя, что он удовлетворяет требованиям. Его затем использовать внутри класса API. Если высока вероятность динамической компановки, использовать DI.
PD>Ради тестирования нарушать структуру классов ? Метод сортировки должен быть там, где ему по логике положено быть, а не по соображениям удобства тестирования. Если ему по логике действительно нужно быть в отдельном классе — туда ему и дорога. Но не по соображениям тестирования.
Все логично. Либо он является частью внутренней логики и неявно тестируется через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:
1) методу не место внутри класса из-за более сложной логики, чем требуется
2) какие-то случаи являются лишними и написаны лишние тесты
3) публичные методы недостаточно качественно протестированны
Тут ваша мысль абсолютна понятна. Зачем выделять в какой-то класс, когда можно написать вызов приватного метода через рефлексию и посмотреть как оно работает. Тут больше речь идет о том, чтобы держать свои инструменты, рабочий стол, код, документацию и пр. в порядке. Да, можно и так, как говорите вы, но вероятность проблем будет ниже, если держать все в чистоте. Все очень банально. Если рефакторить раз в неделю и писать сразу нормально, то это не сложно. Если рефакторить раз в месяц, а в остальное время костыли — то легко не получится. С этим никто не спорит.