Сообщение Re[18]: Внедрение зависимостей в типичном веб приложении. от 26.05.2017 5:12
Изменено 26.05.2017 5:14 IQuerist
Re[18]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
IQ>> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и соотв. за пределами кода.
И это я еще не беру в рассчет ошибки программера.
·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
В вашей фразе кстати бездна философского смысла! (без сарказма) Но, не в этой реальности )))
IQ>> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и соотв. за пределами кода.
И это я еще не беру в рассчет ошибки программера.
·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
В вашей фразе кстати бездна философского смысла! (без сарказма) Но, не в этой реальности )))
Re[18]: Внедрение зависимостей в типичном веб приложении.
Здравствуйте, ·, Вы писали:
IQ>> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода.
И это я еще не беру в рассчет ошибки программера.
·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))
IQ>> IQ>>Осталось определиться с критериями полноты и актуальности )))
IQ>> ·>Актуальность — 100%, очевидно же, если они компилятся и зелёные. А как полноту любой документации измерить в принципе?
IQ>> ))))))))))) увы тесты это не то, что нужно заказчику, заказчику нужен бизнес-функционал, по нему и измеряется и актуальность и полнота.
·>Код должен обеспечивать бизнес-функционал. Тесты должны тестировать код. Значит тесты тестируют бизнес-функционал.
Увы, бизнес функционал может быть вообще не связан с написанным кодом, например если аналитики "сработали плохо". Бизнес функционала вообще (части бизнес функционала) может вообще не быть ))) т.к. ее планирую стартовать после релиза проекта. Ну и что хуже всего бизнес функционал скорее всего измениться в процессе эксплуатации проекта, этого не будет в коде соотв. этого не будет в тестах.
Имхо бизнес процессы — вынужденая мера бизнеса. Источник их сущности за пределами бизнеса и конечно же за пределами кода.
И это я еще не беру в рассчет ошибки программера.
·>В идеале — если функционал не покрыт тестами — значит бизнесу он не нужен.
В вашей фразе кстати бездна философского смысла! (без сарказма) Но в этой реальности бизнес не знает о юнит тестах)))