Здравствуйте, criosray, Вы писали:
V>>Ты еще забыл кодеки, мультимедиа, реалтайм протоколы и т.д. И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ
C>Пример классического ламеризма. Может стоило бы для начала что-то узнать о предмете обсуждения? Например, что версия CLR все еще 2.0.х, а не 3.0
Насколько я понял, ты просто не в курсе какие тут шли обсуждения сразу после выхода второго фреймворка. Порой заносило даже весьма уважаемых мною коллег (уажаемых за то, что их обычно не заносит). А ламеризм — это когда читают оппонента, и при этом десятое сообщение подряд совершенно не втыкают, о чем речь... Речь о том, что мы все унутренне готовились к несколько другому развитию событий, а оно вишь как вышло — застряли малость.
И вот это твое замечание насчет версий фреймворков... неожиданный ход, прямо скажем.
Я только не понял, какую мою мысль должен был опровергнуть твой выпад, не пояснишь нам, убогим?
Здравствуйте, vdimas, Вы писали:
V>>>Ты еще забыл кодеки, мультимедиа, реалтайм протоколы и т.д. И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ
C>>Пример классического ламеризма. Может стоило бы для начала что-то узнать о предмете обсуждения? Например, что версия CLR все еще 2.0.х, а не 3.0
V>Насколько я понял, ты просто не в курсе какие тут шли обсуждения сразу после выхода второго фреймворка. Порой заносило даже весьма уважаемых мною коллег (уажаемых за то, что их обычно не заносит). А ламеризм — это когда читают оппонента, и при этом десятое сообщение подряд совершенно не втыкают, о чем речь... Речь о том, что мы все унутренне готовились к несколько другому развитию событий, а оно вишь как вышло — застряли малость.
V>И вот это твое замечание насчет версий фреймворков... неожиданный ход, прямо скажем. V>Я только не понял, какую мою мысль должен был опровергнуть твой выпад, не пояснишь нам, убогим?
Вы даже не знаете разницы между фреймворком и CLR. Продолжайте писать в таком же духе — это становится очень забавно.
Ламеризм это когда человек делает много громких заявлений, имея очень слабое представление о предмете обсуждения. То, что мы и наблюдаем в Вашем случае.
Здравствуйте, vdimas, Вы писали:
VD>>С++ же используется в последнее время больше частью для создания высокотиражных продуктов где стоимость разработки не так важна
V>Правда твоя, он теперь преимущетсвенно используется для разработки высококачественного софта, и в каждую дырку его теперь не суют, что не может не радовать.
Не надо перевирать мои слова. Я о высоком качестве, как и вообще о качестве, не говорил.
VD>>так как окупается количеством продаж (т.е. — игры, ОС, офисные приложения), а меньшее потребление компьютерных ресурсов может увеличить объем продаж.
V>Ты еще забыл кодеки, мультимедиа, реалтайм протоколы и т.д. И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ
Я ничего не забывал. Я не ставил себе задачей перечислить все мелкие подниши. Кодеки можно смело отнести к системному софту (в купе с дровами). "мультимедиа" — это что-то очень абстрактное. Ну, а риалтайм тут не в кассу. Он и на Руби более чем возможен.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, criosray, Вы писали:
V>>Просто надо четко понимать, что автоматически-генерённые моки — это костыль по сути, для ситуаций чудесного дизайна, когда одно гвоздями прибито к другому.
C>С точностью до наоборот — нормальные моки и стабы генерируются автоматически. т.к. автоматическая генерация исключает возможность допустить ошибку или не учесть чего-то.
Расшифруй, пожалуйста, слово "нормально" и слово "автоматически", а так же набор возможностей этого "автоматически".
V>>А так, там где можно обойтись в юнит-тестах классичесскими ассертами — это и синтаксис нагляднее, и проще поддерживать. C> C>Вы вообще не понимаете что такое юнит-тесты. Не надоело показывать неграмотность?
А да, что такое юнит-тесты требуется еще и понимать... Не надоело рефлексировать и показывать в очередной раз свой поверхностный взгляд? Все твои вызовы мокков ради ассертов, собственно и сделаны. И хоть они теперь не в фас, а в профиль — они были и есть цель любого автоматического теста (не обязательно юнит...)
V>>У нас в последней системе в центре тупой диспетчер сообщений, и все тупо шлют в систему сообщения, никто ни о ком не знает... что по одиночке, что в любой комбинации прекрасно все тестируется, и произвольные тестовые заглушки прекрасно пишутся с логикой произвольной сложности, которая автомокам и не снилась.
C>Перечень того, что не возможно сделать средствами RhinoMocks + xUnit в студию, как говорится.
Любую динамическую среду/заглушки, которые генерят переменный по насыщенности траффик или сообщения с разной задержкой и произвольным наполнением. Фишка в том, что реальных задержек-то и нет, текущее время эмулируется, но тестирующая последовательность слишком длинная, чтобы записывать её ручками, она генерируется программой. А таких последовательностей/программ у меня — мама не горюй.
Далее, обмен сложными структурами данных заглушки и тестируемого объекта, у объекта приличное пространство состояний, на что заглушка должна грамотно реагировать, т.е. приличная иногда логика на if-ах и case-ах. В декларативном синтаксисе мокков это выглядит как удаление гландов через Ж, и чем осмысленнее логика — тем более глубокое погружение в эту Ж. А если процедура внешняя, то это лишняя тестирующая сущность и все такое.
А теперь смотри что получается: автомоками удобно пользоваться для оформления относительно несложных тестов, где внешние условия и реакцию на них вполне можно описать декларативно и синтаксис все еще не будет раздражать. Т.е. типа, сказали ему "открой рот", убедились что рот открыт, далее "скажи А", убедились, что сказал А. Не много ли чести для подобной возни? У меня в одном методе юнит-теста дружно открывают рты сразу два десятка подобных объектов. Найди мне смысл оформлять отдельный юнит-тест, если затраты на оформление сравнимы со сложностью теста. Тоже самое с автомоками, я слишком часто вижу, что их используют в тех самых случаях, где одно-дву-строчного Assert из nUnit более чем достаточно.
Ах да, чуть не забыл... разумеется без них практически никак, если у кого-то был неудержимый понос на Ынтерфейсы в период дизайна. Собственно для них в первую очередь оно и есть.
Здравствуйте, vdimas, Вы писали:
V>С какой это радости система типов более мощная? ИМХО, гораздо более простая, в плане параметрических типов (мощная она по сравнению с Nemerle разве что). Или ты считаешь, что если пользовательские типы ограничить только до алгебраических, то система типов от этого мощнее становится? Она становится проще гораздо и ограниченнее.
Иди разберись, что такое система типов. Потом поговорим. Nemerle же использует систему типов .net, которая принципиально не допускает вычислений (как Хаскель и С++). Только Nemerle это и не нужно. У него есть своя система метапрограммирования работающая во время компиляции.
VD>>2. Есть куда более мощные синтаксические препроцессоры (например, Nemerle и Лисп) которые по возможностям и удобству рвут С++ как тузик грелку. К примеру, я воспроизвел linq из спецификации C# написав два макроса. С++ такое сделать не может в приципе.
V>И? 99.99% языков такое сделать не могут в принципе, ибо давать дорабатывать компилятор простым программистам — это спорное занятие. Не зря на Лиспе и Форте не так уж много людей лабали.
Ну, вот С++ к этим процентам и относится. Хотя процент несколько завышен. Почти любой скриптовый язык обладает не хилыми возможностями МП.
V>С# 5/6/7 тоже мочь не будет однозначно, эта фишка "не на каждый день", в массы его вряд ли выпустят.
Ага. Обезьяны с дубинами не доросли. Даш им оружие по мощнее и они себе что-нить отстрелят .
V>Дженерики слабее на порядок примерно, не знаю, откуда ты берешь свое "лучше"?
Ты уж разберись. Или у Nemerle более мощная система типов (а за одно и у C#, так как она у них единая, практически), или "Дженерики слабее на порядок".
Подсказка. МП и система типов не обзяательно должны быть связаны.
V> Банально хрен обобщишь алгоритм на float и на double, а тебе от этого лучше.
О, как. А мужики то и не знали. Хочешь я тебя научу обобщать алгоритмы на любом языке поддерживающем лямбды и/или generic-интерфейсы?
V> Реально и с размахом эти дженерики используются только по одному назначению — улучшить статическую типизацию, дабы меньше было динамической или тупого боксинга на ровном месте — офигенная, однако, у нас разновидность полиморфизма-то.
О, как? Еще одно противоречие. Ты уж определись или дженерики не позволяют обобщать алгоритмы, или они могут улучшить статическую типизацию. Это как бы два друг-другу протеворечащих заявления.
V>У меня за эти годы сложилось четкое убеждение, что дженерики — это способ обходить перечисленные недостатки платформы .Net, не более того.
У тебя за эти годы сложилось много каши в голове .
VD>>А уж параметрический полиморфизм в современных ФЯ сделан несравнимо лучше шаблонов С++.
V>Голословие. Если по возможностям — то так же или хуже (где есть явная специализация — то примерно так же, где нет — хуже). "Лучше" разве что по минималистическому синтаксису всего одного языка. Дык по этому критерию и Немерле — убожество еще то.
Тебе конечно виднее. Когда в руках молоток, то все вокруг кажется гвоздями.
VD>>Просто использование шаблонов выходит за рамки параметрического полиморфизма и входят в область метапрограммирования. Но в этой области безоговорочно царят макросы. И убогим возможностям С++ тут делать не чего.
V>Ты то отсылаешь к Хаскелю и ОКамлу, то называешь языки без макросов убогими (значит и их тоже). А ведь системе типов Немерле даже до Хаскельной как до луны раком. В общем, более чем сумбурно.
Ты кашку из головки вынь и попытайся систематизировать знания. Тогда поймешь, что система типов и система МП — это разные вещи. И можно спокойно иметь слабую систему типов и сильную систему МП (как в Лиспе, например), или наоборот сильную систему типов и слабую МП (Хаскель).
VD>>Если же серьезно говорить о метапрограммировании, то С++ тут откровенный лузер, если сравнивать его с такими языками, реализованными поверх дотнета, как Nemerle и Lisp. Вот где МП доведено до высшего пилотажа. Причем оно исходно предусмотрено в языка, а не достигается использованием побочных эффектов системы типов.
V>Не надо из МП делать священную корову, иногда и просто попрограммировать надо. У вас в том большом реальном проекте доля МП так себе, прямо скажем. А все остальные многие и многие тыщщи строк делать на Лиспе — увольте и в пример больше не приводите.
Как говорится "слив зачитан".
V>И что касается макросов, то Лисп тут проигрывает даже Форту, по удобству пользования этой фичей... Так что, отличное вышло у тебя пюре, надо сказать.
Гы-гы. Расскажи это лиспарям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
V>>Я только не понял, какую мою мысль должен был опровергнуть твой выпад, не пояснишь нам, убогим?
C>Вы даже не знаете разницы между фреймворком и CLR.
Так пояснишь или нет?
Заодно и последнее.
C>Ламеризм это когда человек делает много громких заявлений, имея очень слабое представление о предмете обсуждения. То, что мы и наблюдаем в Вашем случае.
Для 11 лет практики маловато конкретики, ближе к телу.
Здравствуйте, VladD2, Вы писали:
VD>Не надо перевирать мои слова. Я о высоком качестве, как и вообще о качестве, не говорил.
Да ладно, красиво же было сказано, я не удержался.
VD>Я ничего не забывал. Я не ставил себе задачей перечислить все мелкие подниши. Кодеки можно смело отнести к системному софту (в купе с дровами). "мультимедиа" — это что-то очень абстрактное. Ну, а риалтайм тут не в кассу. Он и на Руби более чем возможен.
Может и возможен, но тот же VoIP сервак потянет на порядок меньше клиентов.
-----------
А вообще, не находишь странным спустя лет 5 примерно, пройтись по тем же темам?
У меня, например, вообще любимого языка нет. Использую активно С# и С++, но к обоим достаточно претензий. И к Немерле тоже, разумеется.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Не надо перевирать мои слова. Я о высоком качестве, как и вообще о качестве, не говорил.
V>Да ладно, красиво же было сказано, я не удержался.
Перевиравшие слов — это красиво.
Скажи, ты действительно не понимаешь, что подмена понятий и несвязанные выводы — это средство получать лживые выводы? Или ты намеренно пытаешься добиться лжи?
V>Может и возможен, но тот же VoIP сервак потянет на порядок меньше клиентов.
Слово "риалтамй", которое ты тут не к месту упомянул, не имеет никакого отношения к производительности.
Кстати, само заявление тоже высосано из пальца.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Иди разберись, что такое система типов. Потом поговорим. Nemerle же использует систему типов .net, которая принципиально не допускает вычислений (как Хаскель и С++). Только Nemerle это и не нужно. У него есть своя система метапрограммирования работающая во время компиляции.
Во первых да, параметризацию Хаскеля, так же как и шаблоны С++ в бинарную сборку не запихаешь (отчего Хаскеля и нет на .Net), ну дык кто мешает распространять так же как шаблонные библиотеки на С++ — в исходниках?
Во вторых, я дал реплику относительно твоего заявлени о "мощности" системы типов Хаскеля относительно С++. Хотел бы увидеть эту мощность, помимо встроенных алгебраических типов.
V>>С# 5/6/7 тоже мочь не будет однозначно, эта фишка "не на каждый день", в массы его вряд ли выпустят.
VD>Ага. Обезьяны с дубинами не доросли. Даш им оружие по мощнее и они себе что-нить отстрелят .
Да вполне нормальный ситуейшн и изменений в обозримом будущем не предвидится. На таких лего-компиляторах как Немерле надо делать системы по разработке DSL, а не целевой потенциально-важный код. В общем, я — за разграничение ответственности.
V>>Дженерики слабее на порядок примерно, не знаю, откуда ты берешь свое "лучше"?
VD>Ты уж разберись. Или у Nemerle более мощная система типов (а за одно и у C#, так как она у них единая, практически), или "Дженерики слабее на порядок".
Нет, система типов не мощная. Мощный вывод типов, но это не одно и то же.
VD>Подсказка. МП и система типов не обзяательно должны быть связаны.
Блин, это должна была быть моя подсказка. Влад, я понимаю, что совершенно некогда читать каждого попавшегося тебе vdimas-а, но разговор слепого с глухим как минимум утомляет.
V>> Банально хрен обобщишь алгоритм на float и на double, а тебе от этого лучше.
VD>О, как. А мужики то и не знали. Хочешь я тебя научу обобщать алгоритмы на любом языке поддерживающем лямбды и/или generic-интерфейсы?
Нашел обобщение. Сорри, суходрочка это, а не обобщение.
V>> Реально и с размахом эти дженерики используются только по одному назначению — улучшить статическую типизацию, дабы меньше было динамической или тупого боксинга на ровном месте — офигенная, однако, у нас разновидность полиморфизма-то.
VD>О, как? Еще одно противоречие. Ты уж определись или дженерики не позволяют обобщать алгоритмы, или они могут улучшить статическую типизацию. Это как бы два друг-другу протеворечащих заявления.
С чего бы они противоречили друг-другу? Возможность внутри алгоритма покласть объект в типизированное хранилище — не бог весть какое обобщение. Переопределённые операторы и вообще все статические члены — не доступны. А значит прощай статически реализуемые траитсы и бихейворы, статические эффективные фабричные методы и иже с ними. Т.е. я даже ни о каком МП не говорю, только о параметрическом полиморфизме, которого практически нет в генериках.
VD>>>А уж параметрический полиморфизм в современных ФЯ сделан несравнимо лучше шаблонов С++.
V>>Голословие. Если по возможностям — то так же или хуже (где есть явная специализация — то примерно так же, где нет — хуже). "Лучше" разве что по минималистическому синтаксису всего одного языка. Дык по этому критерию и Немерле — убожество еще то.
VD>Тебе конечно виднее. Когда в руках молоток, то все вокруг кажется гвоздями.
Ну ты ведь все-равно поинта про параметрический полиморфизм не понял, так? Понимаешь, в генериках мы можем вызывать методы типа-параметра либо унаследованные им от Object, либо доставшиеся от типов/интерфейсов-ограничений. А это не совсем параметрический полиморфизм, это самый что ни на есть обычный, через vtable или как его. Сравни с явным инстанциированием классов типов в том же Хаскеле. Почему выше абзацем сказал "практически" — из-за value-type.
VD>>>Просто использование шаблонов выходит за рамки параметрического полиморфизма и входят в область метапрограммирования. Но в этой области безоговорочно царят макросы. И убогим возможностям С++ тут делать не чего.
V>>Ты то отсылаешь к Хаскелю и ОКамлу, то называешь языки без макросов убогими (значит и их тоже). А ведь системе типов Немерле даже до Хаскельной как до луны раком. В общем, более чем сумбурно.
VD>Ты кашку из головки вынь и попытайся систематизировать знания. Тогда поймешь, что система типов и система МП — это разные вещи. И можно спокойно иметь слабую систему типов и сильную систему МП (как в Лиспе, например), или наоборот сильную систему типов и слабую МП (Хаскель).
Вот только здесь с тобой и соглашусь. Мне в С++ крайне не нравится синтаксическая легкость конструкции C-style приведения типа, которая и может стать причиной той самой неверной реинтерпретации памяти. Вот только одну эту возможность убери (static_cast и const_cast тоже) — и будет практически другой язык с другой репутацией. А всё остальное в С++ — это классика статической строгой типизации и даже кое-какие МП-зачатки, чем не в состоянии похвастаться многие другие статически строго-типизированные языки.
VD>Скажи, ты действительно не понимаешь, что подмена понятий и несвязанные выводы — это средство получать лживые выводы?
Щас, если пару раз прочту, а то с первого раза как-то не очень...
А если по-делу, я ведь не поверю, что дотнетчики-одиночки делают лучший софт, чем крупные конторы на С++. Так что гоуту собственный пост, ты сам все сказал.
VD>Или ты намеренно пытаешься добиться лжи?
Или ты задал очередной дурацкий вопрос.
V>>Может и возможен, но тот же VoIP сервак потянет на порядок меньше клиентов.
VD>Слово "риалтамй", которое ты тут не к месту упомянул, не имеет никакого отношения к производительности.
Это у сферических коней и бравых форумных парней не имеет. В конкретных цифрах, если производительность не дает вкладываться в отведённые временные рамки, то отношение получишь непосредственное. И в VoIP, если не в курсе, с задержками довольно-таки строго.
VD>Кстати, само заявление тоже высосано из пальца.
Насчет порядка на Ruby? Тебе на заметку — простейший шумоподавитель на .Net работает в 3 раза медленнее, чем на С++, микшер конференции на C# — в 3-5 раз медленнее, чем на С++. Не думаю, что я сильно ошибся относительно Ruby.
Здравствуйте, samius, Вы писали:
S>Моки и заглушки — разные вещи, использующиеся в разных сценариях тестирования.
Садись, два.
Роутеры и маршрутизаторы с этой же точки зрения тоже разные вещи, использующиеся в разных местах сети.
S>Разве речь о Вас в совокупности с тупым диспетчером сообщений?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Моки и заглушки — разные вещи, использующиеся в разных сценариях тестирования. V>Садись, два.
Я спорить не буду, если мосье интересно в чем разница, он найдет где почитать.
S>>Разве речь о Вас в совокупности с тупым диспетчером сообщений?
V>Так не меня спросил?
Я спросил "А моки вообще не в почете?" в ответе на пост где Вы (не против если на ты?) отвечали как бы за всех:
Таким образом, в подавляющем большинстве случаев на С++ в юнит-тестах тестируется...
А ответ на мой вопрос перескочил на частности вроде
У нас в последней системе в центре тупой диспетчер сообщений
и про стразы, что цитировать я не буду.
V>и произвольные тестовые заглушки прекрасно пишутся с логикой произвольной сложности, которая автомокам и не снилась.
По поводу этого — я как бы не понял, как отсутствие автоматизированного инструмента ставится в преимущество.
На дотнете никто совать генераторы моков во все щели не заставляет. Нужен рукописный мок — пожалуйста. Но при наличии средств генерации моков, надобность в ручном мокировании практически отпала.
Следствием использования мокогенов является значительное сокращение времени на рефакторинг.
Да, кстати... рефакторинг тоже предпочитаете ручной, а не автоматические костыли?
Что касается теста с заглушкой с логикой произвольной сложности, которая не снилась — то это не предмет гордости.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, samius, Вы писали:
S>>http://www.google.com/trends?q=c%2C+c%2B%2B%2C+c%23%2C+java&ctab=0&geo=all&date=ytd&sort=0
NBN>Ценность данного графика в контесте данного спора близка к нулю NBN>Например, на том же RSDN вопросы по покетам задают восновном в контестке CF. Однако вопросы задают восновном нубы (создают статистику), а профи пишут на С++ (реальность).
Из этого утверждения следует:
1)Профи не задают вопросов
2)Все профи раньше писали на CF.
3)Пишуших софт на CF несоизмеримо больше, так как далеко не каждый нуб становится профи, а сами по себе профи не появляются
Здравствуйте, vdimas, Вы писали:
V>Ты еще забыл кодеки, мультимедиа, реалтайм протоколы и т.д. И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ
Ну да, всего-то научились инлайнить вызовы со структурами, а также ускорили работу GC, несмотря на то что версия CLR не поменялась.
С учетом этих ускорений код на .NET, который проигрывал плюсовому в 1,5-2 раза стал выигрывать у плюсовго по скорости.
И это даже бех перекомпиляции программ.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Моки и заглушки — разные вещи, использующиеся в разных сценариях тестирования.
V>Садись, два. V>Роутеры и маршрутизаторы с этой же точки зрения тоже разные вещи, использующиеся в разных местах сети.
Здравствуйте, vdimas, Вы писали:
V>>>Просто надо четко понимать, что автоматически-генерённые моки — это костыль по сути, для ситуаций чудесного дизайна, когда одно гвоздями прибито к другому.
C>>С точностью до наоборот — нормальные моки и стабы генерируются автоматически. т.к. автоматическая генерация исключает возможность допустить ошибку или не учесть чего-то.
V>Расшифруй, пожалуйста, слово "нормально" и слово "автоматически", а так же набор возможностей этого "автоматически".
Откройте документацию по xUnit.NET, откройте документацию по RhinoMocks и почитайте. Заниматься восполнением пробелов в Вашем образовании не намерен.
V>>>А так, там где можно обойтись в юнит-тестах классичесскими ассертами — это и синтаксис нагляднее, и проще поддерживать. C>> C>>Вы вообще не понимаете что такое юнит-тесты. Не надоело показывать неграмотность?
V>А да, что такое юнит-тесты требуется еще и понимать...
Требуется. Представьте себе, может для Вас это и в новость, но предмет обсуждения требуется понимать, иначе обсуждать особо и нечего становится. Иначе все-равно что спорить с ребенком о корпускулярно-волновом дуализме.
V>Не надоело рефлексировать и показывать в очередной раз свой поверхностный взгляд? Все твои вызовы мокков ради ассертов, собственно и сделаны. И хоть они теперь не в фас, а в профиль — они были и есть цель любого автоматического теста (не обязательно юнит...)
"Все твои вызовы мокков ради ассертов, собственно и сделаны" — это напоминает генератор цепей Маркова. Взять два умных слова, и связать их между собой связующими. Получается билеберда, но звучит вроде как умно для стороннего человека.
Так вот, ликбез: мокинг выполняется с целью изолировать тестируемый объект от внешних зависимостей.
Что означает, что ожидается, что будет вызван databaseManager.BeginTransaction(), а потом в любом порядке будут вызваны Withdraw и Deposit.
Ассерты это всего-лишь предикат, который по-определению всегда true.
Assert.Equals(10, someObj.SomeIntProperty);
Assert.IsTrue(someObj.SomeBoolProperty);
и т.д. и т.п.
Ассерты и моки не цель. Это средство и ключевой механизм реализации юнит тестов.
При чем тесты ни коим образом не захламляют код. Все тесты находятся в отдельной сборке, которая "видит" (и только она одна) внутренности тестируемых сборок.
V>>>У нас в последней системе в центре тупой диспетчер сообщений, и все тупо шлют в систему сообщения, никто ни о ком не знает... что по одиночке, что в любой комбинации прекрасно все тестируется, и произвольные тестовые заглушки прекрасно пишутся с логикой произвольной сложности, которая автомокам и не снилась.
C>>Перечень того, что не возможно сделать средствами RhinoMocks + xUnit в студию, как говорится.
V>Любую динамическую среду/заглушки, которые генерят переменный по насыщенности траффик или сообщения с разной задержкой и произвольным наполнением. Фишка в том, что реальных задержек-то и нет, текущее время эмулируется, но тестирующая последовательность слишком длинная, чтобы записывать её ручками, она генерируется программой. А таких последовательностей/программ у меня — мама не горюй.
Еще один ликбез: описанное Вами не является модульными тестами. Это т.н. integration tests. При чем ничего невозможного в реализации этого нет — описанное реализуется элементарно в .NET.
V>Далее, обмен сложными структурами данных заглушки и тестируемого объекта, у объекта приличное пространство состояний, на что заглушка должна грамотно реагировать, т.е. приличная иногда логика на if-ах и case-ах. Элементарно средствами RhinoMocks.
V>В декларативном синтаксисе мокков это выглядит как удаление гландов через Ж, и чем осмысленнее логика — тем более глубокое погружение в эту Ж. А если процедура внешняя, то это лишняя тестирующая сущность и все такое.
Демагогия.
Выглядит преотлично. На много лучше, чем то, что у вас есть (а точнее нет) в unmanaged C++. lambda выражения и fluent interface дают прекрасную читабельность.
V>А теперь смотри что получается: автомоками удобно пользоваться для оформления относительно несложных тестов, где внешние условия и реакцию на них вполне можно описать декларативно и синтаксис все еще не будет раздражать.
Модульные или unit тесты ОБЯЗАНЫ быть несложными. В этом их СУТЬ.
V>Ах да, чуть не забыл... разумеется без них практически никак, если у кого-то был неудержимый понос на Ынтерфейсы в период дизайна. Собственно для них в первую очередь оно и есть.
Нет, не для них. Вам не надоело ламерствовать?
Здравствуйте, vdimas, Вы писали:
V>Насчет порядка на Ruby? Тебе на заметку — простейший шумоподавитель на .Net работает в 3 раза медленнее, чем на С++, микшер конференции на C# — в 3-5 раз медленнее, чем на С++. Не думаю, что я сильно ошибся относительно Ruby.
1)Ну приведи код на C++ и C#, дающий такой результат. Хотя сомневаюсь что будет C++, будет тупо С, обернутый в класс и никаких шаблонов, STL, полиморфизма.
2)Ты писал о real-time, оно вообще говоря с производителностью не связано.
Здравствуйте, gandjustas, Вы писали:
S>>>Моки и заглушки — разные вещи, использующиеся в разных сценариях тестирования.
V>>Садись, два. V>>Роутеры и маршрутизаторы с этой же точки зрения тоже разные вещи, использующиеся в разных местах сети.
G>http://www.martinfowler.com/articles/mocksArentStubs.html — курить до просветления. G>Как провсетление наступит можно выложить сюда реализацию моков на С++
Здравствуйте, gandjustas, Вы писали:
G>Из этого утверждения следует:
Снова нарушения логики.
G>1)Профи не задают вопросов
Этого не утверждалось. Профи как сами умеют искать информацию (человек должен иметь склонность к этому, чтобы стать профи), так и знают более лучшие способы эту информацию найти.
G>2)Все профи раньше писали на CF.
Никаких предпосылок для данного утверждения, оно очевидно ложно.
G>3)Пишуших софт на CF несоизмеримо больше, так как далеко не каждый нуб становится профи, а сами по себе профи не появляются
Ну дык, каждый тупой школьник со своим тетрисом. Только они погоды не делают.
Здравствуйте, criosray, Вы писали:
c> Откройте для себя .NET CF и Mono.
Вот тут все про моно да про моно. Но хоть бы кто-нибудь показал мастер-класс на оном, а то складывается впечатление, что его защитники видели его только на картинках, а те, кто его пользовал, молчат, дабы не было стыдно.
