24.05.2021, 05:12 | #1 |
Участник
|
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 |
Участник
|
Интересная тема для обсуждения. Спасибо Ване что ответил
Есть ли кто-нибудь кто пытался внедрить данные тесты на проекте? Несколько комментариев от меня. 1. Во первых если говорить об этом Цитата:
ATL is a framework which allows to write robust (and reasonably fast) test automation with a low cost investment, all things considered.
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
Но опять же большой вопрос как тесты это способны решить. Т.е. сами тесты требуют обслуживания, плюс время на их написание, плюс все же цена ошибки для партнера или клиента несколько меньше. Плюс опять же непонятно сколько время тратится в 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.
В тоже время D365FO по сути полностью меняет концепцию АХ, которая заключалась в том, что не требуется время для обновление кода. Критичная ошибка по сути могла быть исправлена путем быстрого накатывания нового кода, оперативного написание джобов. Т.е. в новой концепции данного нет, поэтому важность механизма тестирования крайне возрастает. Я как-то видел решение в неком гибрите, т.е. у нас есть некая функциональность, позволяющая там генерить тестовые данные, т.е. к примеру если это сопоставления должна быть одна кнопка, которая может создать разные типы документов, и оплаты по ним, чтобы можно было любой кейс довольно просто сгенерировать. Или если мы делаем отчет, должна быть какая-то генерация документов, чтобы этот отчет занимал 1, 2 и 3 страницы, чтобы можно было проверить его на разных данных. Далее уже вводится ручное тестирование. У кого какие мысли по этому поводу? |
|
24.05.2021, 16:16 | #3 |
Участник
|
Цитата:
Сообщение от trud
Во первых если говорить об этом , то тут есть некий элемент неравенства. Microsoft тесты не публикует, кроме того, я подозреваю что тесты все более или менее похожие, т.е. разработчик Microsoft может например изменяя какой-либо класс найти все тесты для него(по предыдущим багам) и создать что-то похожее. У партнера/клиента такой информации нет, т.е. тест надо будет разрабатывать с нуля и каждый раз искать к примеру какой-же класс вызвать для создания заказа. Это по сути резко увеличивает стоимость использования данной функции.
В моем представлении закрытие тестов от других - отрыжка колониального мышления. Уровень МС +- ясен (там работают люди и они порой допускают ошибки как и все) народ не рефлексирует находя ошибки а вот тестить сварганенное порой в запарке и не очень на предмет не сломал ли чего стандартного очень было бы удобно. Сложный тест - большое время работы и сложности с пониманием. Это критично если тестов десятки или сотни тысяч. Опять же по слухам долгие тесты отрубают. В каком то смысле это интересно что на уровне архитектуры надо об этом подумать - микросервисы и вся фигня + удобство для тестирования Цитата:
Цитата:
Запустил все тесты: если что то сломал, то получил ошибку. Если это не ошибка а тест некорректен - поправил тест. Цитата:
На сколько представляю революция во взглядах индийского вождя МС: он за эволюцию а не революцию в развитии продукта. Типа у нас один продукт One(?) и мы его развиваем а не варганим новые 9 12 19 и тп. В таком контексте и сократили тестеров. И в главном он вполне себе прав. Последний раз редактировалось axm2017; 24.05.2021 в 16:34. |
|
25.05.2021, 10:02 | #4 |
Moderator
|
Самое интересное - в качестве примера приводятся ATL-тесты для ошибок, которые были найдены и зарегистрированы клиентами и партнерами (то есть - микрософтовские ATL-тесты их изначально не ловили). Партнеры и клиенты, естественно, нашли эти ошибки старым добрым методом проб и ошибок, возможно с использованием отладчика VS. После этого, делается вывод что, использование ATL-тестов может снизить затраты на тестирование после каждого обновления.
|
|
25.05.2021, 10:43 | #5 |
Участник
|
Мы используем юнит-тесты на проекте. Сейчас их уже полторы сотни. Без ATL это было бы нереально.
В основном они покрывают большие доработки, с каждым новым багом или сценарием дописывается новый тест или два. Уже была пара случаев, когда разработчики что-то ломали и не могли зачекинить своё из-за чужих падающих тестов. Но основное преимущество, как по мне - это сниженные временные затраты на перетестирование большой фичи после очередного исправления. Запустить все тесты на полчаса и пойти пообедать, а потом вернуться и видеть что все тесты прошли - приятно. Во многих случаях даже не приходилось запускать UI перед чекином, потому-что TDD в паре с ATL рулит. Из трудностей - слишком мало примеров ATL тестов, и нередко приходится копаться в Atl* классах, чтобы понять, как их правильно применить. Исправлять существующие тесты приходилось редко, потому-что старые требования практически не менялись, а только появлялись новые. |
|
|
За это сообщение автора поблагодарили: trud (3). |
25.05.2021, 11:24 | #6 |
Участник
|
Основной вопрос почему МС не откроет свои тесты для всех.
Это бы сильно помогло клиентам проверять свои решения на предмет а не ломаем ли мы стандарт. |
|
25.05.2021, 11:27 | #7 |
Moderator
|
Цитата:
1. Сколько разработчиков на проекте 2. Какой примерно бизнес у конечного клиента 3. Кто "продал" клиенту идею разработки автоматизированных тестов (партнер, Микрософт или сам клиент настоял) 4. Насколько давно идет проект ? Запустились уже или нет и сколько микрософтовских обновлений пережили ? |
|
25.05.2021, 12:02 | #8 |
Участник
|
В посте же
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. |
|
25.05.2021, 12:14 | #9 |
Banned
|
Цитата:
Ну, это еще надо доказать, что помогло бы. У всех свои данные, а тесты делаются под данные (Contoso). |
|
25.05.2021, 12:25 | #10 |
Участник
|
|
|
25.05.2021, 12:30 | #11 |
Banned
|
Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.
Для клиентов придуман RSAT, а не ATL. Впрочем, RSAT тоже едва ли применяется на практике, поскольку невозможно продать. К примеру, Майкрософт не применяет RSAT на проектах. Последний раз редактировалось EVGL; 25.05.2021 в 12:33. |
|
25.05.2021, 12:32 | #12 |
Moderator
|
Цитата:
Я могу поверить, что начиная с какого-то числа клиентов для ISV эти затраты отбиваются. Но мне очень трудно поверить что они отобьются для партнера, который на конечном заказчике внедряет. (Особенно с учетом того что все равно все тестировать надо, чтобы не наткнуться на проблемы с микрософтовскими изменениями). |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
25.05.2021, 12:45 | #13 |
Участник
|
Цитата:
Значение для клиентов довольно велико так как сильно снижает вероятность сломать стандартный функционал доработками. Последний раз редактировалось axm2017; 25.05.2021 в 12:48. |
|
25.05.2021, 12:47 | #14 |
Участник
|
Цитата:
Сообщение от fed
1. Сколько разработчиков на проекте
2. Какой примерно бизнес у конечного клиента 3. Кто "продал" клиенту идею разработки автоматизированных тестов (партнер, Микрософт или сам клиент настоял) 4. Насколько давно идет проект ? Запустились уже или нет и сколько микрософтовских обновлений пережили ? 2. Текстиль - производство и продажа. Сильно доработан и активно используется модуль Warehouse management. 3. Никто не продавал. Моя собственная инициатива. Когда показал другому разработчику этот ATL - товарищ сразу начал строчить свои собственные тесты для своей большой доработки, хотя пришлось помочь вначале из-за отсутствия примеров. В нашей конторе думают о "продаже" автоматических тестов клиентам в будущем, но вполне может быть, что не взлетит, или не сразу взлетит. Разработчики должны уметь это делать и понимать все плюсы хотя бы для себя, плюс иметь какой-то опыт. А это займёт время. Сам -то я тесты писал, и много, когда в Майкрософте работал, ну и книжки нужные читал, поэтому изучение ATL далось легко. Другим, не имеющим опыта написания юнит-тестов по причине геморроя с соозданием тестовых данных до ATL, труднее. Опять же, многие не читали толстых книг по программированию/TDD. У них отсутствуют некоторые полезные концепции в голове. 4. Проекту года 3, запустились где-то год назад. Вот и считайте. На последнем обновлении несколько тестов стали падать, потому-что при разноске накладной стал вызываться диалог печати в PDF - какой-то Flight активировался, но это исправили в коде кастомизации. |
|
|
За это сообщение автора поблагодарили: belugin (10), sukhanchik (10). |
25.05.2021, 13:10 | #15 |
Участник
|
Цитата:
Сообщение от EVGL
Да, это понятно. Однако клиентские настройки создаются с нуля, и с Contoso имеет совсем мало общего. Стандартный ATL не найдет даже группы номенклатуры (точнее, в особенности группу номенклатуры). А еще есть проблемы локализации. В России все на русском будет, и все стандартные тесты Ивана оказываются применимы только к компании USMF.
В майкрософтовских примерах, кстати, используется перекрытый setup() метод. Это не очень хорошо для производительности. Лучше использовать setupTestCase() в паре с атрибутом SysTestCaseUseSingleInstanceAttribute. Тогда все данные создаются один раз для всех методов класса. По поводу локализации - есть атрибут SysTestCaseCountryRegionDependencyAttribute. Русские названия или нерусские - не должно влиять, если тестируется код, а не названия. |
|
|
За это сообщение автора поблагодарили: Logger (1). |
25.05.2021, 13:24 | #16 |
Участник
|
Цитата:
если в тестируемый код изменяет исходные данные в качестве побочного эффекта... Цитата:
а когда не знаешь, есть ли там побочные эффекты, то изолированность - не такая уж требовательная штука. |
|
25.05.2021, 13:29 | #17 |
Участник
|
Спасибо за ответы. А RSAT используете/планируете использовать?
Цитата:
На последнем обновлении несколько тестов стали падать, потому-что при разноске накладной стал вызываться диалог печати в PDF
А 5-6 человек - это разработчики получающие зарплату на клиентском проекте и вы работаете на клиенте? |
|
25.05.2021, 13:34 | #18 |
Участник
|
Ну, теперь ведь используются SQL SavePoints, которые якобы справляются даже с падением АОСа и неожиданными исключениями? И побочные эффекты исключены?
См. диаграмму здесь, на странице 14. |
|
25.05.2021, 13:46 | #19 |
Участник
|
Цитата:
Сообщение от trud
1) А RSAT используете/планируете использовать? ...
2) Главный вопрос - насколько они оправдывают траты? 3) А те положительные срабатывания что были - вы их анализировали, могли бы они пойматься другими процедурами перед деплоем в прод? (например code review, ручное тестирование и пр.) 4) А 5-6 человек - это разработчики получающие зарплату на клиентском проекте и вы работаете на клиенте? Из опыта, Майкрософт очень советовал одному из наших старых клиентов RSAT, но в итоге не закончилось ничем, потому-что у клиента были жесткие требования по сторонним продуктам из соображений безопасности, и для установки RSAT хотя бы на одном ноутбуке требовалось специальное разрешение. Но там клиент был особый, связанный с банковскими системами Не знаю, может ситуция у них поменялась с тех пор. 2) Очень зависит. По-моему, идеальный сценарий для юнит-тестов - это или ISV решение, или большая доработка с кучей разных сценариев, которая пухнет по мере поступления новых желаний клиента. 3) Могли бы, наверное, если бы разработчик тестировал побочные сценарии, что происходит нечасто, или если бы код ревью делал именно тот, чьи тесты упали. 4) Мы партнеры на клиенте. |
|
25.05.2021, 13:46 | #20 |
Участник
|
они же не сохраняют и не восстанавливают состояние классов в памяти вроде.
|
|
|
|