|
24.08.2015, 14:02 | #1 |
Участник
|
Про подход TDDничего плохого сказать не могу, как и прочие подходы он имеет свою область определения. Но вот автор явно находится под воздействием рекламы отеля Риксос. Много хвалебных слов, но полное отсутствие описание самого объекта.
|
|
24.08.2015, 16:14 | #2 |
Гость
|
Их есть у меня.
http://18delphi.blogspot.ru/
думается автор просто накидывал примеры у себя в блоге и соответственно счел излишним вдаваться в подробности в интервью. + он как правило эмоционален (холерик?) http://18delphi.blogspot.ru/2013/03/blog-post.html Просто некоторые выражения понравились +- типа "Тесты — это «архивированная память», а также «документация» и «варианты использования». " Подход имхо крайне перспективен: если покрыть тестами какую то область то можно с легкостью избежать традиционного шастанья по граблям и прочих приятных мелочей при множественной разработке. Зачастую при поддержке: бага по сути тест рождает дальнейшее тз и прочее. В Ax в силу разных вещей почему то данный подход пока не прижился хотя хз почему. Последний раз редактировалось axm2013; 24.08.2015 в 16:37. |
|
24.08.2015, 16:40 | #3 |
Moderator
|
По одной очень простой причине: При разработке на Аксапте достаточно легко оттестировать разработанную функциональность. И очень нелегко оттестировать все те места в стандарте, которая эта функциональность может сломать. Писать свои собственные тесты для стандартной функциональности - не реально. Написать тесты для своей собственной функциональности можно, но будет ловить 10% ошибок (причем ошибок достаточно банальных - которые и руками не тяжело выловить).
|
|
|
За это сообщение автора поблагодарили: Михаил Андреев (1), AP-1055D (1). |
25.08.2015, 10:40 | #4 |
Гость
|
Цитата:
Я же как средний разработчик наблюдал случаи, когда ломает порой даже не в стандарте а и в разработанной функциональности особенно если разработчиков много. В общем то с "хождением по граблям" сталкивался не сказать что часто но регулярно (с меньшим драматизмом чем у автора но все же). Очень похоже описано у автора статьи: "И я ОЧЕНЬ долго правил код "машины печати". И попадал в "программистские качели". Правишь тут - сломалось там.. правишь там - сломалось тут.. И так - БЕСКОНЕЧНО... Мозги готовы били вскипеть... Хотелось убить кого-нибудь рядом... Функционал - не сходился... А ещё Группа Качества находила одну ошибку за другой.. Группа Качества была как Бич Божий!! Они находили ошибки БЫСТРЕЕ, чем я их исправлял... Всё время находилась 150-я страница документа, или 300-я или 550-я.. Которая не печаталась.. Или на которой приложение тупо падало...." Причем тут еще все хорошо так как он знал что ошибка есть. Цитата:
Цитата:
Цитата:
Сообщение от Morpheus
Часть бизнес логики реализовано на формах или классах вызываемых из форм. Результатом работы кода являются созданные или измененные записи в разных таблицах. Поэтому задача написать и поддерживать актуальными тесты для создания журналов (ГК, склад, заказ на покупку или продажу) и контроля их разоски является не тривиальной.
Узнать что проводки появились к примеру не проблема. Проверить что они правильные по части параметров тоже Покрывать все 100% случае имхо не требуется. Последний раз редактировалось axm2013; 25.08.2015 в 10:46. |
|
25.08.2015, 18:29 | #5 |
Участник
|
Цитата:
Сообщение от axm2013
Ну это у гуру все так легко
Ну и конечно то что некоторые консалты (R.Safianov привет ) не рассматривают все внедрение в совокупности как единый проект, а лишь как набор отдельных проектов по стадиям и соответственно на стадии сопровождения продукта к примеру где тесты начинают играть очень важную роль ничего нет. Ну, раз пошла такая пьянка... Не вижу противоречий и совсем не понимаю, как это относится к восприятию проекта. Вы опять пытаетесь "мягкое" назвать "теплым". Если вы задаетесь целью создать по завершению проекта продукт, который является решением + тест скриптами, то что вам помешает это сделать даже выделив создание тест скриптов в отдельный проект? Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах? Не забывайте, реальная ERP-это давно уже не монолитный продукт, а TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах. |
|
26.08.2015, 11:00 | #6 |
Гость
|
Цитата:
планирование - внедрять не нам, так что о тестах думать не будем. разработка: +- работать не нам + мы еще переделаем то что напланировали до нас собственно запуск и поддержка: уже поздно что то менять + мы тут от случая к случаю. Если что примеры такого знаю от ваших коллег. В итоге при всей необходимости автоматизированных тестов и вообще внимательном отношении к этому (сначала тест потом остальное к примеру) на выходе их не видим. Цитата:
Почему? Как это соотносится с Dynamics Ax? Последний раз редактировалось axm2013; 26.08.2015 в 11:04. |
|
26.08.2015, 11:26 | #7 |
Участник
|
Цитата:
Сообщение от axm2013
Когда проекты разбиты на мелкие составные якобы независимые части то получаем на выходе:
планирование - внедрять не нам, так что о тестах думать не будем. разработка: +- работать не нам + мы еще переделаем то что напланировали до нас собственно запуск и поддержка: уже поздно что то менять + мы тут от случая к случаю. Если что примеры такого знаю от ваших коллег. В итоге при всей необходимости автоматизированных тестов и вообще внимательном отношении к этому (сначала тест потом остальное к примеру) на выходе их не видим. А вы их использовали на практике? Почему? Как это соотносится с Dynamics Ax? 2) Использовал. Я бы не говорил о том, чего не использовал. 3) Потому что есть принцип системотехники: "Сложность системы управления сопоставима со сложностью объекта управления". Создавая систему автоматического тестирования, вы проектируете систему управления для системы управления. Цель которой: Поддержание работоспособности в установленных границах. Если вы проектируете систему управления, которая масштабируемая, легко настраиваемая и т.д., то вы проектируете систему тестирования, которая тоже будет сопоставима по сложности. А при попытке создать универсальную систему сложность вырастет в разы. Если рассматривать DAX, как монолитный единый продукт, то можно использовать. Если рассматривать как комплекс интегрированных средств, то систему автоматизированного тестирования построить будет практически невозможно. Философствовать можно на эту тем сколько угодно. Можно даже почитать про "новые" методологии на хабре http://habrahabr.ru/company/piter/blog/262807/ |
|
|
За это сообщение автора поблагодарили: Kabardian (3). |
24.08.2015, 17:07 | #8 |
Участник
|
Цитата:
Интересно, как в самрой MS проходит процесс тестирования? Как выявляют регрессии? Неужели этот процесс не автомаизирован? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
|
|