История изменений
Исправление Manhunt, (текущая версия) :
А если это автомат состояний, с сотнями параметров и условий и, соответственно какими-ниубдь квинтиллионами возможных состояний - то
Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности (= написаны юнит-тесты с хорошим покрытием).
чем вообще поможет парочка сраных тестов,
Их там не парочка будет. В норме юнит-тестов должно быть пропорционально количеству классов и методов. Если добиваться хорошего покрытия, то объем кода с тестами будет превышать объем «боевого» кода.
Поможет тем, что чем на более ранней стадии разработки выявляется дефект, тем меньший экономический ущерб он наносит.
кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно
Все прекрасно понимают (и грамотный разработчик, и грамотный менеджер), что даже хорошее покрытие тестами само по себе не даёт никаких гарантий. Это чисто твоя личная фантазия, которую ты прилюдно и доблестно пытаешься высмеять.
Спесь про «ложную уверенность» слетает по мере того, как тесты выявляют в твоем коде проблемы, которых ты при написании кода не замечал. Становится прямо-таки очевидным, что без тестов качество программного продукта будет намного ниже.
чистая профанация ради прикрытия своей жопы - «а я чо, все тесты были пройдены, я ничо, насралося.»
Спрашивают за результат (процент времени простоя сервиса, количество серьезных инцидентов вроде потери данных, и подобные метрики). Мычание о том, каким образом ты этого результата достиг (или не достиг) на судьбу задницы не особо влияет.
Тесты - это производственная практика, это инструмент разработки. В одном ряду со множеством других производственных практик и инструментов. И это точно не панацея и не замена головы.
Исправление Manhunt, :
А если это автомат состояний, с сотнями параметров и условий и, соответственно какими-ниубдь квинтиллионами возможных состояний - то
Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности (= написаны юнит-тесты с хорошим покрытием).
чем вообще поможет парочка сраных тестов,
Их там не парочка будет. В норме юнит-тестов должно быть пропорционально количеству классов и методов. Если добиваться хорошего покрытия, то объем кода с тестами будет превышать объем «боевого» кода.
Поможет тем, что чем на более ранней стадии разработки выявляется дефект, тем меньший экономический ущерб он наносит.
кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно
Все прекрасно понимают (и грамотный разработчик, и грамотный менеджер), что даже хорошее покрытие тестами само по себе не даёт не никаких гарантий. Это чисто твоя личная фантазия, которую ты прилюдно и доблестно пытаешься высмеять.
Спесь про «ложную уверенность» слетает по мере того, как тесты выявляют в твоем коде проблемы, которых ты при написании кода не замечал. Становится прямо-таки очевидным, что без тестов качество программного продукта будет намного ниже.
чистая профанация ради прикрытия своей жопы - «а я чо, все тесты были пройдены, я ничо, насралося.»
Спрашивают за результат (процент времени простоя сервиса, количество серьезных инцидентов вроде потери данных, и подобные метрики). Мычание о том, каким образом ты этого результата достиг (или не достиг) на судьбу задницы не особо влияет.
Тесты - это производственная практика, это инструмент разработки. В одном ряду со множеством других производственных практик и инструментов. И это точно не панацея и не замена головы.
Исходная версия Manhunt, :
А если это автомат состояний, с сотнями параметров и условий и, соответственно какими-ниубдь квинтиллионами возможных состояний - то
Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности (= написаны юнит-тесты с хорошим покрытием).
чем вообще поможет парочка сраных тестов,
Их там не парочка будет. В норме их должно быть пропорционально количеству классов и методов. Если добиваться хорошего покрытия, то объем кода с тестами будет превышать объем «боевого» кода.
Поможет тем, что чем на более ранней стадии разработки выявляется дефект, тем меньший экономический ущерб он наносит.
кроме создания ложной увернности у долбодятла (и его начальства), который уверовал в «полное покрытие», в том что всё правильно
Все прекрасно понимают (и грамотный разработчик, и грамотный менеджер), что даже хорошее покрытие тестами само по себе не даёт не никаких гарантий. Это чисто твоя личная фантазия, которую ты прилюдно и доблестно пытаешься высмеять.
Спесь про «ложную уверенность» слетает по мере того, как тесты выявляют в твоем коде проблемы, которых ты при написании кода не замечал. Становится прямо-таки очевидным, что без тестов качество программного продукта будет намного ниже.
чистая профанация ради прикрытия своей жопы - «а я чо, все тесты были пройдены, я ничо, насралося.»
Спрашивают за результат (процент времени простоя сервиса, количество серьезных инцидентов вроде потери данных, и подобные метрики). Мычание о том, каким образом ты этого результата достиг (или не достиг) на судьбу задницы не особо влияет.
Тесты - это производственная практика, это инструмент разработки. В одном ряду со множеством других производственных практик и инструментов. И это точно не панацея и не замена головы.