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

[trud]

Интересная тема для обсуждения. Спасибо Ване что ответил
Есть ли кто-нибудь кто пытался внедрить данные тесты на проекте?
Несколько комментариев от меня.
1.
Во первых если говорить об этом

Цитата:

ATL is a framework which allows to write robust (and reasonably fast) test automation with a low cost investment, all things considered.

, то тут есть некий элемент неравенства. Microsoft тесты не публикует, кроме того, я подозреваю что тесты все более или менее похожие, т.е. разработчик Microsoft может например изменяя какой-либо класс найти все тесты для него(по предыдущим багам) и создать что-то похожее. У партнера/клиента такой информации нет, т.е. тест надо будет разрабатывать с нуля и каждый раз искать к примеру какой-же класс вызвать для создания заказа. Это по сути резко увеличивает стоимость использования данной функции.
2.
Сами тесты - я честно говоря ожидал что они будут сложнее. Т.е. у нас когда я работал для ISV и мы пытались придумать что-то похожее была следующая проблема. Есть различные типы номенклатур, к ним могут привязываться различные типы накладных расходов, разные налоги и т.п.. В итоге мы приходили что всего возможно миллионы различных входных комбинаций образованных сочетанием этих параметров, т.е. получается большая трудоемкость.
Тут сделано оригинально - любой баг проверяется на самом простом примере по сути с 1 номенклатурой. В целом непонятно хорошо это или плохо. С одной стороны тест читается, с другой возникает вопрос - Насколько полезны такие тесты? ну т.е. я сходу не вспомнил примеров когда что-то что работало на одних данных вдруг переставало работать, но есть много примеров когда переставало работать на других входных данных, данные тесты по сути это не покрывают. Хотелось бы посмотреть какой тип ошибок данные тесты смогли предотвратить и когда их срабатывание было ложным. Но это по сути потребует перевода текущей разработки Microsoft в опен сорс, чего я как понял никто не обещает
3.
По поводу этого

Цитата:

Very frequently today, even with some of our larger customers, we hear test cycles of 1-2 months before taking a newer standard release. That puts a significant on-going cost on the customer, as well as stress, as we at Microsoft keep pushing everyone to be current. This could have been mostly alleviated with test automation

Да, это реальная проблема. Такой огромный срок возникает она из-за того, что нет одного человека кто способен протестить все процессы, т.е. это размазывается на несколько человек, получается такой огромный срок. Если есть кто-то один, то как правило срок тестирования меньше, для достаточно большого ISV решения это было 1-2 дня
Но опять же большой вопрос как тесты это способны решить. Т.е. сами тесты требуют обслуживания, плюс время на их написание, плюс все же цена ошибки для партнера или клиента несколько меньше. Плюс опять же непонятно сколько время тратится в Microsoft на выполнение/поддержку/разработку этих тестов для каждого обновления, вполне возможно что это теже самые 1-2 месяца
4.
Экономическое обоснование. Тут любой клиент может возразить что "вот Microsoft пишет тесты, а кол-во багов в каждой версии остается большим. Т.е. зачем они нужны нам?". Причем это по сути перекликается с пунктом 2. Взять хотя бы вот эту ошибку

Цитата:

533573 Creating a sales order’s work without a pick location is not updating the on-hand figures correctly.

Т.е. тут был какой-то один процесс, который работал и для которого был написал тест, но который перестал работать если в шапке заказа не указана pick location. Я так понимаю достаточно редкий случай, но по сути большинство ошибок представляет из себя нечто подобное, на вход подаются другие данные и процесс перестает работать.

В тоже время D365FO по сути полностью меняет концепцию АХ, которая заключалась в том, что не требуется время для обновление кода. Критичная ошибка по сути могла быть исправлена путем быстрого накатывания нового кода, оперативного написание джобов. Т.е. в новой концепции данного нет, поэтому важность механизма тестирования крайне возрастает. Я как-то видел решение в неком гибрите, т.е. у нас есть некая функциональность, позволяющая там генерить тестовые данные, т.е. к примеру если это сопоставления должна быть одна кнопка, которая может создать разные типы документов, и оплаты по ним, чтобы можно было любой кейс довольно просто сгенерировать. Или если мы делаем отчет, должна быть какая-то генерация документов, чтобы этот отчет занимал 1, 2 и 3 страницы, чтобы можно было проверить его на разных данных. Далее уже вводится ручное тестирование.
У кого какие мысли по этому поводу?