Application Verifier для программиста: тестирование Windows-приложений

[RedricShuhart]

Программа функциональная, но отделам бэта-тестирования волноваться, думаю, рано)

[sic]

Это так, пока разработка самого AppVerifier'а ведется в сторону увеличения функциональности и покрытия тестами потенциальных проблем, но тулза всё равно остается удобной только программистам в силу специфики использования. А на этапе бета-тестирования уже поздно узнавать о неправильном вызове CloseHandle…

Хотя мы внедрили применение тулзы в отделе тестирования, и результат в скором времени очень порадовал :)

[MKrivosheev]

А где работаете, если не секрет?

[sic]

ответил в личку.

[Umnik_ADS]

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

[AigizK]

А как быть программам, написанным на C#? Для них другая тулза или такие программы вообще не могут получить логотип? ))

[nzeemin]

Для managed-кода чаще всего используется FxCop, тоже от MS.

[sic]

Могут, и скорее всего на них есть какие-то дополнительные требования, но проверки AppVerifier'ом никто не отменяет — и да, группа Basics заведомо проходится любым приложением на C# без unmanaged (а для unmanaged имеют смысл почти все тесты кроме Exceptions), но от ошибок LuaPriv не застраховано не одно приложение имеющее доступ к файлам, реестру, ShellExecute.

[nzeemin]

Было бы неплохо в самом начале статьи показать область — что это Win32/Win64, поскольку «Application Verifier is a runtime verification tool for unmanaged code.»
А для дотнета есть FxCop + StyleCop.
Ну и в целом — средства статического анализа не ограничиваются перечисленным, есть и другие.

[sic]

Спасибо. Модифицировал теги к топику. На самом деле не стоит так жестко отметать применимость AV к managed коду, он все равно использует тот же API.

А FxCop решает немного другую задачу, но у managed кода и другие цели. Но инструмент более чем достойный внимания.

[kettle]

Возможно в Вашем проекте и не пишут try { /* code */ } catch(...) { }

Если бы вы тока знали....

[Nashev]

А вот я не понял, чем оно так уж плохо? Поясните?

[kettle]

Процитирую

… произойти все что угодно в любой строке. Тогда программист начинает писать вещи типа
try {  
   dosomething(); 
} 
catch(...){
   /*do nothing*/ 
}
которые гасят все исключения, и вот тогда это действительно становится проблемой. Потому что его код, работая в среде, где все доверяют исключениям, начинает врать, что все хорошо, даже когда все плохо. Никогда не съедайте все исключения, съедайте только те, за которые отвечает ваша функция.

И от себя добавлю пару слов. На проекте с действительно широкой аудиторией, написанном изначально весьма посредственно, в один из дней решено было обернуть подозрительную область в такой try{}. Потом появился второй, третий… Подобный стиль, в купе с несинхронизированной многопоточностью, привёл к появлению креш репортов указывающих на, скажем, объявление переменной типа int. Стало в порядке вещей, что во время выполнения метода класса, где-то в его серединке, указатель this занулялся, или принимал жуткое значение, указывающие в никуда. Это всё признаки покорапченного стека и прочей нечести.

Всегда при ошибке нужно как минимум делать запись в лог, что бы потом найти её источник. Подобный try{}catch{} — это поведение страуса который прячет голову в песок прячась от проблем.

[Nashev]

О! вот именно этого /*do nothing*/ мне и не хватало для понимания. В таком варианте — это действительно зло.

[Terror]

Для получения логотипа в логе не должно быть ни одного Warning-a, Error-а?

[sic]

Ни одного Error'а. Просто некоторые из Warning'ов уже к следующей версии AppVerifier'а могут превратиться в Error'ы, особенно, скажем, связанные с DangerousAPI (функция может стать deprecated). Но, поскольку сейчас проверка выполняется стороной самих разработчиков, достаточно просто убедиться что нет Errors перед отправкой лога.
Если тема Вас заинтересовала могу посоветовать документ от майкрософт.

[Terror]

Спасибо за ссылку.
Попробовал прогнать на простейшем приложении на базе WTL, включил LuaPriv, получил кучу ошибок и предупреждений, все связаны с ATL. Стоит ли на это обращать внимание?

[sic]

Если стек вызова растет из MessageBoxW то можете смело игнорировать, но это не ошибка WTL (про это я уже задавал вопрос представителям Microsoft на конференции по совместимости с Vista). Хотелось бы каких-то частностей, чтобы можно было исследовать вопрос.

[AndrewTishkin]

А что с картинками к статье? :(

[sic]

исправил… ох уж этот дропбокс.