Оver-engineering - "зачем так сложно?"

[fed]

Цитата:

Сообщение от skuull

Чем мельче и специализированней метод/класс, тем легче его тестировать. Хотя с пониманием как тестировать и как писать код который можно тестировать в АХ тусовке не сложилось

А ты попробуй продать реальному клиенту идею авоматизированного тестирования, покрытия кода тестами и тд и тп. Когда он узнает сколько это будет стоить,сразу
наступит ясность почему именно "не сложилось".
Вообще - автоматизированное тестирование окупает себя только на тиражируемом софте. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.
Только вот я пока не видел вертикальных решений аксаптовских с таким количеством клиентов (гм - может быть у add-ons типа Bartender или Formpipe Lasertnet есть такое количество клиентов). По крайней мере на обычных внедренческих проектах, с разработкой под конкретного клиента, разработка тест-скриптов не окупается.

[Vadik]

Цитата:

Сообщение от fed

.. Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно

Это палка о двух концах. Да, найти незастолбленную нишу на 50+ клиентов - непросто. Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Цитата:

А ты попробуй продать реальному клиенту идею авоматизированного тестирования

Такие идеи как мне кажется надо продавать инвестору, или ОЧЕНЬ "жирному" клиенту. И, да, типичные проектные финтифлюшки покрывать автоматизироавнными тестами пожалуй себе дороже будет

[ax_mct]

Цитата:

Сообщение от Vadik

Но найти и застолбить ее с корявой, нетестируемой и нерасширяемой поделкой - еще тяжелее

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования
количество багов и последующих hotfixes стало меньше? Так сказать экономический эффект интересен.

Мне почему-то не кажется что в AX2012 или Operations стало меньше hotfixes по сравнению с к примеру 3.0. По моему как пользователи работали beta-тестерами так и работают.

Поправьте меня, так как не могу сейчас с цифрами в руках. У меня только субьективное впечатление от то здесь то там прочитанных KB и CU.

[Vadik]

Цитата:

Сообщение от ax_mct

Кто-то может сказать что с внедрением (в той или иной степени) автоматизированного тестирования количество багов и последующих hotfixes стало меньше?

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов. Много это или мало ? Я не знаю, немало это точно, пускай половина и для проектов \ expense management \ GER которые мы пока не сильно (вернее практически никак) не используем. А сколько у Вас хотфиксов доступных, но не установленных - знаете ? У нас - вот столько (снимок с продуктива, там взяли небольшую паузу пока готовились на 1611 перескакивать, вот и поднакопилось). А сколько будет стоить их поставить, возьметесь посчитать? Предвосхищая реплики "да кому они нужны эти ваши хотфиксы" - нужны. У меня в этом году уже двум клиентам в Европе в связи с налоговыми заморочками вынь да выложь надо ставить хотфиксы для 2012 и 2009 которые за собой по древней традиции пол-аксапты тянут. При текущем уровне закастомизированности там одного code merge недели на две, я уж молчу про тестирование. И да - разработку придется остановить или вести параллельно в другом приложении и потом снова мерджить

Цитата:

Так сказать экономический эффект интересен

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы

[macklakov]

Цитата:

Сообщение от Vadik

Ну вот возьмите среднюю ставку по консалтингу и посчитайте во что такие мероприятия выливаются. В D365O если разработка по уму организована - это в большинстве случаев скачать и импортнуть хотфикс, запустить проверку конфликтов (15 минут), запустить билд, сделать check in и можно начинать тестировать. Мелкие хотфиксы можно пучками ставить, просто чтобы глаза в LCS не мозолили

Ок. Может усложнение исходников и оправданно. Если учесть что MS реально со всей дури впрягся за "вылизывание" стандарта, то вроде как традиционная "доработка напильником" на местах уходит в прошлое. Остаются только разработчики "вертикальных" решений. А им может и стоит задумываться над тем, как изолировать свое решение от стандарта.
Но, есть другой немаловажный момент. Данные! Вот уж что порублено на фарш, та это данные. В результате "программизма", размер таблиц стал чудовищным. При этом несмотря на невероятные усилия по оптимизации, включая переписывание кусков на хранимках, все равно есть места где откровенно подтормаживает. Но главное даже не в этом. Главное что данные нечитаемые. А это приводит к жутким проблемам с BI. Жутким проблемам с миграцией. Жутким проблемам с нарушением целостности.
В результате применения таких "правильных и прогрессивных" паттернов и нормализации, AX превратилась в систему, у которой очень большие проблемы с построением отчетности.

[skuull]

Цитата:

Сообщение от fed

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

А можно поподробней про то как получилась эта цифра или она чисто отфонарная ?
Я вообще-то писал про умение не только писать тесты но и код который легко можно покрыть тестами, так вот второе не требует дополнительных затрат и автоматически исключает методы "бога" по 2000 строк как нетестируемые.

[ax_mct]

Цитата:

Сообщение от Vadik

Для 1611 на сегодня - чуть менее 600 X++ хотфиксов.
...
В D365O если разработка по уму организована - это в большинстве случаев..
...
Я это все не к тому сейчас пишу, чтобы все всегда реализовывать максимально трудоемкими "программисткими" способами. Но в некоторых случаях эти усложнения оправданы

Цитата:

Сообщение от skuull

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

То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?

[skuull]

Цитата:

Сообщение от ax_mct

То есть есть мнение что - в некоторых случаях "усложнения" оправданны
так как это может приводить к

- можно заливать хотфиксы без необходимости слияния кода (2012 vs D365O)
- легче покрыть автоматическими тестами

Корректно выдернул из контекста?

Не все так однозначно.
Я сейчас наверно повторю сказанное ранее, но разбиение 1 класса на 3 есть усложнение для тех кто не понимает MVC и облегчение для тех кто понимает. Плюсы тут уже перечислили.
Как по мне, FormLetter стал легче для понимания и использования, а вот Subledger нет.

[belugin]

Цитата:

Сообщение от fed

Вот если у тебя есть эдак клиентов 40-50, вот тогда написание скриптов автоматического тестирования вполне оправдано и экономически выгодно.

Мне кажется, что тут зависит скорее от задачи.
Если есть отдельный кусок, который часто модифицируется, и для которого просто построить тестовое окружение, то его разумно протестировать автоматически.

Если у нас типичные задачи аксаптовского внедрения, состоящие в небольших допилах готовых объектов приложения, на которые нам MS не дал готовых тестах это гипертрудоемко.

Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль

[dech]

Цитата:

Сообщение от belugin

Первый раз я применил автоматическое тестирование для расчета зарплаты под BAAN - мы переходили с BaanBase на Oracle и надо было переоптимизировать расчет зарплаты. (Поиск узкого места, оптимизация, проверка корректности, поиск следующего узкого места и т.д.) То, что я могу запустить тест одной кнопкой вместо лазанья по UI и он мне сам проверит не сломал ли я чего - было большим подспорьем.
Это был одноразовый pinning test.

А еще тесты надо уметь готовить, а то получается дополнительная боль

Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.

[belugin]

Цитата:

Сообщение от dech

Юнит-тесты доступны начиная аж с 4 версии аксапты. Давно пора было их использовать.
Если вы не про Селениум, конечно.

Доступен фреймфорк а не сами готовые микрософтовские тесты.