Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Константин Б., Вы писали:
L>>>И чем это будет лучше?
КБ>>Эти тесты проживут дольше. Можно рефакторить углы и код их использующий, а тесты не изменятся.
L>Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
Тесты для кода использущего угла писать все равно придется. Сложность их будет такая же. Время потрачено будет то же. А ошибки легко локализуются по логам системы контроля версий.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
M>>>Насколько этот сценарий правдоподобен, судите сами. Какие еще возможны варианты тестирования (тестирование == проверить функционал)? мне будет интересно послушать.
КБ>>А почему бы и не выкинуть? Написать интеграционные тесты кода который использует эти углы эйлера, а сами тесты для углов — выкинуть.
M>А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
Здравствуйте, Константин Б., Вы писали:
M>>А если через год увидишь новый ,более эфективный способ конвертирования? захочется попробовать , а тестов нету ... стремно как то ?
КБ>Как это тестов нету? А интеграционные?
Мммм все зависит от интеграционных. Если они покрывают функциональность УЭ так же как и первые тесты , тогда вы писали тесты 2 раза. Если покрытие данными меньше, а это мне кажется более реалистичный вариант , то вы либо пишете тесты граничных условий и т.д еще раз , либо оставляете неоттестированный код.
Здравствуйте, Константин Б., Вы писали:
КБ>Как это тестов нету? А интеграционные?
Ну и конечно отлаживать код на интеграционных тестах для нового метода конвернирования УЭ будет сложнее. А если новый метод потребует еще и проверки новых граничных условий , а интеграционный тест не позволяет это сделать?
А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
Здравствуйте, minorlogic, Вы писали:
M>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, minorlogic, Вы писали:
M>>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
КБ>Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
Ну мы же моделируем ситуацию, что старые тесты выкинули ?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, minorlogic, Вы писали:
M>>>А если вы решили переиспользовать код УЭ в другом проекте , в другом сценарии? опять в третий раз писать одни и теже тесты ?
КБ>>Если такое произошло, значит интерфейс УЭ достаточно стабилен и можно откопать старые
M>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
Здравствуйте, Константин Б., Вы писали:
M>>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
КБ>В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
Здравствуйте, Константин Б., Вы писали:
L>>Зато они будут сложнее, на написание уйдет больше времени и будет сложнее локализовать ошибки.
КБ>Тесты для кода использущего угла писать все равно придется. Сложность их будет такая же. Время потрачено будет то же.
Нет, сложность интеграционных тестов будет гораздо сложнее и времени уйдет гораздо больше.
КБ>А ошибки легко локализуются по логам системы контроля версий.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Константин Б., Вы писали:
M>>>Ну мы же моделируем ситуацию, что старые тесты выкинули ?
КБ>>В svn'е то остались. Хотя наверное разумнее будет выкинуть эти тесты не сразу, а когда они начнут мешать.
M>"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
Ну например изменили интерфейс этих самых углов. Теперь два варианта 1) рефакторить юнит-тесты 2) выкинуть юнит-тесты
Здравствуйте, Константин Б., Вы писали:
M>>"В svn'е то остались." это не выкинули , это как раз и есть самый что ни на есть юнит тест. А отчего они мешать то могут начать? какой сценарий? лежат себе, кашки не просят, запускать не требуют.
КБ>Ну например изменили интерфейс этих самых углов. Теперь два варианта 1) рефакторить юнит-тесты 2) выкинуть юнит-тесты
В этом случае я бы подстраховался и хотел бы как минимум запустить старые тесты на новом интерфейсе, чтобы убедиться что ничего не поломал , ничего не забыл. Мне этот вариант кажется более выигрышным .
AndrewVK,
G>>Один с IoC — с формальными требованиями по функционалу, их неформально описать даже не получится
AVK>Так, ты кажется что то не понимаешь. Формальные требования к функционалу меня не колышат. Потому что они примитивны. Меня колышет внешний дизайн фреймворка. Я же ведь не зря акцентировал на том, что собственно реализация там смешная и очевидная. Вопрос в том, каков должен быть дизайн, и как, не имея этого дизайна, написать тесты. Вот это вопрос из вопросов.
Я вот тут наткнулся про разработку IOC контейнера на основе TeDD. Это видеотрейс из 9 частей, где Daniel Cazzulino (создатель фреймворка Moq) в реальном времени лабает контейнер под названием Funq, и одним из нефункциональных требований есть перфоманс (он хочет сделать всех, и по последним тестам Funq всего-лишь в 2.5 раза медленнее чистого создания объектов), а другим — чтобы было красиво и статически типизировано (не так убого, как в Unity или, там, в Spring.net).
Хотя даже после просмотра что-то мне не нравится в TeDD. И складывается ощущение, что у kzu на момент тестов уже была достаточно чёткая картина, и он просто подгонял тесты под умственную модель, а потом и сам код. То есть, на мой взгляд, ему ничто не мешало поступить наоборот — сначала код, потом тесты. Тем не менее интересно, и вдобавок подумываю о переходе Autofac -> Funq.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Хотя даже после просмотра что-то мне не нравится в TeDD. И складывается ощущение, что у kzu на момент тестов уже была достаточно чёткая картина, и он просто подгонял тесты под умственную модель, а потом и сам код. То есть, на мой взгляд, ему ничто не мешало поступить наоборот — сначала код, потом тесты. Тем не менее интересно, и вдобавок подумываю о переходе Autofac -> Funq.
Поступать наоборот крайне неэффективно. так как написав тесты до кода ты сразу же ограничиваешь необходимый функционал и создаешь критерий завершения работы.
Про это тут написано — http://www.rsdn.ru/forum/philosophy/3435925.aspx
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
