Kashperuk Ivan: [Development tutorial] Thoughts on test automation + more sample tests using ATL

[EVGL]

Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.

Для клиентов придуман RSAT, а не ATL. Впрочем, RSAT тоже едва ли применяется на практике, поскольку невозможно продать. К примеру, Майкрософт не применяет RSAT на проектах.

[Stitch_MS]

Цитата:

Сообщение от EVGL

Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.

Мы не используем Contoso данные для наших тестов. Да, в некоторых тестовых примерах (ReturnOrderSampleTest) видно, что нужна компания USMF, но тот же SalesOrderSampleTest создает заказ на продажу и разносит накладную/счет-фактуру с нуля. Я так понимаю, всё можно тестировать без привязки к определенной компании, просто тесты будут медленнее. Из опыта, каждый новый юнит-тест класс минуту-две запускается и создает данные, каждый новый тест-метод - это 5..10 секунд. Грубо говоря, класс с десятком методов работает минуты 3..4. У меня больше времени ушло бы на запуск клиента и открытие первой формы на "холодной" системе.

В майкрософтовских примерах, кстати, используется перекрытый setup() метод. Это не очень хорошо для производительности. Лучше использовать setupTestCase() в паре с атрибутом SysTestCaseUseSingleInstanceAttribute. Тогда все данные создаются один раз для всех методов класса.

По поводу локализации - есть атрибут SysTestCaseCountryRegionDependencyAttribute.

Русские названия или нерусские - не должно влиять, если тестируется код, а не названия.

[mazzy]

Цитата:

Сообщение от Stitch_MS

В майкрософтовских примерах, кстати, используется перекрытый setup() метод. Это не очень хорошо для производительности.

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

Цитата:

Сообщение от Stitch_MS

Лучше использовать setupTestCase() в паре с атрибутом SysTestCaseUseSingleInstanceAttribute. Тогда все данные создаются один раз для всех методов класса.

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

[Stitch_MS]

Цитата:

Сообщение от mazzy

изолированность

Ну, теперь ведь используются SQL SavePoints, которые якобы справляются даже с падением АОСа и неожиданными исключениями? И побочные эффекты исключены?

См. диаграмму здесь, на странице 14.

[mazzy]

Цитата:

Сообщение от Stitch_MS

Ну, теперь ведь используются SQL SavePoints

они же не сохраняют и не восстанавливают состояние классов в памяти вроде.

[Stitch_MS]

Цитата:

Сообщение от mazzy

они же не сохраняют и не восстанавливают состояние классов в памяти вроде.

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

Но в нашем случае проблем не было, и тесты стали "пробегать" за 19 минут вместо 25, когда мы перешли с setup на setupTestCase.