AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.05.2021, 05:12   #1  
Blog bot is offline
Blog bot
Участник
 
24,301 / 817 (76) +++++++
Регистрация: 28.10.2006
Kashperuk Ivan: [Development tutorial] Thoughts on test automation + more sample tests using ATL
Источник: http://kashperuk.blogspot.com/2021/0...s-on-test.html
==============

I recently had an interesting discussion around testing and specifically Microsoft testing efforts and frameworks, namely, ATL. If you are not familiar with this framework - you've been living under a rock. Get out from under there and go read some articles about it, like the one belowhttps://kashperuk.blogspot.com/2019/05/development-tutorial-sample-test-tips.htmlThe discussion revolved around

Источник: http://kashperuk.blogspot.com/2021/0...s-on-test.html
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 24.05.2021, 15:16   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
990 / 1402 (48) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Интересная тема для обсуждения. Спасибо Ване что ответил
Есть ли кто-нибудь кто пытался внедрить данные тесты на проекте?
Несколько комментариев от меня.
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 страницы, чтобы можно было проверить его на разных данных. Далее уже вводится ручное тестирование.
У кого какие мысли по этому поводу?
Старый 24.05.2021, 16:16   #3  
axm2017 is offline
axm2017
Участник
 
522 / 199 (8) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от trud Посмотреть сообщение
Во первых если говорить об этом , то тут есть некий элемент неравенства. Microsoft тесты не публикует, кроме того, я подозреваю что тесты все более или менее похожие, т.е. разработчик Microsoft может например изменяя какой-либо класс найти все тесты для него(по предыдущим багам) и создать что-то похожее. У партнера/клиента такой информации нет, т.е. тест надо будет разрабатывать с нуля и каждый раз искать к примеру какой-же класс вызвать для создания заказа. Это по сути резко увеличивает стоимость использования данной функции.
Насколько слышал от ребят с МС довольно давно то кто то имеет доступ к тестам, что приводит к эксцессам так как код для тестов пишут из разряда тяп-ляп и в продакшен, что попадает на глаза партнеров и те начинают понимать уровень.
В моем представлении закрытие тестов от других - отрыжка колониального мышления. Уровень МС +- ясен (там работают люди и они порой допускают ошибки как и все) народ не рефлексирует находя ошибки а вот тестить сварганенное порой в запарке и не очень на предмет не сломал ли чего стандартного очень было бы удобно.

Цитата:
Сообщение от trud Посмотреть сообщение
Сами тесты - я честно говоря ожидал что они будут сложнее.
Сложный тест - большое время работы и сложности с пониманием. Это критично если тестов десятки или сотни тысяч. Опять же по слухам долгие тесты отрубают. В каком то смысле это интересно что на уровне архитектуры надо об этом подумать - микросервисы и вся фигня + удобство для тестирования


Цитата:
Сообщение от trud Посмотреть сообщение
Т.е. сами тесты требуют обслуживания, плюс время на их написание, плюс все же цена ошибки для партнера или клиента несколько меньше.
Да как и банальное тестирование тестером. При долгой жизни продукта авто тестирование более чем оправданно.


Цитата:
Сообщение от trud Посмотреть сообщение
Плюс опять же непонятно сколько время тратится в Microsoft на выполнение/поддержку/разработку этих тестов для каждого обновления, вполне возможно что это теже самые 1-2 месяца
На сколько слышал мало.
Запустил все тесты: если что то сломал, то получил ошибку. Если это не ошибка а тест некорректен - поправил тест.

Цитата:
Сообщение от trud Посмотреть сообщение
Экономическое обоснование. Тут любой клиент может возразить что "вот Microsoft пишет тесты, а кол-во багов в каждой версии остается большим.
В теории да и на практике число багов выявленных по старому функционалу уменьшается.

Цитата:
Сообщение от trud Посмотреть сообщение
В тоже время D365FO по сути полностью меняет концепцию АХ, которая заключалась в том, что не требуется время для обновление кода
На сколько представляю революция во взглядах индийского вождя МС: он за эволюцию а не революцию в развитии продукта. Типа у нас один продукт One(?) и мы его развиваем а не варганим новые 9 12 19 и тп. В таком контексте и сократили тестеров. И в главном он вполне себе прав.

Последний раз редактировалось axm2017; 24.05.2021 в 16:34.
Старый 25.05.2021, 10:02   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,618 / 5037 (173) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Самое интересное - в качестве примера приводятся ATL-тесты для ошибок, которые были найдены и зарегистрированы клиентами и партнерами (то есть - микрософтовские ATL-тесты их изначально не ловили). Партнеры и клиенты, естественно, нашли эти ошибки старым добрым методом проб и ошибок, возможно с использованием отладчика VS. После этого, делается вывод что, использование ATL-тестов может снизить затраты на тестирование после каждого обновления.
Старый 25.05.2021, 10:43   #5  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
345 / 373 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Мы используем юнит-тесты на проекте. Сейчас их уже полторы сотни. Без ATL это было бы нереально.

В основном они покрывают большие доработки, с каждым новым багом или сценарием дописывается новый тест или два.

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

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

Во многих случаях даже не приходилось запускать UI перед чекином, потому-что TDD в паре с ATL рулит.

Из трудностей - слишком мало примеров ATL тестов, и нередко приходится копаться в Atl* классах, чтобы понять, как их правильно применить.

Исправлять существующие тесты приходилось редко, потому-что старые требования практически не менялись, а только появлялись новые.
За это сообщение автора поблагодарили: trud (3).
Старый 25.05.2021, 11:24   #6  
axm2017 is offline
axm2017
Участник
 
522 / 199 (8) ++++++
Регистрация: 15.05.2017
Основной вопрос почему МС не откроет свои тесты для всех.
Это бы сильно помогло клиентам проверять свои решения на предмет а не ломаем ли мы стандарт.
Старый 25.05.2021, 11:27   #7  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,618 / 5037 (173) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Мы используем юнит-тесты на проекте. Сейчас их уже полторы сотни. Без ATL это было бы нереально.
Поскольку это - первый зарегистрированный мною случай использования ATL за пределами микрософта, хотелось бы узнать:
1. Сколько разработчиков на проекте
2. Какой примерно бизнес у конечного клиента
3. Кто "продал" клиенту идею разработки автоматизированных тестов (партнер, Микрософт или сам клиент настоял)
4. Насколько давно идет проект ? Запустились уже или нет и сколько микрософтовских обновлений пережили ?
Старый 25.05.2021, 12:02   #8  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,554 / 2714 (100) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Основной вопрос почему МС не откроет свои тесты для всех.
В посте же

2. We do not ship our test automation library. The code is not written with shipping in mind, so it's not necessarily "Microsoft production quality". The value for customers is also marginal.

И еще:

Björn
September 8, 2006
Too bad no tests are included. It would be good to have them both for testing if a modification breaks existing functionality, as well as having an example how to use existing code.

Can you tell us why they aren't shipped with the final release?
dpokluda
September 8, 2006
Re Bjorn: I totally understand what you're saying and I agree that it might be a help for all the partners if they would have some of our tests. On the other hand I also understand others saying that the value of shipping the tests wouldn't be so big since with all the modifications (made by partners) most of the tests would either not compile or fail anyway. Partners would either have to invest heavily to update all the tests (and repeat that investment with every release) or to investigate every failure to find out whether it is a valid failure or not.

On top of that you have to understand that there is different bar for code quality for tests. Therefore we don't really want to publish/ship those classes with the product. I remember that there were some thoughts about shipping our test automation framework with one of our test suites but since test automation framework doesn't meet our shipping code quality bar we never did that.
__________________
blog | twitter
Старый 25.05.2021, 12:14   #9  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,116 / 2638 (96) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от fed Посмотреть сообщение
Поскольку это - первый зарегистрированный мною случай использования ATL за пределами микрософта
GWS из Мюнстера (где небезызвестный Paul Heisterkamp), кажется, тоже использует. Вообще, для ISV это нормально.

Цитата:
Сообщение от axm2017 Посмотреть сообщение
Основной вопрос почему МС не откроет свои тесты для всех.
Это бы сильно помогло клиентам проверять свои решения на предмет а не ломаем ли мы стандарт.
Ну, это еще надо доказать, что помогло бы. У всех свои данные, а тесты делаются под данные (Contoso).
Старый 25.05.2021, 12:25   #10  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,554 / 2714 (100) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от EVGL Посмотреть сообщение
Ну, это еще надо доказать, что помогло бы. У всех свои данные, а тесты делаются под данные (Contoso).
Часть данных создается кодом под конкретный тест или множество тестов. ATL,
собственно, облегчает это.
__________________
blog | twitter
Старый 25.05.2021, 12:30   #11  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,116 / 2638 (96) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.

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

Последний раз редактировалось EVGL; 25.05.2021 в 12:33.
Старый 25.05.2021, 12:32   #12  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,618 / 5037 (173) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от EVGL Посмотреть сообщение
GWS из Мюнстера (где небезызвестный Paul Heisterkamp), кажется, тоже использует. Вообще, для ISV это нормально.
Я еще подозреваю что Inways (с Флорианом, если знаешь его) тоже их для своего ISV-решения по работе с банком использует.
Я могу поверить, что начиная с какого-то числа клиентов для ISV эти затраты отбиваются. Но мне очень трудно поверить что они отобьются для партнера, который на конечном заказчике внедряет. (Особенно с учетом того что все равно все тестировать надо, чтобы не наткнуться на проблемы с микрософтовскими изменениями).
За это сообщение автора поблагодарили: Vadik (1).
Старый 25.05.2021, 12:45   #13  
axm2017 is offline
axm2017
Участник
 
522 / 199 (8) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от belugin Посмотреть сообщение
The code is not written with shipping in mind, so it's not necessarily "Microsoft production quality". The value for customers is also marginal. [/I]
В общем как понимаю ложный стыд (если не видно то никто не узнает что мы человеки).

Значение для клиентов довольно велико так как сильно снижает вероятность сломать стандартный функционал доработками.

Последний раз редактировалось axm2017; 25.05.2021 в 12:48.
Старый 25.05.2021, 12:47   #14  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
345 / 373 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от fed Посмотреть сообщение
1. Сколько разработчиков на проекте
2. Какой примерно бизнес у конечного клиента
3. Кто "продал" клиенту идею разработки автоматизированных тестов (партнер, Микрософт или сам клиент настоял)
4. Насколько давно идет проект ? Запустились уже или нет и сколько микрософтовских обновлений пережили ?
1. Сейчас 5 или 6. Юнит-тесты писали только трое.

2. Текстиль - производство и продажа. Сильно доработан и активно используется модуль Warehouse management.

3. Никто не продавал. Моя собственная инициатива. Когда показал другому разработчику этот ATL - товарищ сразу начал строчить свои собственные тесты для своей большой доработки, хотя пришлось помочь вначале из-за отсутствия примеров.
В нашей конторе думают о "продаже" автоматических тестов клиентам в будущем, но вполне может быть, что не взлетит, или не сразу взлетит.
Разработчики должны уметь это делать и понимать все плюсы хотя бы для себя, плюс иметь какой-то опыт. А это займёт время. Сам -то я тесты писал, и много, когда в Майкрософте работал, ну и книжки нужные читал, поэтому изучение ATL далось легко. Другим, не имеющим опыта написания юнит-тестов по причине геморроя с соозданием тестовых данных до ATL, труднее. Опять же, многие не читали толстых книг по программированию/TDD. У них отсутствуют некоторые полезные концепции в голове.

4. Проекту года 3, запустились где-то год назад. Вот и считайте. На последнем обновлении несколько тестов стали падать, потому-что при разноске накладной стал вызываться диалог печати в PDF - какой-то Flight активировался, но это исправили в коде кастомизации.
За это сообщение автора поблагодарили: belugin (10), sukhanchik (10).
Старый 25.05.2021, 13:10   #15  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
345 / 373 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от EVGL Посмотреть сообщение
Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.
Мы не используем Contoso данные для наших тестов. Да, в некоторых тестовых примерах (ReturnOrderSampleTest) видно, что нужна компания USMF, но тот же SalesOrderSampleTest создает заказ на продажу и разносит накладную/счет-фактуру с нуля. Я так понимаю, всё можно тестировать без привязки к определенной компании, просто тесты будут медленнее. Из опыта, каждый новый юнит-тест класс минуту-две запускается и создает данные, каждый новый тест-метод - это 5..10 секунд. Грубо говоря, класс с десятком методов работает минуты 3..4. У меня больше времени ушло бы на запуск клиента и открытие первой формы на "холодной" системе.

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

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

Русские названия или нерусские - не должно влиять, если тестируется код, а не названия.
За это сообщение автора поблагодарили: Logger (1).
Старый 25.05.2021, 13:24   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,360 / 4225 (199) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
В майкрософтовских примерах, кстати, используется перекрытый setup() метод. Это не очень хорошо для производительности.
но очень хорошо для изолированности
если в тестируемый код изменяет исходные данные в качестве побочного эффекта...

Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Лучше использовать setupTestCase() в паре с атрибутом SysTestCaseUseSingleInstanceAttribute. Тогда все данные создаются один раз для всех методов класса.
не всегда.
а когда не знаешь, есть ли там побочные эффекты, то изолированность - не такая уж требовательная штука.
__________________
Полезное на axForum, GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 25.05.2021, 13:29   #17  
trud is offline
trud
Участник
Лучший по профессии 2017
 
990 / 1402 (48) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Спасибо за ответы. А RSAT используете/планируете использовать?
Цитата:
На последнем обновлении несколько тестов стали падать, потому-что при разноске накладной стал вызываться диалог печати в PDF
Вот это то что обычно напрягает. ну т.е. любые тесты(как в целом и код) после написания надо поддерживать, т.е. они не будут бесплатными. Главный вопрос - насколько они оправдывают траты? А те положительные срабатывания что были - вы их анализировали, могли бы они пойматься другими процедурами перед деплоем в прод? (например code review, ручное тестирование и пр.)
А 5-6 человек - это разработчики получающие зарплату на клиентском проекте и вы работаете на клиенте?
Старый 25.05.2021, 13:34   #18  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
345 / 373 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от mazzy Посмотреть сообщение
изолированность
Ну, теперь ведь используются SQL SavePoints, которые якобы справляются даже с падением АОСа и неожиданными исключениями? И побочные эффекты исключены?

См. диаграмму здесь, на странице 14.
Старый 25.05.2021, 13:46   #19  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
345 / 373 (13) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от trud Посмотреть сообщение
1) А RSAT используете/планируете использовать? ...
2) Главный вопрос - насколько они оправдывают траты?
3) А те положительные срабатывания что были - вы их анализировали, могли бы они пойматься другими процедурами перед деплоем в прод? (например code review, ручное тестирование и пр.)
4) А 5-6 человек - это разработчики получающие зарплату на клиентском проекте и вы работаете на клиенте?
1) Я слышал разговоры про RSAT от наших консультанов, но все какие-то абстрактные. Реальных примеров использования на наших клиентах не помню.
Из опыта, Майкрософт очень советовал одному из наших старых клиентов RSAT, но в итоге не закончилось ничем, потому-что у клиента были жесткие требования по сторонним продуктам из соображений безопасности, и для установки RSAT хотя бы на одном ноутбуке требовалось специальное разрешение. Но там клиент был особый, связанный с банковскими системами Не знаю, может ситуция у них поменялась с тех пор.

2) Очень зависит. По-моему, идеальный сценарий для юнит-тестов - это или ISV решение, или большая доработка с кучей разных сценариев, которая пухнет по мере поступления новых желаний клиента.

3) Могли бы, наверное, если бы разработчик тестировал побочные сценарии, что происходит нечасто, или если бы код ревью делал именно тот, чьи тесты упали.

4) Мы партнеры на клиенте.
Старый 25.05.2021, 13:46   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,360 / 4225 (199) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Ну, теперь ведь используются SQL SavePoints
они же не сохраняют и не восстанавливают состояние классов в памяти вроде.
__________________
Полезное на axForum, GitHub, Facebook, mazzy.priot, mazzy.music, coub.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Kashperuk Ivan: [Development tutorial] Sample test + tips for using ATL (Acceptance Test Library) to implement tests in Warehouse management Blog bot DAX Blogs 0 21.05.2019 02:53
Kashperuk Ivan: Development tutorial: SysExtension framework with SysExtensionIAttribute and an Instantiation strategy Blog bot DAX Blogs 0 01.04.2017 02:17
Kashperuk Ivan: Development tutorial: SysExtension framework in factory methods where the constructor requires one or more arguments Blog bot DAX Blogs 4 19.03.2017 23:56
Kashperuk Ivan: Development tutorial: Extensible base enumerations in Microsoft Dynamics AX 7 Blog bot DAX Blogs 0 27.09.2016 00:19
NAV Team: Test Automation and Test Data Blog bot Dynamics CRM: Blogs 0 01.10.2010 12:56
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:07.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.