Tarmik

Кстати — то что я пробовал 32/64-битные аппликации — в 32-битной версии все по другому чем в 64-битном. вот один из коммиттов что я закоммитил:

github.com/boostorg/stacktrace/pull/90/commits/cf4eb6300c1d19b8fe0138bbd275b69a9b36de80

Я повесил hook на __CxxFrameHandler3, но он работает только с native code exception, но не с managed code exception, так что пока что отключил все относящееся к 32битному коду. Пока оставлю как есть потом может вернусь к этому коду.

Вообще 32/64 отличаются в корне друг от друга.

Но то что я дебагирровал до данного момента — подвисание дебаггера, легкое или конкретное — это нормально. Отсутствие полного call stacka в дабаггере, (нужно пользовать process hacker), отличие работы аппликации с дебаггером или без него — это все нормально.
несраватывание debug breakpointов…

Ощущение что идешь в лес по дрова… :-) При чем дров больше чем самого леса…

github.com/dotnet/diagnostics/issues/152#issuecomment-480457800

> Some of our team's past efforts with C/C++ exception handling interop demonstrated this can > be extremely complicated and the amount of effort it took us to maintain it wasn't justified
> relative to the value it was delivering for .NET customers.

Интересно у людей с Микрософт те же проблемы что у меня?
:-)

В общем пока вы отвечали, я уже умудрился интегрировать свой код в boost / stacktrace библиотеку.

На данный момент то, что я сделал и/или собираюсь сделать описанно тут:
github.com/dotnet/runtime/issues/12405#issuecomment-626291059

А сам обработчик исключений находится тут:
github.com/tapika/stacktrace

см. example — csharp_crashy_window.xaml.cs / cpp_crashy_managed_dll/cpp_crashy_managed_dll.cpp

Пока что очень на эксперементальном уровне, но я могу теперь нативные падения отлавливать и передевывать в managed их. С достанавием call stackа и прочего.

Но пока что библиотека не допилена до конца, надо будет добавить managed call stack determination, и прочее.

Буду первым кто спросит у автора данной статьи.

Я изучаю как работают исключения под C++ + C++/clr + C#, с намерением обрабатывать ошибки со всех этих языковых диалектов. На данный момент я уже кое-что описал что и как работает здесь:

github.com/dotnet/diagnostics/issues/152#issuecomment-616082922

и мне интересно если у меня имеется C# аппликация, которая использует C++ — как исключения обрабавываются там. Как упоминается в моем сообщении — ни SetUnhandledExceptionFilter, ни AddVectoredExceptionHandler в C# аппликации не дают полного контроля над C++ exception (пытаюсь валить код по записи на invalid pointer).

Но тем не менее C# аппликация вызывает AppDomain.CurrentDomain.UnhandledException на стороне C#, но это уже немного поздновато, так как UnhandledExceptionEventArgs.IsTerminating = true и остановить падение программы уже невозможно.

Тем не менее — я заметил что вызов C# кода проиходит с vcruntime140_clr0400.dll / __C_specific_handler.

Я могу туда даже поверить hook, изпользуя minhook библиотеку. Но у меня остается вопрос что при вызове данной функции делать. и не слишком ли это поздно уже.

В данной статье:
web.archive.org/web/20080213085805/http://msdn.microsoft.com/msdnmag/issues/01/09/hood/default.aspx

Some tools (such as Mutek's BugTrapper) have circumvented this problem by overwriting parts of the user mode exception handling code in NTDLL. One place to do this would be the KiUserExceptionDispatcher function in NTDLL.DLL, which I described in the aforementioned structured exception handling article in MSJ. While overwriting KiUserExceptionDispatcher works, it's a fragile solution, and prone to breaking as new versions of NTDLL come out.

Упоминается возможность вешать hook на NTDLL, но как я понял — это тоже проблематично, как как NTDLL имеет одну копию не дупликаты per процесс как например с kernel32.dll. Но в принципе это не важно, так как NTDLL вызывает vcruntime140_clr0400.dll, куда мы можем повесить hook.

Я попытался найти что можно делать вообще в функции __C_specific_handler, и нашёл Wine имплементацию оного
www.winehq.org/pipermail/wine-cvs/2009-May/055617.html

который в принципе предлагает стратегию обработки данной функции, но уверен сработает ли он с managed code и во всех случаях.

Здесь очень бы помог сам код vcruntime140_clr0400.dll, вроде как не существует как open source code.

Может можете что посоветовать?

Это если игра использует https, но не факт, скорее всего customизированный бинарный протокол, который больше подходит для обновления мира.

Кстати, один из вариантов — это онлайн игры. Они по идее сами тянут контент из сети. Изменить DNS оффициального сервера на свой собственный локальный сервер, я подавать эксплойт контент напрямую с сервера.

Онлайн игр много, Terraria, Growtopia,…
Думаю что игры проще эксплойтить, чем саму приставку.

Начиная с того, что поддержка скриптинга и modинга может быть в самой игре (как фича). Заблокировать сложнее — представьте отозвать и/или забаннить все версии данной игры, да и думаю в Sony более помешанные на security программисты, чем все те поставщики игр, что под них работают.

Сам купил недавно новый PS4, но для детей — самому не охота «гадить» и/или убивать свой PS4, хотя сам с интересом поковырял бы защиту PS4. Думаю пока железо мое лезть в неё глубже пока не буду. Максимум попробовал бы PS4 SDK, и может какую нибуть игру написать пока её не хотят забанить. Боюсь, что PS4 SDK платный.

Если кто что захочет профинансировать, сообщите лично.

а как вообще с dev rights — можно ли получить доступ разработчика на любую консоль или это платно / холерно? не знаете?

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

Мне странно, что Sony до сих пор не начала вычислять хакеров проактивно — например, если странный вызов происходит — связаться с Sony серверами и сообщить о данной попытке взлома.

Я бы предпочёл не reverse engineeriть вообще ничего, если возможно.

Есть ли возможность сделать игру для PS4, и запихать туда некий development kit / scripting kit, или же использовать существующие игры и их поддержку scriptинга / компиляции.

Я пробовал googlить, но скажем «ps4 python» не дружат между собой вообще.

А какие PS4 простенькие игры знаете вы, куда можно было бы залезть и через какие скриптовые языки?

Чем проще хак и чем обширнее даннная игра разпространена, тем лучше.

Должен снять шляпу перед автором данной статьи. Все benchmarkи которые я на данный момент находил проводили тестирование на single и multithreading, а все остальное — тоже важная информация упускалась.

Мне интересно было бы ещё посмотреть есть ли на какой код code coverage и сколько он процентов, а также интересен сам benchmark тест — на тот случай, если захочу сделать свой собественный логгер. Возможно ли выложить сами тесты куда-нибуть — скажем на github.

Можно было бы заодно посмотреть код и побегать по нему.

Спасибо за данную статью. Очень странно что мои происки в Google нашли на данную статью — но у меня была идея совместить генерацию Solution / Projectа ( habr.com/post/337138 ) с real-time обновлением Solution / Projecta — вот и искал какие-то описания EnvDTE eventов. А вообще есть желание списаться и вместе подумал на данную тему? ( если есть желание и интузиазм взяться за что-то совместное )

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

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

Думаю никто реально этого не хочет. Почему вы думаете иначе?

Но мы ведь не про армию, а про терроризм говорили.

Суть смысла сказанного выше — если сделать форум, где сами граждане могли бы выбирать куда вкладывать деньги (своих налогов), то они могли бы сами выбрать — вкладывать деньги или нет.

Например — Американское правительство — у нас тут классный проэкт. Поддержка группы ИГИЛ. Они занимаются… тем то и тем то… Мы могли бы заработать на этом… так то и так то… и как последствие дестабилизировать другие страны, от чего американцам бы казалось что они лучше живут.
Нам требуется ещё… столько то и столько то… что бы проивести… столько оружия… для продажи.

Нажми сюда что бы поддержать.

И тогда сами граждане выбрали бы хотят они туда вкладывать деньги или нет.

Единственное что интересно — как, кем и по какому критерию данный форум модерировался бы. Я сам заметил если скажем форум спонсируется компанией A, а ты на форуме рекламируешь продукты компании Б, где Б прямой конкурент компании А — такие сообщения удаляются моментально без какой либо нотификации пользователю. Т.е. форум, модераторы тоже имеют свой менталитет/веру и не хотят продвигать то с чем им не по пути.

Вы видимо не в этой стране живёте.

Да я сам с Финляндии, поэтому всей ситуации не знаю.
Интересно однако.

А что вы сделали, чтобы убрать финансирование своего правительства?

Это довольно сложная тема как мне кажется. По идее ни правительство ни сам президент не могут точно сказать куда и во что стоит вкладывать деньги. Сам живя в Финляндии, я не согласен с тем, что треть зарплаты уходит не понятно куда. Я бы финансировал ремонт и починку дорог, но к сожалению не армию. Но я понимаю Россию и Путина, который вкладывает деньги в армию — с той информационной войной, что сейчас ведется. Думаю в данном случае Путину виднее, чем мне, зачем вкладывать деньги в армию. Но в финскую армию я бы однозначно не вкладывал ни цента — стоит Финляндия на отшибе Европы, и вряд ли кому она нужна.

Можно было бы организовать форум, на уровне государства, где каждый гражданин мог бы сам определять, во что он хочет вкладывать деньги и куда его деньги уходят. Была бы какая-то основа, от чего никак не отвертется, остальное на любителя. Скажем хочешь поддержать армию — может поставить в них помесячный вклад со своих налогов.

Но опять же — это палка о двух концах. Гражданин посчитает, что зачем вкладываться в армию, лучше куплю себе новый диван, а через месяц понаедет НАТО за отравление какого-нибуть шпиона-предателя. Или объявят, что у вас в стране химическое оружие и под видом улучшения мира придут разбираться и заберут себе по пути нефть.

Но все это довольно глубоко на уровне политики и самих фактов не видно, а только отголоски о том, кто и что сказал. Начнёшь копаться — почти что болото — до дна никогда не доверешься. При чём зависит от того где начнёшь копаться — новости какой страны, какой информационный канал, и на каком языке — результаты могут быть разными. У информационных каналов тоже должен быть свой рейтинг правды, что бы можно было убрать и заткнуть все ненужные «веро»исповедания. Или сделать освещение новостей опосля — как, что, и зачем было сказано и кому это нужно.

В кратце так…

Вот антивирус. Так производительность ПК просаживает иногда — пользователи от этого аж кушать не могут. А вирусы иногда всё равно пролезают. Так давайте уберём антивирус?

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

Форматируют вирусы диск => забрать у них доступ к форматированию.
Запускает сторонний код через ActiveX в web browserе — исправить и убрать данный доступ.

Но с корнями терроризма бороться сложнее. Если религия или вероисповедание помогает взять в руки оружие — нафиг такую веру. Или промыть мозги религиозным убеждениям / фанатикам.

Есть оружие — убрать доступ к оному. Законы, финансы, культура страны в конце концов.

Намного интереснее вопрос конечно что делать, если терроризм финансируется другим государством — как например Америкой. Простые американцы не виноваты, что в государстве сидит кто попало. Тут уже идёт в направлении — убрать финансирование правительства, которое финансирует поставку оружия. Сложно.

а как же этот текст:

ru.wikipedia.org/wiki/%D0%A1%D0%9E%D0%A0%D0%9C

Решение Европейского суда по правам человека

В другом языковом разделе есть более полная статья Zakharov v. Russia (англ.).
В декабре 2015 года Европейский суд по правам человека вынес решение по делу о российском законодательстве о СОРМ.[15][16] Единогласным решением Большой палаты Суд постановил, что «положения законодательства Российской Федерации, регулирующие прослушивание связи, не содержат адекватных и эффективных гарантий против произвола и риска превышения полномочий, которые присущи любой системе скрытого наблюдения и которые особенно высоки в системе, где специальные службы и правоохранительные органы имеют прямой доступ с помощью технических средств ко всем мобильным телефонным сообщениям»[17], и, следовательно, это законодательство нарушает статью 8 Европейской конвенции по правам человека.[15][16]

не не знал. Кстати — я так понял что СОРМ навернулась под воздействием европейского суда? Но теперь наверное Российский суд может отвергнуть решения Европейского суда, если их идеи неприменимы. Т.е. при желании можно возродить СОРМ. :)

Кстати — СОРМ — это больше прослушивание на уровне оператора связи — я же предлагаю не прослушивать, а обобщать и извлекать содержимое/смысл текста.
Это разные вещи.

Я полностью согласен насчёт двоякости ситуации. Я понимаю и тех, кто хочет поймать террористов, наркоманов и прочих, но понимаю и идею насчёт права на свободу. Самое интересное — а что если в семье муж работает в ФСБ, а жена ему изменяет? По идее ФСБ: шник может посмотреть всё, что жена писала и кому писала — хотя и превышает свои пономочия — но никто не сможет ничего проверить если это не окажется изменой.

Не женись на ФСБ: шнике? :-)

Я думаю, если это конкретные люди и они уже в чем-то нехорошем засветились, то можно было бы официально предоставить «иск» для просмотра их переписки. Как предъявление иска будет выглядеть, и от кого кому — можно было бы прописать законами. Есть же иск на обыск квартиры — почему не может быть аналогичного для обыска чата сообщений?

Если же государство/ФСБ хочет действительно улучшить защиту против террористов, то один из вариантов как это сделать — можно было бы сделать программу для семантиского анализа текста. Програмка скажем ищет в сообщениях «взорвать» или ещё что-то, и в соответствии с этим реагирует на написанное.

Но если подумать — то написанное может варьироваться в зависимости от используемых диалектов и аббревиатур, не факт даже, что сторонний человек поймет, что там в чате написано. Но и там можно было бы подсчитывать примерный уровень опасности сообщения, прежде чем отдавать весь текст сообщения.

Например смс «Пойду проколю шину» можно было бы классифицировать как уровень 1 — употреблено агрессивное слово («Проколоть»). Или же «Пойду проколю этому уроду шину» — как уровень 2 — употреблено агрессивное слово («Проколоть») а также ругательство («урод»).

К обобщенным классиификациям чатов имела бы доступ ФСБ и делала вывод как и кому предъявлять иски.

Естественно данную програмку могла бы написать сама ФСБ, но тут ещё вопрос и в том — а что если она не работает так как надо? (Падает, выдает неправильные результаты) Может ли разработчик программы получить оригинальный текст чата чтобы исправить ошибку?

И даже если данная программа будет написана, не думаю что она попадёт во все модели мобильников, просто из-за того что она может быть очень трудоёмкой.

И кто и как будет одобрять что данная программа сделана ФСБ, а не троян? А муж в виде ФСБ программиста тоже может иметь полный доступ ко всему? :-)

File formaty описаны с точки зрения того как проекты buildить. syncProj занимается же генерацией проектов.

Не для юнит-тестов. Юнит-тесты пишутся либо до, либо после. Нет смысла писать их одновременно.

А почему нельзя писать одновременно то?

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

Мы уже ходим кругами. Думаю уже не имеет смысла копать глубже, к тому же вряд ли что дочитает эту переписку.

Если сильно захотеть, то можно. Но зачем?

Мне кажется это нормальный подход, делаешь и тестируешь? Если без автоматизации, то это так и надо делать, если с автоматизацией, то можно и с светофором.

Ээээ. Результат работы программы — это результат работы программы, я не должен его модифицировать только для того, чтобы тестам было удобнее.

Ну скажем так если outputа много, то это уже отдельные файлы надо делать, визуально не проверишь мега или гига байтовые файлы.

Так откуда же взять файл, с которым сравнивать-то? И зачем в этой конструкции что-то «одобрять», если уже есть эталонный файл.

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

Это уже второе, третье и т.д. он может полуспать и сравнивать diff на преведущую версию в svn или с чем то ещё.

Но когда слишком много изменений, надо опять проснуться и разобраться в коде.

Нету у меня версионника в тестах, и никогда не будет.

По мне результат тестирования так же важен как и сам код. По крайней мере я так решил с syncProj. Но в принципе можно и без version control обходится, просто полуспать не получится. :-)

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

Можно, но нужно ли. В принципе syncProj не имеет на данный момент никакой сложной функциональности — т.е. там нет геометрических подсчётов, нет больших операцией с базой данных — поэтому зачем делать сложным то, что в своей основе просто?

Есть всегда вероятность того, что другой программист не сможет все держать в голове что и где находится или же я сам лет через 5-10 не смогу — но я и ещё не такие навороты с кодом видел.

Правда навороты — это не есть хороший код. (Особенно без тестирования)

Так вот, вместо того, чтобы делать ее дифф с эталонной, я просто проверяю, что она содержит нужные элементы, сформированные по нужным правилам.

Как я уже говорил, diff не обязательно делать на данные, можно просто ответ написать (на сравнение с эталонными данными) — «ок / не ок».
и сравнивать уже сам «ок».

Red-green-refactor. Очень просто же: написали тест, он красный, написали код, тест стал зеленый, можно двигаться дальше.

Ну можно и написать и тест и код одновременно?

я должен просмотреть результат (а если он большой)

Ну если это консоль — то не печатай много текста. А если это сгенерированный файл, то здесь либо diff compare на другой файл (например между соседними файлами), либо diff compare на svn history (преведущий коммит). Сравнение делает в любом случае машина, разница лишь в том, что в одном случае ты сам пишешь, а в другом машина.

Ну так намного эффективнее посмотреть в тест, и понять, что ожидается, чем разбираться по истории файла.

В случае с syncProj — файлы подбираются Visual studiей, и проще иметь весь проект, чем запчасти проекта, хотя бы потому что можно протестировать с Visual Studiей.

Даже на данный момент если я буду добавлять поддержку всего того, что умеет Visual Studiя на данный момент (а это например c# код, managed c++ код), то у меня уйдут годы на поддержку всех пермутаций.

А если это весь проект, то diff compare единственный вариант. Но для других проектов возможно diff compare не лучший вариант.

Вам, видимо, низачем. А вообще это основа юнит-тестов.

Вообще в программировании много новых и просто искуственных терминов и понятий. Когда люди начинают говоть о controllerах, factory, clue, wrapperах, начинашь прислушиваться, что за странности пойдут дальше. Можете объяснить то зачем мне светофор? :-)

Ну т.е. тот что на дороге стоит, известно зачем.

Понимаете ли, «одобрение» всегда хуже, чем машинная сверка.

т.е. в первом случае вы набрали текст и спасли его в исходник. Во-втором случае вы нажали «yes» и программа спасла текст вместо вас в файл. В чем разница то? :-)

Ну да, свое болото-то интереснее, конечно.

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

Потому что чем меньше инструментов нужно для решения задачи, тем лучше.

Чем эффективнее используешь инструменты — тем быстее разработка.

Можно. Какое отношение это имеет к семафору?

Никакого. Зачем мне светофор то?

А ваше «print&compare» — это же вообще не атрибуты, это всего лишь подход. Чем универсальнее подход, тем менее он удобен на каждый конкретный частный случай.

Возможно. Возможно нет, надо пробовать. Мне нравится, что я тесты как таковые не пишу. Просто печатаю все в for loopе на экран и одобряю. Вообще без запарки.

Это утверждение ничем не обосновано. А учитывая, что методология юнит-тестирования описана сильно больше, чем в одной книге, еще и бессмысленно.

Я уже предлагал созвонится аудио / скайп. Основая идея, что онлайн / face-to-face зачастую проще и быстрее объяснить, чем сотней писем/постов. Но я думаю, что и это множество книг меня тоже не особенно вдохновляют, хотя бы потому что их множество. Напоминает трясину или болото, где все звучит хорошо, но времени уходит уйма.

То есть для того, чтобы корректно работать, вашему подходу нужен еще и версионник. Спасибо, но нет.

А почему нет?

Да, но полное описание file formatа вы мне не нашли.
Вы, похоже, не понимаете, как устроены msbuild-проекты. Ну ладно, не суть, это не моя проблема.

Ну я понимаю, что понимать мне особо и не надо — зачем забивать голову ненужной информацией? :-)

Это не «проще», это так, как я и описал.

Удивительно, как можно говорить об одном и том же и не понимать друг друга. :-)

Теперь можно поподробнее. Семафор, как я понимаю — это просто лампочки — красная или зелёная — прошло / не прошло.
Да, именно так.

На данный момент я не коммичу не протестировав. Мне кажется так тоже можно делать?

Нет, я не так пишу тесты. Я ничего не «одобряю», я просто пишу тесты с assertions и удостоверяюсь, что они проходят.

В смысле вы не пишете 176 тестов за раз. (Тест пишется, тестируется) * N, релизится.

Ну и ничего. Мы обсуждаем методику тестирования, а не то, как у вас фича реализована.

Ну т.е. там, где я вижу пол-стакана полным (протестируем), вы видите его пустым. (не будем тестировать)

[Theory]
[InlineAutoData]

Если честно, то аналогичные unit тесты видел у нас в группе когда смотрел «через плечо». Думаю, что любая проблема, может быть решена несколькими способами. Сначала вырабатываются «слова», «запчасти», C# attributы, функции нового языка для тестирования, а затем тестирование происходит на уровне нового языка.

И тут нет правильных или неправильных вариантов, потому что, я думаю, что большинство программистов разберутся, если потребуется. Разберутся то да, но будут ли поддерживать — это другой вопрос.

Но тут вопрос ещё в том, что легко ли усвоить новый язык или нет.

У вас приведен код уже с 4мя аттрибутами. Дальше будет больше? Я оперирую с двумя — print & compare.

С точки зрения понимания нового языка для тестирования мой легче усвоить. (Если возьмем новичка, что не понимает в тестировании ничего).

Да, отсутствие документации для моего метода тестирования — это минус, но при желании могу написать. Думаю, что надо бы написать.

106 на один компонент, проходят за 0.093 секунды.

Вот скорость — это кстати тоже важный критерий. Мои тесты прогоняются порядка 4 секунд, но у меня есть тоже создание процесса (это консольное приложение как никак). Согласен, что со временем чем больше testing занимает, тем больше отнимает времени у программиста. Лучше его минимизировать. У меня есть к чему стремится. :-)

Нет, конечно. Весь смысл автоматизированных тестов в том, чтобы программист работал поменьше.

Но если тест failит — то чем ваш ваш подход уменьшает время работы программиста? Т.е. если не работает, то не работает, надо фиксить — тут никуда не отвертется.

… это если у вас ожидаемый файл правильный. А откуда вы это знаете, если вы его в прошлый раз «одобрили»?

Если одобрен — то находится в *accepted* файле. А svn diff покажет изменения с преведущего релиз тестирования (Что-где добавилось или изчезло).

К тому, что, вопреки тому, что вы пишете, описание формата vcxproj гуглится сравнительно быстро.

Да, но полное описание file formatа вы мне не нашли. Вы нашли что-то. Что-то кто угодно найдет.

Нет, не кажется. Если вам надо получить такие проекты, то у вас есть три способа — документированный формат, готовая библиотека или самому все сгенерить. Такова жизнь.
…
Не вижу проблемы. Сделали реверс, зафиксировали результаты анализа в виде требований.

А можно сделать проще. Не выписывать все требования, а начать с основных и по мере развития проекта добавлять новые требования. Как я и сделал.
И оставить за проектом возможность сравнивать file format по мере надобности, как это делается сейчас. Думаю какой-нибуть умный термин для этого есть. Например интеративное или эволюционное развитие.
:D

Я говорил, что в вашей реализации адекватного семафора нет.

Теперь можно поподробнее. Семафор, как я понимаю — это просто лампочки — красная или зелёная — прошло / не прошло. Или я что-то не так понимаю?

А если не писать, то как проверить, что результат работы совпадает?

В syncProj на данный момент запускается 176 тестов. Естественно я их не написал все сразу. Обычно пишется один тест за раз и сразу же тестируется. И в месте с тем, как тестируется — то результат одобряется или код продолжает исправлятся. Разве вы не так пишете тесты?

… а можно просто не тестировать, чего уж.

Лучше больше, чем нет совсем. То что .cs может генерироваться из .vcxproj — это большой плюс, но то что не самым оптимальным образом — ну и что?
Фича есть? Есть. Такой не у premake5 ни у cmake нету.
Тестируется? Да. Разботает не оптимально? Ну и?

При таком подходе, повторюсь, можно вообще не тестировать. Пользователь сам все поправит.

В смысле обратная генерация .vcxproj должна работать правильно — а как писать C# поверх syncProj — это уже зависит от программиста хорошо или нет.

Нет. Если в тесте сказано «игнорировать порядок элементов», то он будет игнорировать порядок элементов.

А зачем мне это?

Просто я подумал, что человек который пишет «Отвратительно.» действительно знает как писать unit тесты, а тут начинаешь ковырятся и идут отсылки и требованиям и к методике, и потихоньку тонешь в этом болоте. Покажите мне красивый unit test, как бы вы его стояще написали? :D

Вот и демонстрация того, почему так делать не надо.

Да нет, syncProj делает далеко не оптимизированный C# код. и это уже не первый раз я обхожу.

Ээээ… что? И как это решит проблему того, что ваше сравнение не понимает семантики?

Семантику понимает программист. Этого достаточно?
Вообще я сам всегда мечтал, что бы утилиты были не слишком глупыми, а немного помогали делать работу. Тот же компилер мог бы и автоматом пытаться добавить ';' если она отсутствует. Но пока что такого нет.

Так надо же знать, не хватает, или слишком много, или не те.

По diffy определяется. Я использую TortoiseMerge или ExamDiff. Достаточно? (Это когда нажимаешь «No»)

Правильно, потому что студия 2010-ая. Но к формату файла это отношения не имеет. DebugInformationFormat — это типичный параметр для таска/таргета, а параметры можно посмотреть в описании самого таска/таргета в .targets, и так далее.

Теперь не понял. К чему этот линк то?

Чтобы хотя бы примерно видеть, что я генерирую то, что Visual Studiя спасает.
Это этап формирования требований (=постановки задачи). Это происходит до написания тестов.

Ну предположим что я мог бы запустить vs2010, vs2012, vs2013, vs2015, vs2017 сгенерировать на них все возможные пермутации проектов с mfc, native c++, windows, x64, со всеми возможными опциями, но вам не кажется что это немного перебор?
Думаю что основаная проблема в том что я частично reverse engeneerю file format, по этому это невозможно оформить в виде требований. К тому же у меня меняются требования — добавлял поддержку странностей других генераторов как cmake, Gyp.

… ну так вы это не упоминайте не к месту, я и не буду вспоминать.

Ну так вы спросили знаю ли я. Знаю… :-) Но с конктекстом syncProj никак не связанно.

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

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

Например в этом файле в конце 3 filter, которые можно было соединить в два — как это написано уже в исправленной версии — там логика такая что если несколько конфигураций с одной и той же коммандой и сообщением — то syncProj должен был их соединить в одну конфигурацию.

Я знаю, что syncProj работал не так, как надо, но reverse engineering не моя прямая цель, поэтому я одобрил, как есть и пошёл дальше. Позже правда это пришлось разбирать, почему не работает, из-за случайных failов — но если бы failов не было это был бы удолетворительный результат для меня.

Пользователь получает на 6 строк больше, чем нужно — перебьётся и сам отедитирует, как ему нужно.

Думаю, не я первый и не я последний, кто захочет обойти какое-то мало важное препятствие.

И как это все поможет понять, что всего лишь поменялся порядок элементов (который для задачи не критичен)?

Ну это я думаю даже с обычным unit testом надо будет дебаггировать.

Нет, нельзя. Пока вы тестируете буквальное совпадение файлов, такого вы сделать не сможете.

Взять ваш аналитический подход и напечатать «ok» / «not ok» на экране? «ok» одобрить, если придет «not ok», то тест зафайлит.

Ставишь breakpoint и начинаешь фиксить.
… на что?

Я уже описал выше, но вообще зависит от кайса. Не хватает xml тагов, или линий — добавить, слишком много — убавить?

blogs.msdn.microsoft.com/visualstudio/2010/05/14/a-guide-to-vcxproj-and-props-file-structure

это props file format. Сделай поиск на «DebugInformationFormat»? Нету? Правильно. Не описан.

Да нет, ничем не хуже других. Даже наоборот, в чем-то лучше, потому что вход и выход чисто машино-читаемые, и нет никакого сложного сетапа.

Единственное что мог бы предложить — взять и покрыть syncProj тестированием таким, каким видите вы его. Понимаю что это много работы, но хотя бы для basic вызовов.

Идея неплохая, но я иногда сравниваю с оригинальным форматом Visual Studio
Зачем?

Чтобы хотя бы примерно видеть, что я генерирую то, что Visual Studiя спасает. Т.е. file format идентичен. Я же для Visual Studiи его делаю.

Это происходит в ответ на месседж-бокс вашей тестовой системы? Или вы о чем-то вообще не связанном говорите?

Забудьте что я на работе делаю, syncProj на данный момент не подключен к autoбуйлдам. Возможно в будущем подключу.

xunit (или mstest, или nunit) — не менее «полная оболочка для тестирования». Так в чем удобство-то?

В том что ты не тестируешь, т.е. не пишешь тестовый код, как таковой. Просто печатаешь все на экран (console output) или спасаешь в файл, одобряешь его, и все, тест готов. 50% меньше работы.

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

Ок, большое кол-во информации можно либо спасасть в тот же *accepted* файл, но уже в бинарном формате, либо посчитывать какой-нибуть checksum через все bufferа, и печатать их, тогда в *accepted* файл (console output), но в мой тест framework можно сделать и автоматический анализ и разпечатывать результаты на экран, после чего он тоже попадет в *accepted* file (console output). T.e. можно сделать и по-моему и по-твоему ?!

(а) как найти, где генерится этот таг?
(б) как узнать, на что исправить?

Ну например с vs2010 несовместимостью Visual Studiя выдавала ошибку стиля: не знаю такого Debug formatа: None.
Открываешь .vcxproj, ищешь None. Находишь напротив название xml taga: DebugInformationFormat. идешь в исходники и ищешь "<DebugInformationFormat" и находишь точку, где он генерируется. Ставишь breakpoint и начинаешь фиксить.

Но с Visual studiями я поменял Visual studio версию 2 или 3 раза пока не понял какая Visual studiя поддерживает и что. Использовал для этого vsver() функцию — после этого знал, как фиксить.

С syncProj немного сложнее, потому что .vcxproj file format оффициально не документирован нигде и такие утилиты как cmake, qmake, premake5 сами разбираются с этим file formatом. Это немного «reverse engineering» — как заставить Visual Studiю думать, что это она спасала этот файл, а не ты.

Думаю с точки зрения покрытия unit testингом — это не лучшая для примера утилита.

… ну и не генерите их. Или они в одной версии не поддерживаются, а в другой обязательные? Тогда как раз очень удобно проверять наличие/отсутствие явно.

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

У вас вообще нет нормального красно-зеленой семафора, у вас есть зеленый (ничего не изменилось) и не-пойми-какой (что-то изменилось); но это не важно: если требуется вмешательство разработчика для проверки, надо ли править код — это то же самое, что «упал тест».

Вообще есть — моя буйлд система (по работе) майл шлет, у паралельной группы именно светофор с отдельным дисплейем. Но syncProj сделан в свободное от работы время и у меня отдельных build компьютеров дома нет. Сейчас жду, если syncProj подберется / не подберется community, а потом буду думать о расширении.

Есть готовый инструментарий. А постановка задачи в инструментарий не входит.

В этом то и удобство syncProj тестирования, что это полная оболочка для тестирования. Может быть оптимизированная не с точки зрения отдельного build компьютера, но тем не менее. Хотя syncProj использует C# скрипты (почти как end-user frontend), не факт что ещё какой-нибуть API захочет использовать C# скрипты.

Осталось, глядя на тест, понять, какой же именно файл считается «полностью готовым».

Все полностью готовые? Т.е. в итоге конечный пользователь конфигурирует syncProj C# скрипты как он хочет, а что он хочет, зависит от него самого. В unit testе я просто делаю все возможные вариации проектов.

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

Ну обычно это не трудно, визуально воспринимается легко. Обычно если какая несостыковка — ищешь где генерируется преведущий xml tag и ставишь туда breakpoint — и исправляешь. Не сложнее чем использование калькулятора или Excelя.

Но есть и более сложные запчасти кода — например переделка .vcxproj в .cs скрипт. Включен у тебя этот define только для Debug конфигурации / x64 платформы или ещё для Release / Win32?

Там уже надо с кофе думать, как должно работать — но сейчас моя основная цель генерация, не reverse engineering. syncProj может отплюнуть какой-то .cs, а оттуда developerы могут уже и сами доковылять с документацией до конечной цели.

Но думаю без сложного кода не делается нужная функциональность.

А валидатор что об этом думает? А главное, если вы не понимаете, почему VS считает сгенеренный вами файл бредом, как вы можете их генерить?

(и вообще, это типичный msbuild-проект, что там за чудеса?)

Ну как я упомянул, там могут быть такие xml tagи которые не всеми Visual Studio версиями поддерживаются — как DebugInformationFormat / None например. Т.е. в 2013 году Микрософт программисты решили — давайте улучшим это так, и сделали это. Я же не виноват что vs2010 ещё в активном использовании многими проектами.

Это не msbuild проект — это генератор .vcxproj и .sln файлов. msbuild буйлдит эти проекты.

если в проекте поменять местами два айтема, ваши тесты упадут,

Не упадут. syncProj.exe unit test выдаст, что результат тестирования изменился, что будем делать дальше?

Учитывая, что мы находимся в статье про юнит-тесты — вполне себе суть.

Wiki странички не делают особой разницы между unit и integration testing.

От задачи зависит.

Кто-то утверждал, что у нас все готовое есть, и документация и описание тестирования, а как копнешься глубже оказывается что чего-то нет? :-)

А идея (одна из) тестов в том, чтобы по тестам можно было определить ожидаемое поведение SUT.

Ну в принципе ожидамое поведение — это полностью готовый .vcxproj файл. если не совпадает по линиям, то надо по линиям разбираться почему работает не верно.

Правда согласен — иногда это сложно. Как например с Xml Serializerом — order of fields при сериализации меняет порядок случайным образом. По мне это полный бред.

А зачем их сравнивать? Если известно, что должно генериться с тегом или без тега, значит, надо проверять наличие и отсутствие тега в выводе.

Тут ещё такая фишка, что да, я могу это протестировать отдельным unit testом, но кроме этого есть шанс что Visual Studio не одобрит того file formatа что я сгенерировал. Такое бывает правда редко, когда с моей точки зрения это правильный xml код, а с точки зрения Visual Studio полнейший бред. В тот момент когда я подозреваю что Visual Studio станет ругаться на мой проект, я просто открываю .vcxproj в студии и смотрю что она скажет. Т.е. мне иногда нужен не промежуточный результат тестирования, а именно конечный результат.

Конечный результат хорош тоже тем, что я не тестирую промежуточные результаты (где могут тестироваться также всякие ненужные штуки наподобии 2+2=4), а как весь код себя ведет с данной программой. Какие ошибки выдает. Понятны ли ошибки пользователю.

Если делать многоуровней код тестирования, то можно ли все unit test запустить за раз без колдовства?

Это же от требований зависит, а не от методики тестирования.

Требования, методика… — а на практике то как reference файлы сделаем? :-) Может есть предложения?

… вот только это не unit test.

Это наверное больше integration test, но не суть.

А идея (одна из) тестов в том, чтобы по тестам можно было определить ожидаемое поведение SUT.

Ну на данный момент ожидаемое поведение — это весь .vcxproj файл а также console output — но это довольно много информации за раз.

Что такое SUT?

Вообще зачем я этот тест изменил — была изначально разница работы vs2010 и vs2013 — там xml format .vcxproj немного отличается — в vs2010, vs2012, нет тага <DebugInformationFormat>None</DebugInformationFormat>

тут находится тот if который я покрыл тестированием

и результат изменения можно просмотреть сравнив файлы out_TestWindows_symbols_off_vs2013.vcxproj.accepted и out_TestWindows_symbols_off_vs2010.vcxproj.accepted между собой.

Во-вторых, ничто не мешает прочитать референсные файлы и сравнить результат работы SUT с ними.

Да, но нужна логика для создания reference файлов?
Или как вы думаете их создавать.

Но вообще я понимаю что тестирование именно даного бага можно было бы сделать именно разбив оригинальный код помодульно, и протестировать конкретно каждый модуль в отдельности. Просто сейчас я имею один механизм тестирования, а так вместо одного я имел бы 3 или 4 разноуровневых unit testа.
Как проще — не знаю — надо было бы пробовать оба метода. Но если честно одноуровневый unit test на данный момент меня устраивает.

И да — тебя наверное интересует как определить результат тестирования — т.е. что я этим тест кайсом тестирую — и это не так ясно. Моя идея в том что я сам на момент разработки знаю где и что должно находится, а если кто и переберет эту утилиту, то можно по svn diff отслеживать что и в какую сторону именилось — а по коду выяснять, что и где не работает.

Ну да, а в чем проблема? Или могу взять в экселе вбить, сделать колонку с суммами, выгрузить в csv, загрузить как теорию. Наконец, могу взять AutoFixture, генерить случайные, складывать и сравнивать.

Хорошо. Я усложню задачу.

sourceforge.net/p/syncproj/code/HEAD/tree/tests/CsToProjects/TestPerFileConfs

для TestPerFileConfs.cs, я хочу проверить что при данной конфигурации код / скрипт сгенерирует те 12 *accepted* файлов что там лежат?

Вобьешь каждую строчку Assert.Equal?

… а можно просто взять работающий и освоить минут за десять.

А за 5 можно и свой написать? :-)

[Fact]
public void PassingTest()
{
Assert.Equal(4, Add(2, 2));
}


Как я уже говорил — тут пишутся не только сам код, но и результат тестирования. а если я возьму более сложный пример — например 125374 + 832748 — будете на калькуляторе считать сколько получится? :-)

Имеет. Во-первых, для любого другого человека подключение стоит намного дороже (документации-то нет), во-вторых, каждую фичу надо дорабатывать.

Ну все при желании запиливается и документируется.
Думаю основой вопрос в каком направлении идти.

Для всех мейнстрим-фреймворков это время меньше, чем время на написание того же для своего фреймворка.

Да, вот это мне нравится больше всего — для «всех». Я знаю что их вагон и маленькая тележка. Можно до конца жизни посвятить себя изучению всех тестовых фреймворков, а можно написать свой и будет работать.

Собственно если вы говорите о мейнстрим-фрейворке, то можете дать линк на хорошую документацию, и как и что пишется?

Ну мне кажется готовый framework или свой framework особо разницы не имеет? Ну т.е. (1) может съесть время, например на допиливание своего frameworkа, но и готовый framework тоже может съёсть время — например на конфигурацию и подключение к buildам.

Хмм… Давайте начнем с начала.
Итак для того что бы запустить unit test

1) нам нужен некий unit test framework и начальный effort что бы его взять в использование

2) надо написать сами unit testы.

Я предполагаю что время ушедшее на развертку (1) пункта намного меньше чем (2). Т.е. если мы сделали (1) каким то образом, то он не съест у нас много времени в отличие от (2).

На этом этапе вы со мной согласны?

Мне все таки кажется что проще готовый заменить на мой — но тут это возможно мое субъективное мнение. Я думаю что если скажем писать unit test на библиотеку которая делать 3d подсчёты то наверное проще было бы использовать обычный unit test, но как только библиотека станет сложнее чем 2+2 — то уже проще перейдти на мой подход. Ну а для syncProj-утилиты проблема довольно специфическая — надо было бы проверять синтакс того что генерируется, можно сделать как это делается в premake5, но мне кажется это сложнее.

Но думаю что подход syncProj очень расширяемый — и на базы данных, и на любые файловые операции.

Возможно картинки он не сможет сравнивать, но это уже другой unit test домайн.

Кстати, нашёл один random fail — уже профиксил:

Revision: 130
Author: tarmopikaro
Date: 16. syyskuuta 2017 10:51:13
Message:
Bugfix: XmlSerializer was causing field reorder by itself, causing weird fails to appear
— Modified: /ProjectTypes.cs
Modified: /tests/ProjectsToCs/TestAllInOne/out_testproj.cs.accepted

Удивительно почему XmlSerializer вообще задает fieldы случайным образом.

Из следующего коммита — TestRunTime.cs — это тот тест что я написал, остальные 11 файлов сгенерированы и просто «одобрены» мною.

Да, готовые есть, но если можно сделать проще — почему бы не сделать?