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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.03.2017, 12:20   #61  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,751 / 1849 (69) ++++++++
Регистрация: 16.01.2004
Адрес: Москва
Надо написать такой набор тестов, чтобы написать по ним правильный код было легче чем написать неправильный. Например, проверить каждый параметр по отдельности на явно заданное значение и тот случай, когда они все вместе включены (если они должны быть связаны через && в запросе). Умолчания будут проверяться при проверке отдельных других параметров.
Старый 20.03.2017, 09:42   #62  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,242 / 3058 (142) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
А еще есть книжка Эффекстивная работа с унаследованным кодом там как раз про то, как писать тесты для говнокода.
Хорошая ссылка, спасибо.
Как и все подобные книги, авторы исходят из предположения, что код можно и нужно менять.
Дается обоснование, почему "боязнь изменений" - это плохо
Далее даются советы, как лучше делать эти изменения.

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

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

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

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

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

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

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

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

Нажмите на изображение для увеличения
Название: 3.PNG
Просмотров: 3
Размер:	44.8 Кб
ID:	11287  
__________________
Facebook, mazzy.priot, mazzy.music.
Старый 20.03.2017, 10:50   #63  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,751 / 1849 (69) ++++++++
Регистрация: 16.01.2004
Адрес: Москва
Я не очень понял чем это концептуально отличается от тестирования той же функциональности, но выраженной в коде другими средствами?

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

Цитата:
Ближайший аналог:
разработка с закрытыми dll или com-компонентами.
Почти вся разработка такая - мы не модифицируем код ни винды ни .NET FW
Старый 20.03.2017, 11:03   #64  
gl00mie is offline
gl00mie
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Most Valuable Professional
 
3,458 / 4319 (150) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от 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
Administrator
Аватар для mazzy
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Most Valuable Professional
 
20,242 / 3058 (142) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Цитата:
Сообщение от belugin Посмотреть сообщение
Я не очень понял чем это концептуально отличается от тестирования той же функциональности, но выраженной в коде другими средствами?
здесь пропускаем слово модифицируем ))))

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

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


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

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

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

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

Собственно тема как раз про это )
__________________
Facebook, mazzy.priot, mazzy.music.
Старый 20.03.2017, 11:51   #66  
belugin is offline
belugin
Участник
Аватар для belugin
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
Сотрудники Microsoft Dynamics
 
3,751 / 1849 (69) ++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
здесь пропускаем слово модифицируем ))))
Чем отличается тестирование модифицированного кода со значениями по умолчанию от тестирования модифицированного кода другими средствами?

Цитата:
а здесь пропускаем слово тестируем. ))))
Оно в слове "Разработка"
Теги
unit test, как правильно, тестирование

 

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

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

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

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


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