Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, landerhigh, Вы писали:

L>>Здравствуйте, iHateLogins, Вы писали:

HL>>>или вот еще:
HL>>>

HL>>>[TestMethod]
HL>>>public void TestCustomerObject()
HL>>>{
HL>>>   Customer c = new Customer();
HL>>>   c.ID = 1;
HL>>>   c.Name = "Vasya";
HL>>>   c.Create();
HL>>>   Customer c2 = GetCustomerByID(1);
HL>>>   Assert.AreEqual(c.Name, c2.Name);
HL>>>}
HL>>>

L>>Отлично.

L>>1. Если конструктор Customer() кинет исключение, тест не пройдет.
L>>2. Если Create() кинет исключение, тест не пройдет
L>>3. Если GetCustomerById() вернет что-то отличное от ожидаемого, тест провалится.
L>>4. Если впоследствии кто-то умный решит играться регистром имен в конструкторах, сеттерах или еще где, тест свалится

L>>Нормальный тест.

КБ>Любой интеграционный тест использующий Customer и GetCustomerById проверит то же самое.
Не любой, а каждый. И не просто проверит, а обязан проверять.

КБ>Зачем отдельный юнит-тест?
Затем чтобы не писать кучу ненужного кода.

Здравствуйте, Пацак, Вы писали:

П>Здравствуйте, Константин Б., Вы писали:

КБ>>Для меня фраза "интерфейс определяется тестами" — бессмыслица. Если функциональные тесты еще хоть как-то можно вывести из функциональных требований, то юнит-тесты проектируются "из головы", а то и подгоняются под уже придуманный интерфейс.

П>Вот именно так и получается: тесты выдумываются "из головы" — и в это время в голову приходит понимание того, каким должен быть интерфейс.
П>Просто тест — это уже в каком-то смысле использование модуля, а практика показывает, что как бы хорошо модуль не был спроектирован и написан — с момента начала его эксплуатации о нем неминуемо узнаешь много нового и рука сама тянется к кнопке "переделать нафиг". Тесты позволяют нажать на эту кнопку чуть раньше — только и всего...

Если рука тянется к кнопке "переделать нафиг" значит модуль все таки был спроектирован плохо. Что если в реальности модуль будет использоваться не так как в тестах?

КБ>>Нет. Но презентация запрещает писать один тест на несколько классов.

П>Презентацию не смотрел ввиду угребищности ее формата, поэтому на всякий случай уточню: прям вот так вот и запрещает? Или просто говорит о том, что это неудобно?

Она говорит — что это уже не юнит-тест, а интеграционный тест, а значит это уже не так круто как юнит-тест, а что бы это был все-таки юнит-тест надо делать моки.

П>Просто на самом деле в большинстве случаев оно именно так и есть — проще написать два похожих теста для двух разных сущностей, чем потом пялиться на красную полоску и гадать — "а из-за кого она на этот раз?"

По вашему лучше пялиться на красную полоску и гадать "а что за тест на это раз упал?"?. Или все-таки лучше взглянуть на лог тестирования?

А ошибку вы будете исправлять силой мысли? Или все таки на сорцы взгляните?

Нет никакой разницы один там тест или десять если покрытие у них одинаковое.

Здравствуйте, Константин Б., Вы писали:

Б>Если рука тянется к кнопке "переделать нафиг" значит модуль все таки был спроектирован плохо.
Естественно, но с тестами ты гораздо раньше об этом узнаешь.

Б>Что если в реальности модуль будет использоваться не так как в тестах?
такое бывает при восходящем проектировании. если использовать нисходщее проектирование, то напимсанные пекред кодом тесты — и есть реальные сценарии использования.

КБ>Нет никакой разницы один там тест или десять если покрытие у них одинаковое.
Какое покрытие? Code Coverage, замеренное инструментально? Оно вообще-то слабо коррелирует с покрытием сценариев.

Чтобы добиться одинаковое покрытие сценариев кучки связаанных модулей понадобится гораздо больше интеграционных тестов написать.

Здравствуйте, gandjustas, Вы писали:

КБ>>Ну и ладно. Можно же просто рассказать о моках, о их пользе. А само применение моков оставить на усмотрение разработчика.
G>Но это все же презентация, в ней надо побольше громких, желательно безапелляционных, заявлений делать.
G>Ведь если честно все рассказать в презентации или в книге, то большинство скажет что это и так известно (что на самом деле является очень хорошей характеристикой). Хотя потом еще лет 10 цитировать будут.

Похоже кое-то тут в КСВ руководствуется этим же принципом. Сделать по больше громких, безапелляционных заявлений. На заявления "эти принципы применимы не всегда" — отвечать "нет, всегда". А на конкретные контрпримеры — "ну дык не надо слепо следовать принципам".

КБ>>>>Может тогда ну их нафиг эти правила, а?
G>>>Нет, нафиг такой подход, когда читаешь кучу таких "правил", а потом слемо им следуешь.
G>>>Это называется культ карго
КБ>>А нафига правила если им нельзя следовать?
G>Можно. Почитай по ссылке.

Так вы уж определитесь можно им следовать или нет. "Можно, но не совсем" = "Нельзя"

G>>>На практике человек не может обычно написать тесты для всех сценариев A и B, может получиться так что A использует B таким образом, что B в таком сценарии не тестировался.
КБ>>Ага. Поэтому интеграционные тесты — рулят
G>Совсем не рулят. Потому что если не человек не смог для изолированных компонент написать достаточно полный test-suite, то в случае тестирования группы компонент он вряд ли покроет тестами даже 10% сценариев.

А кто сказал, что "не смог"? Может просто решил не тратить зря время. И обоснуйте пожалуйста вашу оценку в 10%.

G>Вообще интеграционные тесты дают рост экспоненциальный количества тестов при увеличении связности и количества компонент.

Как показывает практика — не дают.

G>Тогда как количество unit-тестов растет линейно. Это уже не говоря о том что unit-тесты гораздо проще в написании, чем интеграционные.

Ну да. Моки там фигачить. Лишние интерфейсы вводить. Офигеть просто как проще.

КБ>>>>Ага. Но вместо того чтобы это объяснить, придумываются глупые правила.
G>>>Сложно объяснять как правильно писать тесты, это также сложно как правильно писать код.

КБ>>Тесты надо писать так:
КБ>>1. Чтобы они запускались автоматически
КБ>>2. Чтобы тестировали то что нужно.

G>Всего-то
G>А как определить что нужно тестировать?

Юнит-тесты ответа на это вопрос не дают.

G>А как писать тесты так, чтобы они не стали обузой?

Юнит-тесты ответа на это вопрос не дают.

G>А когда вообще писать тесты?

А вот это пофиг.

G>...
G>продолжать можно долго.
G>Для полноценной методаки тестирования нужно гораздо больше формализма и при этом должно быть понимание зачем это все делается.

Только вот ваш формализм плюет на эти вопросы.

КБ>>А будут ли они юнит или интеграционными, с моками или без — какая разница? Этому вопросу помоему уделяется неоправдано много внимания.

G>Я думаю что этому вопросу уделяется слишком мало внимания, так как ответы на такие вопросы делают тестирование эффективным.

Каким образом?

G>>>Я уже писал что самый лучший способ изучать TDD — смотреть видеозаписи о том как люди пишут код по TDD.
КБ>>А нужно ли вообще изучать TDD? Это пока вопрос открытый
G>Изучать по-любоу нужно

Зачем? Что такое TDD — вы не знаете. Как отличить TDD от не TDD — вы не знаете. Область применимости TDD — вы не знаете. Альтернатив вы кстати то же не знаете. Преимущества — сомнительны. Зачем вот ЭТО изучать?

Здравствуйте, gandjustas, Вы писали:

КБ>>Любой интеграционный тест использующий Customer и GetCustomerById проверит то же самое.
G>Не любой, а каждый. И не просто проверит, а обязан проверять.

Можете написать любой хоть сколько нибудь осмысленный тест использующий Customer и GetCustomerById, который этого не проверит? Я вот не могу. Так зачем это еще и отдельно проверять?

КБ>>Зачем отдельный юнит-тест?
G>Затем чтобы не писать кучу ненужного кода.

Ненужный код — вот этот самый юнит-тест.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Константин Б., Вы писали:

Б>>Если рука тянется к кнопке "переделать нафиг" значит модуль все таки был спроектирован плохо.
G>Естественно, но с тестами ты гораздо раньше об этом узнаешь.

А может стоит все-таки проектировать хорошо?

Б>>Что если в реальности модуль будет использоваться не так как в тестах?
G>такое бывает при восходящем проектировании. если использовать нисходщее проектирование, то напимсанные пекред кодом тесты — и есть реальные сценарии использования.

Тогда нафига юнит-тесты?

КБ>>Нет никакой разницы один там тест или десять если покрытие у них одинаковое.
G>Какое покрытие? Code Coverage, замеренное инструментально? Оно вообще-то слабо коррелирует с покрытием сценариев.

А тебе с каким смыслом сложнее поспорить, вот тот и выбирай.

G>Чтобы добиться одинаковое покрытие сценариев кучки связаанных модулей понадобится гораздо больше интеграционных тестов написать.

Практика показывает обратное

Здравствуйте, iHateLogins, Вы писали:

___>>>СУБД — да это определяется сразу. А вот перекидывать с одной СУБД на другую — тот еще гемор — заказчик посылается в лес.
I>>Интересный подход однако, посылать заказчика. Жалко в ЖКХ где работает мой отец, об этом не знали. А то MSSQL выдохся и перешли на Оракл.

HL>Ну так если не знать как оптимизировать SQL Server, то переход на оракл не поможет. Это раз.

А с чего ты взял что они чего то не знали с MSSQL ? Они не знали как послать заказчика.

HL>А во-вторых, лучше бы ЖКХ лучше занималось своими непосредственными задачами и уважало своих клиентов (владельцев квартир), а не занималось откатной хернёй с переходом на оракл (который стоит где-то в 20 раз дороже SQL Server).

Я вижу у тебя очень ловко получается решать задачи ничего не зная об условии оной. Продолжай !

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, gandjustas, Вы писали:

КБ>>>Ну и ладно. Можно же просто рассказать о моках, о их пользе. А само применение моков оставить на усмотрение разработчика.
G>>Но это все же презентация, в ней надо побольше громких, желательно безапелляционных, заявлений делать.
G>>Ведь если честно все рассказать в презентации или в книге, то большинство скажет что это и так известно (что на самом деле является очень хорошей характеристикой). Хотя потом еще лет 10 цитировать будут.

КБ> Похоже кое-то тут в КСВ руководствуется этим же принципом. Сделать по больше громких, безапелляционных заявлений. На заявления "эти принципы применимы не всегда" — отвечать "нет, всегда". А на конкретные контрпримеры — "ну дык не надо слепо следовать принципам".

КБ>Так вы уж определитесь можно им следовать или нет. "Можно, но не совсем" = "Нельзя"

Ты путаешь принципы и сформулированные кем-то правила.

КБ>А кто сказал, что "не смог"? Может просто решил не тратить зря время. И обоснуйте пожалуйста вашу оценку в 10%.
Я уде приводил расчеты. С ростом связности системы количестве интеграционных тестов растет экспоненциально, а количество юнит-тестов почти линейно.
Соотвественно начиная с некоторого уровня сложности написание и поддержка интеграционных тестов станет непозволительно дорогоим занятием.
Поэтому по правилу 20\80 будет написано 20% тестов, которые реально покрывают только 10% наиболее вероятных сценариев.

G>>Вообще интеграционные тесты дают рост экспоненциальный количества тестов при увеличении связности и количества компонент.
КБ>Как показывает практика — не дают.
Ну если практика заключается в неписании тестов, то да.

G>>Тогда как количество unit-тестов растет линейно. Это уже не говоря о том что unit-тесты гораздо проще в написании, чем интеграционные.
КБ>Ну да. Моки там фигачить. Лишние интерфейсы вводить. Офигеть просто как проще.
А с чего ты взял что интерфейсы лишние? И в чем сложность моков? С моками тесты становятся гораздо понятнее, так как поведение связанного компонента описывается рядом с тестом.

КБ>>>Тесты надо писать так:
КБ>>>1. Чтобы они запускались автоматически
КБ>>>2. Чтобы тестировали то что нужно.

G>>Всего-то
G>>А как определить что нужно тестировать?

КБ>Юнит-тесты ответа на это вопрос не дают.
Еще как дают — любой нетривиальный кусок кода, не завязанный на внешние компоненты.

G>>А как писать тесты так, чтобы они не стали обузой?
КБ>Юнит-тесты ответа на это вопрос не дают.
Дают — писать тесты надо до кода, писать тесты для одного изолированного модуля.

G>>А когда вообще писать тесты?
КБ>А вот это пофиг.
Совсем нет. Если изначально дизайн не рассчитан на тестирование, то потом написать тесты, особенно unit-тесты будет нереально сложно.
Обратное также верно, если тесты написаны до кода, то дизайн будет лего поддваваться тестированию. А это означает более низнкую связсность системы.


G>>...
G>>продолжать можно долго.
G>>Для полноценной методаки тестирования нужно гораздо больше формализма и при этом должно быть понимание зачем это все делается.
КБ>Только вот ваш формализм плюет на эти вопросы.
См выше. Он дает настолько простые ответы, что ты до сих пор понять не можешь этого.

КБ>>>А будут ли они юнит или интеграционными, с моками или без — какая разница? Этому вопросу помоему уделяется неоправдано много внимания.
G>>Я думаю что этому вопросу уделяется слишком мало внимания, так как ответы на такие вопросы делают тестирование эффективным.

КБ>Каким образом?
Таким что правльно написанные тесты очень сильно помогают в разработке и не требуют дофига времени на поддержку.

G>>>>Я уже писал что самый лучший способ изучать TDD — смотреть видеозаписи о том как люди пишут код по TDD.
КБ>>>А нужно ли вообще изучать TDD? Это пока вопрос открытый
G>>Изучать по-любоу нужно

КБ>Зачем? Что такое TDD — вы не знаете. Как отличить TDD от не TDD — вы не знаете. Область применимости TDD — вы не знаете. Альтернатив вы кстати то же не знаете. Преимущества — сомнительны. Зачем вот ЭТО изучать?

Все тут когда-то программирования не знали, и области его применения тоже, вот зачем его изучили?

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, gandjustas, Вы писали:

КБ>>>Любой интеграционный тест использующий Customer и GetCustomerById проверит то же самое.
G>>Не любой, а каждый. И не просто проверит, а обязан проверять.

КБ>Можете написать любой хоть сколько нибудь осмысленный тест использующий Customer и GetCustomerById, который этого не проверит? Я вот не могу. Так зачем это еще и отдельно проверять?
Ну для какого-то конкретного класса может ваши тесты все будут проверять, а в общем случае замучаетесь одно и тоже писать.

КБ>>>Зачем отдельный юнит-тест?
G>>Затем чтобы не писать кучу ненужного кода.

КБ>Ненужный код — вот этот самый юнит-тест.
Юнит-тест — один и короткий, ты предлагаешь дублировать кучу кода вовсех интеграционных тестах.

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Константин Б., Вы писали:

Б>>>Если рука тянется к кнопке "переделать нафиг" значит модуль все таки был спроектирован плохо.
G>>Естественно, но с тестами ты гораздо раньше об этом узнаешь.

КБ>А может стоит все-таки проектировать хорошо?
Ага, напиши методику, которая тебе гарантированно даст хороший дизайн в любом случае.


Б>>>Что если в реальности модуль будет использоваться не так как в тестах?
G>>такое бывает при восходящем проектировании. если использовать нисходщее проектирование, то напимсанные пекред кодом тесты — и есть реальные сценарии использования.
КБ>Тогда нафига юнит-тесты?
Так описанные выше тесты — и есть unit-тесты.


G>>Чтобы добиться одинаковое покрытие сценариев кучки связаанных модулей понадобится гораздо больше интеграционных тестов написать.
КБ>Практика показывает обратное
Ну если практика заключается в неписании тестов, то да.

Здравствуйте, Ikemefula, Вы писали:

ВВ>>Обычно вообще-то переход, скажем, на 10g превращается в масштабный и сложный проект и вовсе не потому, что там "бизнес-логика" в базе.
I>Поясни.

Ну потому что не переходят обычно "просто так" Многие приложения в огромных компаниях часто крутятся на древних СУБД. И представьте, что вы какую-нибудь систему "документооборота" хотите перевести с антикварного Оракла. А там все документы хранятся в ЛОНГЕ, который а) не поддерживает транзакции и б) имеет ограничения по размеру. И таких нюансов может быть множество.

Здравствуйте, _d_m_, Вы писали:

___>Отвечу всем: ну не будем переписывать проект с нуля, т.к. линк такой вот прекрасный.

Какой проект? Отвечай всем в другой ветке, я никакой такой конкретный проект не обсуждал.

___> Тем более: то он разрабатывается, то его там вроде хотели закрыть, а то опять он ожил. А MS SQL и его оптимизатор будут, и оптимизатор будут подтягивать.

Пока Вилла Риба ждет улучшения оптимизатора, Вилла Баджо зрабатывает бабки.

Здравствуйте, yuriylsh, Вы писали:

Y>Спрашивай, если хочеться. Мне абсолютно не интересно, что он по этому поводу считает.

5 баллов. Конечно, куда удобнее приписать собеседнику то, что он не говорил, и потом с блеском громить несуществующую позицию. Браво.

Y> К словам, на которые я отвечал этот вопрос не имеет никакого отношения.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну потому что не переходят обычно "просто так" Многие приложения в огромных компаниях часто крутятся на древних СУБД. И представьте, что вы какую-нибудь систему "документооборота" хотите перевести с антикварного Оракла. А там все документы хранятся в ЛОНГЕ, который а) не поддерживает транзакции и б) имеет ограничения по размеру. И таких нюансов может быть множество.

Понял, спасибо.

Мне это напоминает выкрики MS фанбоев в 2003 году, когда все хотели похоронить HTML и везде запихнуть XAML. Типа более новое, managed, векторное и пр.

И, простите, где ваш XAML? А вот HTML еще жив, курилка, новая версия выходит (HTML5), более того, веб-девелоперы сейчас куда как более внимательно относятся к HTML.

LINQ — изобретение чисто майкрософтовское, поэтому настоящего девелоперского комьюнити вокруг него не будет никогда. А SQL жил, жив, поддерживается в триллионе баз данных и срать хотел с колокольни на ваш линк.

Еще полгода назад MS хотел депрекейтнуть этот l2s, EF же в настоящий момент вообще не предназначен для какой-либо серьёзной работы.

В любом случае, поживём — увидим.

Здравствуйте, iHateLogins, Вы писали:

HL>Здравствуйте, Eugeny__, Вы писали:

___>>>И это вобще-то ни мега-запрос, как тут уже сказали, запрос прост... Для тех кто в теме.

E__>>Он может и прост, но выглядит довольно монструозно. А это само по себе плохо. Насколько я понимаю, linq создавался в том числе и для того, чтобы запросы выглядели не столь монстряче.

HL>Может это от того, что вы просто не знаете t-sql?

Да, я действительно досконально, до мелочей его не знаю, хотя когда-то работал с ms-sql(хотя больше довелось с ms-sql ce, но это другая история) — мне с проблемами производительности сталкиваться не приходилось, хотя логику я максимально выносил в гораздо более читабельный C#(тем самым запросы были вроде "select a,b from c where d=e").
Приведенный код реально макаронный.

HL>Те кто в теме запрос понимают за 30 секунд.

Вот вот.
Понимаешь, современные языки и технологии стремятся к тому, что для того, чтобы прочесть код, не нужно быть гуру этого языка. Я могу понять, что там происходит, но меня воротит от одного вида такого кода.

Здравствуйте, iHateLogins, Вы писали:

HL>LINQ — изобретение чисто майкрософтовское, поэтому настоящего девелоперского комьюнити вокруг него не будет никогда.

Угу. Как нет таких комьюнити вокруг .net, DX, MS SQL...

HL>А SQL жил, жив

Какой именно из?

Здравствуйте, iHateLogins, Вы писали:

HL>Мне это напоминает выкрики MS фанбоев в 2003 году, когда все хотели похоронить HTML и везде запихнуть XAML. Типа более новое, managed, векторное и пр.

HL>И, простите, где ваш XAML? А вот HTML еще жив, курилка, новая версия выходит (HTML5), более того, веб-девелоперы сейчас куда как более внимательно относятся к HTML.
Наш замл живет и здравствует. WPF и Silverlight базируются на замле. На WPF написаны кроме прочего интерфейсы AutoCAD и VS 2010.

Смотрите только — галстуком не поперхнитесь от такой-то новости...

Здравствуйте, criosray, Вы писали:

HL>>Мне это напоминает выкрики MS фанбоев в 2003 году, когда все хотели похоронить HTML и везде запихнуть XAML. Типа более новое, managed, векторное и пр.

HL>>И, простите, где ваш XAML? А вот HTML еще жив, курилка, новая версия выходит (HTML5), более того, веб-девелоперы сейчас куда как более внимательно относятся к HTML.
C>Наш замл живет и здравствует. WPF и Silverlight базируются на замле. На WPF написаны кроме прочего интерфейсы AutoCAD и VS 2010.

Интересно, сколько сайтов используют WPF или СЛ? 0.01%? 0.1%?

Что касается автокада, то на впф там написан только тулбар, да еще мс отвалила кууучу баблосов аутодеску чтобы те засунули этот несчастный wpf в автокад.

Здравствуйте, iHateLogins, Вы писали:

HL>>>Мне это напоминает выкрики MS фанбоев в 2003 году, когда все хотели похоронить HTML и везде запихнуть XAML. Типа более новое, managed, векторное и пр.

HL>>>И, простите, где ваш XAML? А вот HTML еще жив, курилка, новая версия выходит (HTML5), более того, веб-девелоперы сейчас куда как более внимательно относятся к HTML.
C>>Наш замл живет и здравствует. WPF и Silverlight базируются на замле. На WPF написаны кроме прочего интерфейсы AutoCAD и VS 2010.

HL>Интересно, сколько сайтов используют WPF или СЛ? 0.01%? 0.1%?
Этим технологиям полтора года от роду фактически. Конечно же потребуется время, чтоб они набрали обороты.

HL>Что касается автокада, то на впф там написан только тулбар,
Кто Вам эту чушь сказал?

HL>да еще мс отвалила кууучу баблосов аутодеску
Доказательства будут или очередной плод Вашего воспаленного воображения?

HL>чтобы те засунули этот несчастный wpf в автокад.
Вам не надоело еще писать глупости?