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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.03.2017, 12:20   #61  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Надо написать такой набор тестов, чтобы написать по ним правильный код было легче чем написать неправильный. Например, проверить каждый параметр по отдельности на явно заданное значение и тот случай, когда они все вместе включены (если они должны быть связаны через && в запросе). Умолчания будут проверяться при проверке отдельных других параметров.
Старый 20.03.2017, 09:42   #62  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
А еще есть книжка Эффекстивная работа с унаследованным кодом там как раз про то, как писать тесты для говнокода.
Хорошая ссылка, спасибо.
Как и все подобные книги, авторы исходят из предположения, что код можно и нужно менять.
Дается обоснование, почему "боязнь изменений" - это плохо
Далее даются советы, как лучше делать эти изменения.

Как я уже говорил в самом начале этой ветки, для dynamics продуктов это предположение неверное.
Большинство приемов связанных с расщеплением, охватом не работают.
(см. приложенные скриншоты)

Так в аксапте нельзя менять сигнатуры методов, которые находятся в sys-слоях. Можно только расширять сигнатуры. Что и делается параметрами по умолчанию. Откуда собственно и появилась ветка.

Причем нельзя менять не только клиентам и партнерам. Нельзя менять и самому майкрософту, чтобы не потерять совместимость кода.

Поэтому для Аксапты нужны адаптированные методы.
Но пока я вижу только советы: тестировать только свои изменения. Критерий - здравый смысл.
Что ж, и такие советы тоже не так уж и плохи. Спасибо.

Ближайший аналог:
разработка с закрытыми dll или com-компонентами.
В свой проект вы можете добавить закрытый код. Но не можете его изменить.
Вы можете создать свой охватывающий объект. Но не можете изменить поведение другого стандартного кода, который использует закрытый код (вернее можете. но выполнив закат солнца вручную)

и скорее нужно искать приемы разработки с подобными закрытыми компонентами.

Создал новую ветку
Как правильно вести разработку в условиях, когда часть кода закрыта от изменения - Sys-слой в аксапте, закрытые codeunit в навике, extensions в MS CRM

Если у кого есть соображения именно по unit-тестированию, велкам в эту ветку, котороая называется:
Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?
Миниатюры
Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 393
Размер:	275.7 Кб
ID:	11285   Нажмите на изображение для увеличения
Название: 2.PNG
Просмотров: 279
Размер:	46.5 Кб
ID:	11286  

Нажмите на изображение для увеличения
Название: 3.PNG
Просмотров: 312
Размер:	44.8 Кб
ID:	11287  
__________________
полезное на axForum, github, vk, coub.
Старый 20.03.2017, 10:50   #63  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Я не очень понял чем это концептуально отличается от тестирования той же функциональности, но выраженной в коде другими средствами?

Можно ввести какой-то свой API в виде отдельных фнукций для удобства (см мое первое сообщение в этом треде).

Цитата:
Ближайший аналог:
разработка с закрытыми dll или com-компонентами.
Почти вся разработка такая - мы не модифицируем код ни винды ни .NET FW
Старый 20.03.2017, 11:03   #64  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
Как и все подобные книги, авторы исходят из предположения, что код можно и нужно менять. Как я уже говорил в самом начале этой ветки, для dynamics продуктов это предположение неверное.
Так в аксапте нельзя менять сигнатуры методов, которые находятся в sys-слоях. Причем нельзя менять не только клиентам и партнерам. Нельзя менять и самому майкрософту, чтобы не потерять совместимость кода.
Стесняюсь спросить, все ли сотрудники Microsoft, причастные к разработке приложения Аксапты, в курсе, что нельзя так делать?
\Classes\RunBase\dialog в AX2009:
X++:
protected Object dialog(DialogRunbase _dialog = null, boolean _forceOnClient  = false)
\Classes\RunBase\dialog в AX2012:
X++:
protected Object dialog()
Удаление параметров метода, пусть и имеющих значения по умолчанию, ведь не считается "расширением"?..
Цитата:
Сообщение от mazzy Посмотреть сообщение
Можно только расширять сигнатуры. Что и делается параметрами по умолчанию.
С т.з. проекта, на котором есть кастомизации, добавление в сигнатуру метода на sys-слое нового параметра со значением по умолчанию точно так же приводит к потере совместимости кода - стандартного с кастомизациями. Потому что раньше в методе, скажем, 3-им по счету шел новый кастомный флажок boolean _skipЧегоНибудь = false, и код был допилен для передачи этого нового флажка. А теперь 3-им по счету идет новый стандартный флажок boolean _updateЧегоТоТам = true, и стандартный код местами явно передает значение этого нового стандартного флажка, и поди потом разберись, где в вызове 3-им параметром передается кастомный флажок, а где - стандартный...

По мне - умерла, так умерла: если надо существенно поменять сигнатуру стандартного метода, то надо это сделать - и по возможности использовать нормально типизированные параметры, а не безликие boolean-флажки, чтобы компилятор заметил несоответствия в вызывающем коде, а еще лучше, по-моему, вместо хрендцати параметров использовать data transfer objects (DTO), в которые можно добавлять новые свойства, не переделывая каждый раз сигнатуру вызываемого метода.

Извините, что не в тему, наболело.

Последний раз редактировалось gl00mie; 20.03.2017 в 11:34. Причина: typo
Старый 20.03.2017, 11:43   #65  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от belugin Посмотреть сообщение
Я не очень понял чем это концептуально отличается от тестирования той же функциональности, но выраженной в коде другими средствами?
здесь пропускаем слово модифицируем ))))

Цитата:
Сообщение от belugin Посмотреть сообщение
Почти вся разработка такая - мы не модифицируем код ни винды ни .NET FW
а здесь пропускаем слово тестируем. ))))

вуаля, ответ готов.
самое интересное, как всегда, не что сказано, а что пропущено. ))))


Цитата:
Сообщение от gl00mie Посмотреть сообщение
Стесняюсь спросить, все ли сотрудники Microsoft, причастные к разработке приложения Аксапты, в курсе, что нельзя так делать?
некоторые прорываются ))))

Цитата:
Сообщение от gl00mie Посмотреть сообщение
раньше в методе, скажем, 3-им по счету шел..
А теперь 3-им по счету идет новый стандартный флажок
убедил.
про майкрософт - согласен.
про "добавление параметров по умолчанию" - по прежнему считаю, что это очень распространенный подход в аксапте

Цитата:
Сообщение от gl00mie Посмотреть сообщение
По мне - умерла, так умерла: если надо существенно поменять сигнатуру стандартного метода, то надо это сделать - и по возможности использовать нормально типизированные параметры, а не безликие boolean-флажки, чтобы компилятор заметил несоответствия в вызывающем коде, а еще лучше, по-моему, вместо хрендцати параметров использовать data transfer objects (DTO), в которые можно добавлять новые свойства, не переделывая каждый раз сигнатуру вызываемого метода.
Да, согласен - лучше быть богатым и здоровым, чем бедным и больным.

А как это эффективно и правильно сделать в существующем инструментарии?
И с существующим унаследованным кодом?

Собственно тема как раз про это )
__________________
полезное на axForum, github, vk, coub.
Старый 20.03.2017, 11:51   #66  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от mazzy Посмотреть сообщение
здесь пропускаем слово модифицируем ))))
Чем отличается тестирование модифицированного кода со значениями по умолчанию от тестирования модифицированного кода другими средствами?

Цитата:
а здесь пропускаем слово тестируем. ))))
Оно в слове "Разработка"
Старый 26.03.2017, 17:02   #67  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Вообще, вопрос, поднятый в теме так и просится разбиения на два:
  1. Как тестировать методы с параметрами по умолчанию.
  2. Как тестировать методы со множеством параметров.
Как раз приведенный пример не в полной мере соответствует заголовку темы. Про тестирование параметров по умолчанию имеет смысл говорить в случаях, когда в логике метода есть разные ветви обработки параметров, полученных по умолчанию и параметров, указанных явно. Например, если есть что-то подобное:
X++:
if (prmIsDefault(...))
{
    ...
}
else
{
    ...
}
В данном методе ничего подобного нет, поэтому задача вырождается ко второму варианту.
А для второго варианта универсального подхода просто может и не быть, все зависит от задачи. Сам по себе факт наличия 11 параметров метода наталкивает на мысль от том, что с методом что-то не так. А если учесть, что в этом же классе есть публичный NEW с количеством параметров, превышающем десяток (по крайней мере в DAX2009 это так), то возникает вопрос все ли в порядке с самим классом.
Например (не претендую на истину в последней инстанции, это только мое личное мнение):
  • Если решили делать рефакторинг, то вообще тест самого метода не нужен - покрываем тестами свои новшества. Правда тут возникает вопрос именно для этого класса - вдруг решили изменить NEW, то каким образом тестировать как это повлияет на весь класс в целом.
  • Если нужно добавить новый параметр (хотя куда уж больше), то тестируем как будет работать метод когда новый параметр передаем, а когда не передаем. Возможно, что после просмотра покрытия, что-то добавим.
  • Если нужна только "зеленая стрелка", то тут уже простор для фантазии огромный.
С чисто технической точки зрения тут можно определить только подход для ответа на вопрос
Цитата:
сколько тестирующих методов должно быть
В параметрах модуля тестирования можно задать как действовать при ошибке утверждений в одном тестирующем метод: продолжать выполнять другие методы или прервать тестирование. Для нескольких утверждений в одном методе, метод прерывается если хотя бы одно из утверждений ложно.
Соответственно:
  • Если считаем, что метод не работает, если хотя бы одно из утверждений не выполняется, тогда все сочетания тестируем в одном методе.
  • Если считаем, что некоторые сочетания параметров редкие и нужно проверять их отдельно, то такие сочетания выделяем в отдельный метод.
Опять же, после анализа покрытия вполне возможно, что подход изменим.
Вообще, unit тесты совсем не про то, что все работает правильно. Они проверяют работает ли метод (класс в целом) так как считает разработчик при проектировании этого метода/класса. Вполне нормальный вариант, что правильность (а не формальность) выносится уже на уровень функциональных тестов.

Последний раз редактировалось Raven Melancholic; 26.03.2017 в 17:11. Причина: Орфографические и грамматические ошибки
Теги
unit test, как правильно, тестирование

 

Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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