Pull to refresh
56
0
Send message
Можно, но если работаешь с какой-то известной библиотекой, то по деталям ошибки сразу можно определить ее причину.

Примечание: как оказалось, код показанный выше далеко не всегда даст английскую локализацию. Чаще всего строка информации формируется во время исключения, а не при первом обращении к Message (можно посмотреть в Reflector).
Клиент не должен. Вам от него логи приходят. А в логах исключения с локалью пользователя.
На машинах клиентов тоже будете английскую локаль ставить?
У вас же будут где-то централизовано ловиться исключения.

private void CurrentDomain_UnhandledException( object sender, UnhandledExceptionEventArgs args )
{
    var current = Thread.CurrentThread.CurrentUICulture;
    Thread.CurrentThread.CurrentUICulture = new CultureInfo( "en-US" );
    Logger.Error( args.ExceptionObject as Exception );
    Thread.CurrentThread.CurrentUICulture = current;
}

Смотря как реализована зависимость. Если это C++/CLI сборка, то Assembly.Load должен сработать.

Если это native dll, то тут нужно гуглить такую же статью на С++. В SysInternals инструментах это реализовано, так что должен быть соответствующий WinAPI вызов. Может у Рихтера в книге даже реализация найдется. В любом случае нужно будет перехватывать PInvoke вызовы к unmanaged DLL. Либо PInvoke обертки выделять в отдельные сборки и анализировать в AssemblyResolve, либо пробовать приспособить TypeResolve, либо принять соглашение об именовании таких оберток и использовать аспектное программирование.
Только для кода основного exe.
То, что хранится в ресурсах, будет JIT компилится всегда, похоже.
Не подписывался. После отработки AssemblyResolve CLR сам находит типы из уже загруженных в память сборок.
Да, я знаю. Неаккуратно написал. Там используется такая же функциональность, я показал как реализовать под .NET.
Да, к сожалению, такой магии не будет =)
М… Фактически тесты генерируются по спецификациям. Вручную нужно написать:
— спецификации.
— get акксессор, если для свойства он еще не определен.
— дескриптор свойства, если для данного типа свойств он еще не определен.

У меня в последнем проекте такая статистика:
— 56 спецификаций, в которых в сумме проверяется 216 свойств
— 21 аксессор
— 3 пользовательских дескриптора

Фактически тестом можно считать одно проверяемое свойство в спецификации. Тест генерируется из ожидаемых данных спецификации, действительных данных из аксессора и логики сопоставления из дескриптора.

Не знаю как сделано в Code Contract, но в Design By Contract проверка выглядит примерно так (проверки в статическом классе Check):

public double GetParameter( Vector point )
{
    Check.Require( !Direction.IsZeroLength, "Направление линии не должно быть вырожденным" );

    var t = new List<double>( 2 );

    // Параметры t по значимым осям
    if( Op.Nz( Direction.X ) )
    {
        t.Add( ( point.X - Begin.X ) / Direction.X );
    }
    if( Op.Nz( Direction.Y ) )
    {
        t.Add( ( point.Y - Begin.Y ) / Direction.Y );
    }

    // Проверка на то что параметр t существует и корректен
    Check.Ensure( t.Count > 0, "Если точка лежит на линии, то у нее должен быть определен параметр" );
    Check.Ensure( Op.Eq( t.Max( ), t.Min( ) ), "Разброс значений параметра t не должен быть больше заданной точности" );

    // Возвращаем среднее значение
    return t.Average( );
}


Своей цели обезопасить программу от неверных данных он служит. Мне Design By Contract в таком виде нравится.
Где именно?

Я слышал только об одном Code Contract — библиотека от MS, которая, кажется, скоро должна выйти. Давно не смотрел, что же она в итоге умеет. Потому что когда ее только объявили, я увидел, что это просто развитие идеи Design-by-Contract от Billy McCafferty — devlicio.us/blogs/billy_mccafferty/archive/2006/09/22/design_2d00_by_2d00_contract_3a00_-a-practical-introduction.aspx. А до него, кстати, это было в языке Eiffel.

В общем, если под Code Contract подразумевается явное указание того, какие данные требуются на входе и выходе метода, то это не интеграционное тестирование. У меня такие проверки есть — класс Utils.Common.Check. Эти проверки не предназначены для тестирования системы — это скорее защита программы от некорректных данных.
Еще раз повторяю — нагрузочное тестирование из другой классификации.
en.wikipedia.org/wiki/Software_testing#Non_Functional_Software_Testing

Один и тот же тест можно отнести в разные группы по разным срезам классификаций. Нагрузочное тестирование, как правило, происходит либо при системном тестировании, либо при интеграционном.
Приведена классификация по критерию «степень изолированности кода». У меня это явно указано.
Классифицировать можно по разным критериям.
Я не претендую на новизну идеи. С Fitnesse не знаком и его возможностей не знаю. Но поглядев на их Wiki могу сказать, что движок Fitnesse очень отличен от моего:

1) Отношение к тестовым данным.

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

У меня тестовые данные находятся либо в самой спецификации, либо в отдельном файле. В обоих случаях файлы хранятся в DLL тестового проекта как Embedded Resource. Это позволяет:
— Включать интеграционные тесты вместе со всеми данными в систему контроля версий.
— Всегда иметь под рукой спецификации и тестовые данные, когда работаешь в студии.

2) Считывание пользовательских типов данных.

Насколько просто в Fitnesse считать из спецификации данные такого вида?

$Vertices =
(0;0) (4;0) (4;3) (0;3)
(0;2) (2;2) (2;3) (0;3)
(0;1) (3;1) (3;3) (0;3)

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

3) Ориентированность

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

Это отличие продиктовано отношением к тестовым данным. У меня сложилось впечатление, что Fitnesse ориентирован на более низкоуровневое unit-тестирование. У меня же упор на интеграционное. Мне сложно объяснить без демонстрации кода. Скоро опубликую статью про мой движок, там покажу что я имею ввиду.

4) Чистота кода

Мой движок не требует объявлять место хранения для свойств в классе. Такого вида код не встречается (http://schuchert.wikispaces.com/FitNesse.Tutorials.1):

private int channel;
public void setChannel(int channel) {
this.channel = channel;
}

Такой код никому не интересен. Зачем писать служебный код? Он не решает задачу тестирования. В коде должны быть вычисления реальных значения свойств, а данные уже есть в спецификации.

5) Простой тестовый вывод

У меня простой движок, он не генерирует HTML отчеты. У него простой консольный вывод в котором указано все что требуется программисту для исправления ошибки. При тестировании из-под студии консольный вывод сохраняется в результатах прогона теста.
Не стоит тут искать глубинного смысла.
null подсвечивается, а exception по поводу не инициализированного свойства я вижу максимум один раз.
Это нарошно =)
Чтобы кидались исключения когда не инициализирую.
В том проекте инициализация свойств была довольно сложной. Не в плане вычислений, а в плане выставления зависимостей. Поэтому я специально вставлял null, чтобы если забуду инициализировать кинулось NullReferenceException.

А так да, в общем случае вызывать конструктор по умолчанию полезно.
Честно говоря я не знал про WindowsAPICodePack. Сейчас скачал его, посмотрел семплы. В чем отличия от Ookii:
— API.
— Некоторые диалоги реализованы только под WinForms
— Не нашел Credentials диалога

В Ookii два варианта диалогов — с зависимостью от WinForms библиотек или с зависимостью от WPF. Совместимость с предыдущими виндами нужно проверять на конкретных диалогах.
1

Information

Rating
Does not participate
Registered
Activity