AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.03.2017, 10:39   #21  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
ну по сути это минимальный набор который покажет - не поломался ли метод.
т.е. тестируем только регрессию?
а почему "это минимальный набор, который покажет"?
почему он покажет? ведь может быть регрессия, которая не учитывается этими двумя случаями.

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

и что за случайные выборки?
да, в ax7 добавили sysTestAnyGenerator... но мы ведь не о нем говорим?
что за случайности в unit-тестировании? чего я не понимаю?
__________________
полезное на axForum, github, vk, coub.
Старый 14.03.2017, 11:00   #22  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,039 / 1630 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
и что за случайные выборки?
да, в ax7 добавили sysTestAnyGenerator... но мы ведь не о нем говорим?
что за случайности в unit-тестировании? чего я не понимаю?
ну предположим у вас поломали метод - перестали обрабатывать _agreementHeaderExtRecId внутри. но собственно данные выбираются так, что строка у которой agreementHeader = agreementHeaderExtRecId выбирается первой и возвращается вам. получится что как бы тест работает правильно, но при наличии других данных в таблице будет неправильная работа.

вообще немного подумав - что бы я как разработчик решения хотел бы получить от микрософт. наверное все же не 2, а набор тестов которые тестируют каждый параметр и проверяют что одно изменение параметра приводит к отличию в выполнении.
т.е. в данном случае 11 параметров, на каждый параметр по 2 значения
получается тест с 22 вариантами - на каждый вариант должна быть своя цена. плюс скрипт который генерит 22 разных записи в таблице цен
так бы я проверил, что мой код не поломал стандарт

Последний раз редактировалось trud; 14.03.2017 в 11:03.
Старый 14.03.2017, 11:20   #23  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
А не побухтеть ли нам, уважаемые кроты?

Предположим, есть метод с кучей параметров по умолчанию. (см. скриншот)

Как бы вы написали такой unit test?
Рефакторить, если нельзя рефакторить, оборачивать хелперами.

X++:
void testFindDisc_byRelationAgreementHeader_ifAgreementHaderDoesNotMatch_returnsNothing()
{
      ...
      this.assertFalse(this.findByAgreementHeader(relation, dimId, NotExistringAGreementHHeader));
}
Цитата:
Какую стратегию вы считаете правильной для тестирования методов с параметрами по умолчанию? Почему?
Какие статьи/книги/ссылки вы считаете релевантными по данной теме? Почему?
http://xunitpatterns.com/
Старый 14.03.2017, 11:45   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
прекрасно!
спасибо за ссылку и за книгу.

и все же. а можно поконкретнее?
Миниатюры
Нажмите на изображение для увеличения
Название: xUnit.jpg
Просмотров: 170
Размер:	301.5 Кб
ID:	11262  
__________________
полезное на axForum, github, vk, coub.
Старый 14.03.2017, 13:01   #25  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
1. В общем то, как написал fed - unit test-ирование полезно, когда значительная (по моим оценкам не менее 40% кода) часть кода покрыта unit тестами. Если тесты на стандартный код не появились - это все, вроде как, имеет мало смысла.

2. Что гораздо хуже, большая часть Ax кода написана так, что на нее невозможно написать unit тесты. Чтобы код было удобно тестировать, все с чем он работает тем или иным образом должно передаваться в класс (или метод) - см. прием/паттерн Dependency Injection. В Ax этот принцип нарушается везде

Скажем любой метод, который обращается к БД нормально протестировать нельзя, так как я не могу создать mock для базы данных и передать его в этот метод. Каждый такой метод работает против реальной БД и подменить ее (не трогая стандартный код) я в принципе не могу.
Старый 14.03.2017, 13:13   #26  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре Посмотреть сообщение
Если тесты на стандартный код не появились
появились/не появились - отдельный вопрос.
можно утверждать, что "не публикуются".

Цитата:
Сообщение от Андре Посмотреть сообщение
Что гораздо хуже, большая часть Ax кода написана так, что на нее невозможно написать unit тесты. ...mock для базы данных и передать его в этот метод
ну... не то, чтобы невозможно.
большая часть тестов работает на демонстрационной базе, которая очень стабильна.
любые другие данные нужно догенерировать.

т.е. mock база есть. и она не пустая.

я так понимаю, что в мс есть специальные атрибуты, которые заставляют тестовую среду перед запуском тестов установить демобазу, компанию и страну.
Миниатюры
Нажмите на изображение для увеличения
Название: ax7.PNG
Просмотров: 160
Размер:	54.9 Кб
ID:	11264  
__________________
полезное на axForum, github, vk, coub.
Старый 14.03.2017, 13:16   #27  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
которые заставляют тестовую среду перед запуском тестов установить демобазу, компанию и страну
Тогда это интеграционные тесты, а не unit тестирование.

Но проблема же не только в БД. Может с тех пор как я смотрел в Ax что-то изменилось, но создание объектов в конструкторе объекта, как и в его методах раньше встречалось повсеместно и было правилом, а не исключением.
Старый 14.03.2017, 13:21   #28  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре Посмотреть сообщение
Но проблема же не только в БД. ...создание объектов в конструкторе объекта, как и в его методах раньше встречалось повсеместно и было правилом, а не исключением.
да, и сейчас повсеместно.
да, и сейчас добавляются параметры со значениями по умолчанию.
да, и сейчас возможность рефакторинга очень и очень ограничена. даже в мс.
и прочие отличия аксапты от того же c#, java, php.

собственно, поэтому и вопрос этой темы:
Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?

в принципе с удовольствием послушаю что думают опытные товарисчи на более общую тему:
Как правильно выполнять unit-тестирования в аксапте на ваш взгляд?
__________________
полезное на axForum, github, vk, coub.
Старый 14.03.2017, 13:26   #29  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
поэтому ожидаю, что высказывающиеся расскажут не только о приемах правильного unit-тестирования, но и о том какие цели удовлетворяются при том или ином приеме
Вообще, целью unit тестирования для меня является минимальная гарантия того, что я смогу сегодня ночью спокойно спать и меня не разбудят со словами, что что-то отвалилось.

С этой же задачей хорошо справляется строгая статическая типизация, которую по эффективности я бы поставил даже на первое место. Именно она - та причина, по которой в production я предпочту использовать f# или haskell, а не clojure. Именно она является причиной того, что я буду пропагандировать TypeScript и настаивать на его использовании вместо JS.

Если твои цели совпадают с моими, может просто рассмотреть другие способы проверки работатоспособности продукта, нежели unit тесты, которые не очень вписываются в концепцию продукта ?

Последний раз редактировалось Андре; 14.03.2017 в 13:28.
Старый 14.03.2017, 13:38   #30  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре Посмотреть сообщение
Вообще, целью unit тестирования для меня является минимальная гарантия того, что я смогу сегодня ночью спокойно спать и меня не разбудят со словами, что что-то отвалилось.
другими словами, контроль регрессии.
пусть так.

какая стратегия в имеющихся условиях в имеющейся аксапте с имеющимся инструментом SysTest* является правильной? И почему?

для определенности, давай сосредоточимся на методах с параметрами по умолчанию на примере PriceDisc::findDisc )))

Цитата:
Сообщение от Андре Посмотреть сообщение
Если твои цели совпадают с моими, может просто рассмотреть другие способы проверки работатоспособности продукта, нежели unit тесты, которые не очень вписываются в концепцию продукта ?
Да, это один из вариантов развития.

но что хотелось бы:
1. прикидываем правильную стратегию контроля регрессии для аксапты и для того, что в ней называется юнит-тестированием
2. прикидываем правильную стратегию контроля регрессии для другого способа.
3. сравниваем трудоемкость
4. ...
5. PROFIT

но для этого нужно хотя бы как-то определится с правильной стратегией и понять какой ценой эта правильность обеспечивается в Аксапте.
__________________
полезное на axForum, github, vk, coub.
Старый 14.03.2017, 13:42   #31  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
другими словами, контроль регрессии.
пусть так.

какая стратегия в имеющихся условиях в имеющейся аксапте с имеющимся инструментом SysTest* является правильной? И почему?
Ну, я свое мнение озвучил Написание unit test-а в Ax не прибавляет мне никакой уверенности в том, что последние изменения в коде ничего не поломали. А значит (с моей точки зрения) являются тратой времени.

Может у кого-то был противоположный опыт ?
Старый 14.03.2017, 14:00   #32  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,039 / 1630 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Андре Посмотреть сообщение
Написание unit test-а в Ax не прибавляет мне никакой уверенности в том, что последние изменения в коде ничего не поломали.
ну вот я полностью согласен. т.е. по хорошему тестировать надо не методы, а процессы - т.е. в нашем случае - при создании строки заказа подставилась правильная цена.
в ах7 есть определенные шаги в этом направлении - создали форм адаптеры - классы для форм которые один в один отражаются на контролы формы.
но я вот не очень честно говоря представляю как вообще должен выглядеть тест на создание и разноску заказа, что проверять, каким образом генерить данные и т.д.
Старый 14.03.2017, 14:08   #33  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
но я вот не очень честно говоря представляю как вообще должен выглядеть тест на создание и разноску заказа, что проверять, каким образом генерить данные и т.д.
Теоритически есть продукты, которые автоматически щелкают по полям форм: заполняют данные, разносят заказ и потом считывают из полей полученный результат. Если уже есть база данных для тестирования - можно посмотреть в эту сторону.

Я так не делал - слишком ленив Во первых надо тратить кучу времени на поддержку всех тестов в актуальном состоянии. Во вторых БД должна содержать набор данных для покрытия всех основных сценариев, а значит надо следить и за ее актуальностью.

Когда я работал с Ax, я пошел чуть-чуть другим путем, который можно описать примерно так: "Если мы не можем снизить вероятность возникновения ошибки, попробуем сделать так, чтобы ее цена была как можно ниже". Я понимаю, что это "рабоче-крестьянский подход", но при правке функционала в корректность которого у меня были значительные сомнения (как и сомнения в качестве тестирования), я не выбрасывал из приложения старый вариант кода, а вешал его на галочку. По умолчанию галочка не стоит и работает новый вариант. Если пользователи пишут, что появились проблемы с новым кодом, я предлагаю им поставить галочку, чтобы работать начал предыдуший вариант, а сам спокойно решаю проблемы в новом варианте.

Еще раз - такой способ подойдет не всем и не всегда
Старый 14.03.2017, 14:23   #34  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,039 / 1630 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Андре Посмотреть сообщение
Теоритически есть продукты, которые автоматически щелкают по полям форм: заполняют данные, разносят заказ и потом считывают из полей полученный результат.
В D365 и продукты не нужны, такое уже показывают из коробки, т.е. путем прощелкивания создается таск гайд из него автоматом генерится код, который делает то же самое. сам не делал, но презентацию видел
непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты
Старый 14.03.2017, 14:50   #35  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,932 / 3227 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от trud Посмотреть сообщение
непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты
Написать метод проверяльщик.
Или может та система которую там демили уже так умеет ?
Проблему с датой не вижу. Ее тоже можно выставить, даже из интерфейса.
Или тогда надо ее как параметр вводить в метод проверки.
За это сообщение автора поблагодарили: mazzy (2).
Старый 14.03.2017, 14:51   #36  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты
насколько я понимаю, проверку сводят к тому же инструменту SysTesCase.
атрибутами устанавливают область FunctionTest.
такие классы проверяются в рамках отдельного шага после успешного прохождения CheckInTest...
есть и UnitTest, есть и IntegrationTest, есть еще несколько типов, которые влияют на checkin, последовательность, периодичность, критичность проверки.

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

Отсюда собственно и тема этой ветки )))
Миниатюры
Нажмите на изображение для увеличения
Название: ax7.PNG
Просмотров: 364
Размер:	96.0 Кб
ID:	11265  
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: trud (2).
Старый 14.03.2017, 15:07   #37  
ALES is offline
ALES
Участник
Злыдни
 
220 / 45 (2) +++
Регистрация: 11.08.2004
Цитата:
Сообщение от trud Посмотреть сообщение
непонятно что собственно делать дальше, т.е. как проверить к примеру "правильность" разноски. учитывая что часть данных вообще зависит от системной даты
Денис, ты не можешь не знать решения, где сразу непосредственно "правильная" разноска в БД записывается
Старый 14.03.2017, 15:57   #38  
ALES is offline
ALES
Участник
Злыдни
 
220 / 45 (2) +++
Регистрация: 11.08.2004
Цитата:
Сообщение от mazzy Посмотреть сообщение
..но в конечном итоге все равно нужно написать некий класс..
А смысл? Даже если отбросить "дефолтный" параметр с recid=0 и т.д., "механически верный" поиск по inventDimId предполагает обширные "тайные знания" по применяемым "схемам" учета, логике формирования строк в соотв. таблицах, кастомизациям всего этого "вокруг".. В общем виде от написанного класса получаем подтверждение "найдем строку скидки если код аналитики есть в поле таблички" вместо условно ожидаемого "найдем скидку, как для холодильника зеленого цвета так и для трех вагонов песка, а для восьми вагонов она еще больше" . Еще раз, Сергей, что ты хочешь от юнит теста этого метода? "return "зеленый квадратик"" или что-то другое?
Старый 14.03.2017, 16:31   #39  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,039 / 1630 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
А вот на скриншоте макрос #voucher чему равен? т.е. предполагается что в результате теста один и тот же ваучер получается?
Старый 14.03.2017, 16:51   #40  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ALES Посмотреть сообщение
А смысл? Даже если отбросить "дефолтный" параметр с recid=0 и т.д., "механически верный" поиск по inventDimId предполагает обширные "тайные знания" по применяемым "схемам" учета, логике формирования строк в соотв. таблицах, кастомизациям всего этого "вокруг"..
вообще говоря, unit-тестирование предполагает, что все запуски выполняются в одном и том же окружении. поэтому при правильном подходе "вокруг" ничего меняться не должно.

Цитата:
Сообщение от ALES Посмотреть сообщение
Еще раз, Сергей, что ты хочешь от юнит теста этого метода? "return "зеленый квадратик"" или что-то другое?
как всегда, захватить мир
понять. и простить. )))

если так проще для рассуждений, то наличие unit-теста является обязательным при checkin'е кода в мс.
поэтому формально - именно "зеленый квадратик".

но я смотрю на уже существующие тесты. там чего только нет.
помню себя и как я сам надеялся "вот у вендора то"... )))

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

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

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

Цитата:
Сообщение от trud Посмотреть сообщение
А вот на скриншоте макрос #voucher чему равен? т.е. предполагается что в результате теста один и тот же ваучер получается?
да. нумераторы тоже настраиваются в рамках setup-метода. каждый запуск test-метода происходит в одинаковом окружении.
__________________
полезное на axForum, github, vk, coub.
Теги
unit test, как правильно, тестирование

 


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

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

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