Сообщение Re[3]: Что и как следует покрывать юнит-тестами от 04.01.2016 20:10
Изменено 04.01.2016 20:11 Pauel
Здравствуйте, Yoriсk, Вы писали:
Y>Здравствуйте, Ikemefula, Вы писали:
I>>Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
Y>Нет, не должен.
Y>Потому что это не только бесполезно — зная об ошибке в определённом сценарии ты её и так найдёшь,
А временем на поиски можно пренебречь ? Вообще то юнит-тесты избавляют от дебага. Классика юнит-тестирования — код теста содержит минимум кода и один-два ассерта. Отсюда ясно, что ошибка видна практически сразу, без необходимости дебага и поисков.
>т.е. ценна именно информация "у нас что-то не так", всё остальное приложится само собой — но и просто вредно, т.к. для более лучшего указания на источник ошибки начинается тестирование геттеров-сеттеров, конструкторов типа { this.param1 = param1; this.param2 = param2; } и прочие невероятно полезеные практики, столь улучшающин проценты метрик и столь тешащие сердца менеджмента.
Наоборот, геттеры и сеттеры размывают профит из за того, что тестируется 'что унутре'. С конструкторами ровно то же — тестирование 'что унутре'. Такой подход при малейшем телодвижении поломает вообще все тесты. ТО есть, сразу всё становится красным.
Y>Здравствуйте, Ikemefula, Вы писали:
I>>Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
Y>Нет, не должен.
Y>Потому что это не только бесполезно — зная об ошибке в определённом сценарии ты её и так найдёшь,
А временем на поиски можно пренебречь ? Вообще то юнит-тесты избавляют от дебага. Классика юнит-тестирования — код теста содержит минимум кода и один-два ассерта. Отсюда ясно, что ошибка видна практически сразу, без необходимости дебага и поисков.
>т.е. ценна именно информация "у нас что-то не так", всё остальное приложится само собой — но и просто вредно, т.к. для более лучшего указания на источник ошибки начинается тестирование геттеров-сеттеров, конструкторов типа { this.param1 = param1; this.param2 = param2; } и прочие невероятно полезеные практики, столь улучшающин проценты метрик и столь тешащие сердца менеджмента.
Наоборот, геттеры и сеттеры размывают профит из за того, что тестируется 'что унутре'. С конструкторами ровно то же — тестирование 'что унутре'. Такой подход при малейшем телодвижении поломает вообще все тесты. ТО есть, сразу всё становится красным.
Re[3]: Что и как следует покрывать юнит-тестами
Здравствуйте, Yoriсk, Вы писали:
I>>Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
Y>Нет, не должен.
Y>Потому что это не только бесполезно — зная об ошибке в определённом сценарии ты её и так найдёшь,
А временем на поиски можно пренебречь ? Вообще то юнит-тесты избавляют от дебага. Классика юнит-тестирования — код теста содержит минимум кода и один-два ассерта. Отсюда ясно, что ошибка видна практически сразу, без необходимости дебага и поисков.
>т.е. ценна именно информация "у нас что-то не так", всё остальное приложится само собой — но и просто вредно, т.к. для более лучшего указания на источник ошибки начинается тестирование геттеров-сеттеров, конструкторов типа { this.param1 = param1; this.param2 = param2; } и прочие невероятно полезеные практики, столь улучшающин проценты метрик и столь тешащие сердца менеджмента.
Наоборот, геттеры и сеттеры размывают профит из за того, что тестируется 'что унутре'. С конструкторами ровно то же — тестирование 'что унутре'. Такой подход при малейшем телодвижении поломает вообще все тесты. ТО есть, сразу всё становится красным.
Скажем, для получения информации качества 'что-то не так' обычно и тесты не нужны
I>>Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
Y>Нет, не должен.
Y>Потому что это не только бесполезно — зная об ошибке в определённом сценарии ты её и так найдёшь,
А временем на поиски можно пренебречь ? Вообще то юнит-тесты избавляют от дебага. Классика юнит-тестирования — код теста содержит минимум кода и один-два ассерта. Отсюда ясно, что ошибка видна практически сразу, без необходимости дебага и поисков.
>т.е. ценна именно информация "у нас что-то не так", всё остальное приложится само собой — но и просто вредно, т.к. для более лучшего указания на источник ошибки начинается тестирование геттеров-сеттеров, конструкторов типа { this.param1 = param1; this.param2 = param2; } и прочие невероятно полезеные практики, столь улучшающин проценты метрик и столь тешащие сердца менеджмента.
Наоборот, геттеры и сеттеры размывают профит из за того, что тестируется 'что унутре'. С конструкторами ровно то же — тестирование 'что унутре'. Такой подход при малейшем телодвижении поломает вообще все тесты. ТО есть, сразу всё становится красным.
Скажем, для получения информации качества 'что-то не так' обычно и тесты не нужны