Исходное сообщение
"Линус Торвальдс выступил с критикой контроля качества в  DRM..." Отправлено Анонимм, 27-Фев-17 13:03
>> написание такой проверки ещё перед кодом > Это называется "перенос сложности". Сложность системы остаётся неизменной, но можно перенести > её с одного этапа на другой. Оно и одержимое первых 7 метров /dev/random сложно, как и 7 метров /boot/vmlinuz-4.4.0-64-lowlatency но в первом случае - такая фигня получается... > В данном случае вы переносите > сложность тестирования и отладки с этапа тестирования и отладки на этап > написания предварительных тестов. Если нет тестов - то начинается дебаг, роль уровня владения дебаггером разработчика и временные затраты на сам дебаг - значительно возрастают с ростом проекта (посмотрите сколько уже инструментов run-time дебага в линухе) Что лучше: один раз написать тест и получить постоянную проверку этого места кода, чем постоянно тратить время на дебаг? Ведь тест то будет запускаться всегда уже автоматом, без доп. затрат времени. > По личному опыту: это работает лишь в самых простых случаях. Когда в > коде идёт выборка данных из БД или работа с оборудованием, то > для повторения ситуации нужно повторить всю БД или её значительную часть. А большие модули системы никак не должны работать вместе? И пусть это уже называется не юнит-тестированием, а как-то иначе, но сути не меняет: Вы ведь хотите, чтоб продукт всегда работал, а не только во время изначального написания кода? А как _убедиться_, что он работает? - А только протестировать. > Отсюда вытекает, что твои тесты возможно лишь в простых функциях где есть > чётко обозначенные вход и выход. В 90% случаев они настолько просты > и понятны, что написание для них тестов - это потеря времени. И после любого изменения начинается "экономия времени": открыть страничку логина, нажать кнопку, попробовать там ли всё работает... И это нужно делать при каждом добавлении новой фичи или исправлении бага - иначе нет морального права утверждать, что вся программа работает. Т.е. тестировать всё равно приходится. Но как быстрее: руками или автоматически, кодом? > Unit тесты становятся интересными лишь в ситуациях где... должно работать, а не просто почасовая оплата ^_^

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> написание такой проверки ещё перед кодом >> Это называется "перенос сложности". Сложность системы остаётся неизменной, но можно перенести >> её с одного этапа на другой. > Оно и одержимое первых 7 метров /dev/random сложно, как и 7 метров > /boot/vmlinuz-4.4.0-64-lowlatency > но в первом случае - такая фигня получается... >> В данном случае вы переносите >> сложность тестирования и отладки с этапа тестирования и отладки на этап >> написания предварительных тестов. > Если нет тестов - то начинается дебаг, роль уровня владения дебаггером разработчика > и временные затраты на сам дебаг - значительно возрастают с ростом > проекта (посмотрите сколько уже инструментов run-time дебага в линухе) > Что лучше: один раз написать тест и получить постоянную проверку этого места > кода, чем постоянно тратить время на дебаг? > Ведь тест то будет запускаться всегда уже автоматом, без доп. затрат времени. >> По личному опыту: это работает лишь в самых простых случаях. Когда в >> коде идёт выборка данных из БД или работа с оборудованием, то >> для повторения ситуации нужно повторить всю БД или её значительную часть. > А большие модули системы никак не должны работать вместе? > И пусть это уже называется не юнит-тестированием, а как-то иначе, но сути > не меняет: > Вы ведь хотите, чтоб продукт всегда работал, а не только во время > изначального написания кода? А как _убедиться_, что он работает? - А > только протестировать. >> Отсюда вытекает, что твои тесты возможно лишь в простых функциях где есть >> чётко обозначенные вход и выход. В 90% случаев они настолько просты >> и понятны, что написание для них тестов - это потеря времени. > И после любого изменения начинается "экономия времени": открыть страничку логина, нажать > кнопку, попробовать там ли всё работает... > И это нужно делать при каждом добавлении новой фичи или исправлении бага > - иначе нет морального права утверждать, что вся программа работает. > Т.е. тестировать всё равно приходится. Но как быстрее: руками или автоматически, кодом? >> Unit тесты становятся интересными лишь в ситуациях где... > должно работать, а не просто почасовая оплата ^_^
	Введите код, изображенный на картинке: