Здравствуйте, vdimas, Вы писали:
C>>Вы вообще понимаете о чем говорите? Что такое модульное тестирование? Что значит "тестировать код, а не сборки"? Это, простите, бред. C>>Модульное тестирование подразумевает: а) тестирование состояния объектов, б) тестирование операбельности объектов. Препроцессингом ничто из перечисленного протестировать не возможно.
V>Похоже, ты не понял основной посыл насчет тестирования исходников в С++ в противовес тому, что и как тестируется с помощью моков.
Не понял. Что Вы тестируете? Исходники? На орфорграфию, чтоли?
V>>>что в свою очередь легко делается через инклюды и прочий развитый препроцессинг. В общем, подход к юнит-тестированию совсем другой и нет смысла тратить время на неприменимый и безбенифитный (для С++) способ юнит тестирования, предназначенный для совсем других условий.
C>>Почему он вдруг стал безбенефитным? Чем С++ такой особенный?
V>Моковский подход и не был для С++ никогда бенефитным. Вложения труда не окупятся, поэтому там немного по-другому.
Э-э, Вы серьезно верите в эту чушь (менее громкого слова придумать не могу...)?
Ну хорошо, расскажите тогда что в С++ "немного по другому", что программам на С++ нет пользы от автоматического тестирования. Внимательно Вас слушаю.
C>>Модульное тестирование программ на С++ как минимум не менее полезное, чем модульное тестирование программ на С#, Java, Python, и т.д.
V>А это ты кому и о чем? Просто лозунги?
Какие еще лозунги?
ГВ>>>>>С другой стороны, в самом по себе паттерне IoC ничего запредельного нет, мне сейчас любопытно поиграться в тех ограничениях, которые ты предложил. C>>>>Запредельное? Патерн IoC в управляемых языках реализуется на базовом уровне за минут 40-50 максимум неопытными студентами.
V>>>Рефлексия она и в африке рефлексия. Развитый подобный фреймворк под нейтив — это разве что COM и пляски вокруг typelib-ов и prog ID. C>>А COM тут при чем вообще?
V>При том, что популярные IoC контейнеры для .Net до компиляции в глаза не видели оперируемые интерфейсы и конструкторы реализующих их классов. Такие шутки делаются лишь через метаинформацию, пример которой для нейтива есть typelib из COM, так же как и ср-ва для построения проксей для OLE-совместимых сигнатур.
Да будет Вам известно, что IoC оперирует не только интерфейсами, но и классами.
COM это совсем другое и к чему Вы его упомянули мне по прежнему не ясно.
V>>>ActiveX site — как раз своего рода "конфигурируемый" в рантайм IoC-контейнер, правда в ограниченном множестве интерфейсов. C>>Я очень надеюсь, что Вы пошутили...
V>Не надейся.
Н-да. Ну ладно, поспотрим что Вы еще напишите. Это становится забавно.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, vdimas, Вы писали:
C>>>Вы вообще понимаете о чем говорите? Что такое модульное тестирование? Что значит "тестировать код, а не сборки"? Это, простите, бред. C>>>Модульное тестирование подразумевает: а) тестирование состояния объектов, б) тестирование операбельности объектов. Препроцессингом ничто из перечисленного протестировать не возможно.
V>>Похоже, ты не понял основной посыл насчет тестирования исходников в С++ в противовес тому, что и как тестируется с помощью моков. C>Не понял. Что Вы тестируете? Исходники? На орфорграфию, чтоли?
Имеется ввиду что для тестирования в C++ применяется не такой подход, как в языках с метаданными.
Обычно применяется создание отдельный программных модулей, которые инклюдят файлы с тестируемым кодом, подсовывают им тестовые данные и делают необходимые проверки.
V>>При том, что популярные IoC контейнеры для .Net до компиляции в глаза не видели оперируемые интерфейсы и конструкторы реализующих их классов. Такие шутки делаются лишь через метаинформацию, пример которой для нейтива есть typelib из COM, так же как и ср-ва для построения проксей для OLE-совместимых сигнатур.
C>Да будет Вам известно, что IoC оперирует не только интерфейсами, но и классами. C>COM это совсем другое и к чему Вы его упомянули мне по прежнему не ясно.
COM использует метаинформацию, аналогично .NET в плане концепции. Например я где-то видел как раз тестовый фреймворк для native с помощью com. И test-runner был, похожий на NUnit.
V>>>>ActiveX site — как раз своего рода "конфигурируемый" в рантайм IoC-контейнер, правда в ограниченном множестве интерфейсов. C>>>Я очень надеюсь, что Вы пошутили... V>>Не надейся. C>Н-да. Ну ладно, поспотрим что Вы еще напишите. Это становится забавно.
Насчет IoC-контейнера явно пошутил, нету в COM возможности декларативно описывать зависимости классов.
Зато как Service Locator COM и так отлично работает.
весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
Здравствуйте, Pepel, Вы писали:
P> весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок
Здравствуйте, Pepel, Вы писали:
P>весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
V> N>Может легче сначала пойти на С#, а потом перейти на С++ или сразу искать вакансии С++
V> То, что делается на C++, на C# в принципе нельзя реализовать.
V> По C++ : Не слушайте тех, кто пытается его похоронить, глупости это все субъективные. Съездите на конференцию "Параллельные вычисления"(можете заглянуть на parallel.ru), там мужики и не знают наверное, что есть языки другие, кроме C++.
Здравствуйте, Pepel, Вы писали:
P>весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
Вы все правильно написали, но с точностью до наоборот.
NBN> M>Так как оба языка Тьюринг-полные, то сомнительно
NBN> Языки то да. А костыли для шарпа не везде есть и не везде подходят. NBN> См. те же игры, ембеддед/мобилы/покеты и кроссплатформенное программрование.
V>>> То, что делается на C++, на C# в принципе нельзя реализовать.
M>>Так как оба языка Тьюринг-полные, то сомнительно
NBN>Языки то да. А костыли для шарпа не везде есть и не везде подходят. NBN>См. те же игры, ембеддед/мобилы/покеты и кроссплатформенное программрование.
Здравствуйте, Mamut, Вы писали:
NBN>> M>Так как оба языка Тьюринг-полные, то сомнительно
NBN>> Языки то да. А костыли для шарпа не везде есть и не везде подходят. NBN>> См. те же игры, ембеддед/мобилы/покеты и кроссплатформенное программрование.
M>Во всем этом есть .NET и, следовательно, C#.
Гы.гы.гы. Либо не везде, либо реальное использование сопровождается множеством оговорок
Как следствие — С++ монополист и надолго им останется.
NBN> NBN>> Языки то да. А костыли для шарпа не везде есть и не везде подходят. NBN> NBN>> См. те же игры, ембеддед/мобилы/покеты и кроссплатформенное программрование.
NBN> M>Во всем этом есть .NET и, следовательно, C#.
NBN> Гы.гы.гы. Либо не везде, либо реальное использование сопровождается множеством оговорок NBN> Как следствие — С++ монополист и надолго им останется.
Мы говорим про монополию или про утверждение
То, что делается на C++, на C# в принципе нельзя реализовать.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, criosray, Вы писали:
C>>Откройте для себя .NET CF и Mono.
NBN>И то и другое неполный отстой, даже близко не являющимся решением реальных проблем.
Понятно... еще один неграмотный тролль. Вы даже сформулировать не сможете в чем заключается неполнота.
NBN>С++ тут монополист, это факт. Твои минусы это не испраят
Да-да, именно по тому у меня из 10 приложений на мобилке почти половина на .NET CF.
Здравствуйте, criosray, Вы писали:
C>Ответьте на этот вопрос:
C>
C>Ну хорошо, расскажите тогда что в С++ "немного по другому", что программам на С++ нет пользы от автоматического тестирования. Внимательно Вас слушаю.
Вопрос стоит вовсе не так, и я дважды пытался поправить постановку вопроса. Видя твою невнимательность, мне крайне неохота что-либо объяснять, ибо опять может уйти в космос... Тем не менее, для истории:
Программам на С++ есть такая же польза от автоматического тестирования как и всем остальным. Мало пользы лишь от того способа организации тестирования, какой реализован в моковских фреймворках. Я не буду утверждать, что сэмулировать на С++ аналогичный подход к организации автоматического тестирования невозможно, но я точно могу утверждать, что такое вложение труда совершенно неразумно, т.к. не окупится. Поэтому автоматизируют тестирование путем тесного совмещения юнит, интеграционных и регрессионных тестов, для С++ это должно быть в одном флаконе, иначе толку совсем мало на выходе.
Основное отличие в том, что нативный код — это черный ящик. Например, у нас результатом компиляции явилась некая DLL в которой одна точка входа "GetPlugin", и через эту точку входа доступна функциональность некоего плагина, заметь, самый высокий уровень функцинальности, где класические юнит тесты закончились еще на пару уровней ниже. А сам этот некий плагин в исходниках состоит из где-то трех сотен классов, которые тоже охота погонять на тестах, начиная от юнит, и заканчивая интеграционными, но раздельного доступа к этим классам в этой ДЛЛ, понятное дело, нет. И вот специально для тестов собирают совсем другой бинарный образ(ы), вовсе не такой, какой пойдет в релиз. В этом бинарном образе содержится некий тестовый фреймворк (ииногда самописный, но и сценарии применения С++ не в пример богаче, чем у управляемых платформ), и некий тестовый код, осуществляющий вызовы тестируемых классов/функций внутри этого тестового бинарного образа.
Таким образом, в подавляющем большинстве случаев на С++ в юнит-тестах тестируется по-сути исходный код, скомпиллированный в тестовый бинарник с некими тестовыми эмуляторами и прочей хернью. Учитывая, что в С++ имеется помимо полиморфизма на виртуальных ф-иях еще и "шаблонный полиморфизм", то скомпиллированный тестовый бинарный вариант некоего класса может иметь вообще мало общего с им же в целевой сборке.
-------
А вообще, я ведь не настаиваю, просто рассказываю как дела обстоят в других областях.
Здравствуйте, vdimas, Вы писали:
C>>Ответьте на этот вопрос:
C>>
C>>Ну хорошо, расскажите тогда что в С++ "немного по другому", что программам на С++ нет пользы от автоматического тестирования. Внимательно Вас слушаю.
V>Вопрос стоит вовсе не так, и я дважды пытался поправить постановку вопроса. Видя твою невнимательность, мне крайне неохота что-либо объяснять, ибо опять может уйти в космос... Тем не менее, для истории:
Ну вот и хорошо. Значит польза все-таки есть. Хорошо, что Вы это осознали. Ну а то, что способы тестирования различаются в виду убогости С++ и native кода — это и так понятно было.
