|
24.08.2015, 11:36 | #1 |
Гость
|
"Новые" методологии
Просто интересная статья и обсуждение по TDD.
http://habrahabr.ru/post/206828/ В принципе, как понимаю, пока слабо распространено на уровне концепции для проектов Dynamics Ax, но все же интересно наравне с Agile-ом в сравнении с традиционным подходом. Последний раз редактировалось axm2013; 24.08.2015 в 11:57. |
|
24.08.2015, 14:02 | #2 |
Участник
|
Про подход TDDничего плохого сказать не могу, как и прочие подходы он имеет свою область определения. Но вот автор явно находится под воздействием рекламы отеля Риксос. Много хвалебных слов, но полное отсутствие описание самого объекта.
|
|
24.08.2015, 16:14 | #3 |
Гость
|
Их есть у меня.
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 | #4 |
Moderator
|
По одной очень простой причине: При разработке на Аксапте достаточно легко оттестировать разработанную функциональность. И очень нелегко оттестировать все те места в стандарте, которая эта функциональность может сломать. Писать свои собственные тесты для стандартной функциональности - не реально. Написать тесты для своей собственной функциональности можно, но будет ловить 10% ошибок (причем ошибок достаточно банальных - которые и руками не тяжело выловить).
|
|
|
За это сообщение автора поблагодарили: Михаил Андреев (1), AP-1055D (1). |
25.08.2015, 10:40 | #5 |
Гость
|
Цитата:
Я же как средний разработчик наблюдал случаи, когда ломает порой даже не в стандарте а и в разработанной функциональности особенно если разработчиков много. В общем то с "хождением по граблям" сталкивался не сказать что часто но регулярно (с меньшим драматизмом чем у автора но все же). Очень похоже описано у автора статьи: "И я ОЧЕНЬ долго правил код "машины печати". И попадал в "программистские качели". Правишь тут - сломалось там.. правишь там - сломалось тут.. И так - БЕСКОНЕЧНО... Мозги готовы били вскипеть... Хотелось убить кого-нибудь рядом... Функционал - не сходился... А ещё Группа Качества находила одну ошибку за другой.. Группа Качества была как Бич Божий!! Они находили ошибки БЫСТРЕЕ, чем я их исправлял... Всё время находилась 150-я страница документа, или 300-я или 550-я.. Которая не печаталась.. Или на которой приложение тупо падало...." Причем тут еще все хорошо так как он знал что ошибка есть. Цитата:
Цитата:
Цитата:
Сообщение от Morpheus
Часть бизнес логики реализовано на формах или классах вызываемых из форм. Результатом работы кода являются созданные или измененные записи в разных таблицах. Поэтому задача написать и поддерживать актуальными тесты для создания журналов (ГК, склад, заказ на покупку или продажу) и контроля их разоски является не тривиальной.
Узнать что проводки появились к примеру не проблема. Проверить что они правильные по части параметров тоже Покрывать все 100% случае имхо не требуется. Последний раз редактировалось axm2013; 25.08.2015 в 10:46. |
|
25.08.2015, 18:29 | #6 |
Участник
|
Цитата:
Сообщение от axm2013
Ну это у гуру все так легко
Ну и конечно то что некоторые консалты (R.Safianov привет ) не рассматривают все внедрение в совокупности как единый проект, а лишь как набор отдельных проектов по стадиям и соответственно на стадии сопровождения продукта к примеру где тесты начинают играть очень важную роль ничего нет. Ну, раз пошла такая пьянка... Не вижу противоречий и совсем не понимаю, как это относится к восприятию проекта. Вы опять пытаетесь "мягкое" назвать "теплым". Если вы задаетесь целью создать по завершению проекта продукт, который является решением + тест скриптами, то что вам помешает это сделать даже выделив создание тест скриптов в отдельный проект? Или вы пытаетесь мне преподать уроки TDD, BDD и их использование в распределенных системах на разных платформах? Не забывайте, реальная ERP-это давно уже не монолитный продукт, а TDD и BDD заточены под монолитные системы и перестают работать в сложных распределенных комплексах. |
|
24.08.2015, 17:07 | #7 |
Участник
|
Цитата:
Интересно, как в самрой MS проходит процесс тестирования? Как выявляют регрессии? Неужели этот процесс не автомаизирован? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
24.08.2015, 17:59 | #8 |
Участник
|
Вроде автоматизирован:
Цитата:
Последний раз редактировалось gl00mie; 24.08.2015 в 18:08. Причина: PS |
|
24.08.2015, 18:03 | #9 |
Участник
|
|
|
25.08.2015, 08:30 | #10 |
Moderator
|
Цитата:
1. Все это написано на зоопарке систем (типа часть тестов иммитирует ручной ввод, часть тестов просто вызывают X++ классы, часть тестов иммитируют HTTP-взаимодействие) и синтегрировано при помощи make, powerscript и какой-то матери. 2. Даже если каким-то образом заинтегрировать по-человечески тесты из пункта 1, не факт что свободная раздача этих тестов партнерам и клиентам сильно поможет. В этом случае разработчику на внедрении придется не только разбираться что и в каких стандартных классах подправить для кастомизации, но и разбираться что и в каких тестах поменять чтобы потом исправленные тесты правильно работали. И потом еще исправленные тесты тестировать и отлаживать То есть - трудозатраты на разработку в этом случае вырастут раза в 2-3. 3. Клиенты не готовы платить за автоматизированное тестирование. В реальности все проекты, которые я видел, обходились достаточно поверхностным тестированием консультантами и прогоном основных бизнес-процессов пользователями во время тренингов перед запусками. Если чего-то ломалось - чинили на ходу. Реально дешевле оплатить 10-15-20 человеко-дней авралов на починку кода и исправление данных, чем просто заплатить не за 6 человеко-месяцев разработки, а за 12-15... |
|
|
За это сообщение автора поблагодарили: macklakov (1), sukhanchik (2), Morpheus (3), gl00mie (2). |
25.08.2015, 09:10 | #11 |
Гость
|
|
|
26.08.2015, 11:52 | #12 |
Участник
|
SysTest + самописный фреймфорк для UI тестирования.
Цитата:
Почему эти инструменты недоступны партнерам и клиентам?
P.S. UI - тесты медленные и хрупкие. Для хороших модульных тестов нужны хорошие модули. |
|
|
За это сообщение автора поблагодарили: R.Safianov (2). |
26.08.2015, 12:17 | #13 |
Участник
|
|
|
04.09.2015, 15:28 | #14 |
Британский учённый
|
Цитата:
Цитата:
Test phase best practices
Unit testing SDEs created new unit tests and modified existing unit tests while developing new features. The source code check-in process required a minimum level for the code coverage of the unit tests that the developer created. For X++ development, these tests were developed by using the SysTest framework in MorphX. For managed code, these tests were developed by using an internal test harness and/or MSTest. Tens of thousands of unit tests were run during Microsoft Dynamics AX 2012 development. The number of lines of code for unit testing was nearly the same as the number of lines of code for the product. A subset of the unit tests was defined as check-in tests (CITs). These tests were run and required to pass as part of the gated check-in system that all SDEs used for any check-in to the source code repository. This prevented major regressions from being introduced into the code base. Function testing The first hands-on use of a feature by the SDETs came as part of the scorecard testing of the testable units. This testing is a lightweight form of acceptance test–driven development (ATDD). SDETs and SDEs work very closely in this phase of the project. Subprocess, process, integration, and user acceptance testing In addition to testing that was focused on features, the SDETs broadened their testing efforts to focus on key interfaces with other areas of the system. As described earlier, end-to-end scenarios were a key part of this testing effort. In addition to the scripted E2E scenarios, the test team coordinated numerous “interactive test sessions” in the later phases of the release. The goal of each session was to bring together SDETs, PMs, and SDEs to focus on a particular business cycle or a particular area of the product. These sessions were critical to driving completeness into the product. To automate or not to automate? Because of the scale of the product and the long-term support requirements for Microsoft Dynamics AX, the development team made a heavy investment in automated regression tests during the Microsoft Dynamics AX 2012 development cycle. The unit tests were one part of this regression suite. Additionally, many functional tests were automated. For these tests, the user interface of the product was the primary interaction point. The automated regression tests for features fell into one of three categories: - Build verification tests (BVTs) – These tests verify the most basic functionality in the product and can be considered “smoke tests.” These tests were run as part of the gated check-in system for every SDE change. Tens of BVT test cases were executed thousands of times during the development cycle. - Build acceptance tests (BATs) – These tests verify core functionality in each functional area of the product. As core features of the product were created, a new test case was created, or an existing test case was modified. These tests were run together with every nightly build. They also were frequently run before an SDE check-in to verify that no functional breaks resulted from the checkin. Hundreds of BAT test cases were executed for each run. - Weekly tests – These tests made up the remainder of the automated test suite. As the name suggests, these tests were run one time per week for much of the release. As Microsoft Dynamics AX 2012 approached its release to customers, the tests were run much more frequently. Tens of thousands of weekly test cases were executed for each run. The team has several milestone and release goals for automation – for example: - A targeted percentage of priority 1 test cases must be automated. - A targeted percentage of all test cases must be automated. - A targeted percentage of code coverage must be met for each area of the system. Another category of regression testing is the verification of bug fixes. The workflow that is associated with a bug can be summarized as follows: 1. The bug can be created by anyone on the team and is mapped to a feature team in the bug tracking tool. The bug is in an Active state. 2. The bug is triaged by a cross-discipline team (PM, SDE, and SDET). The triage result is one of the following: - Fix - Don’t Fix – The bug is put into a Resolved state, and a resolution must be specified. The resolution options include By Design, Duplicate, External, Fixed, Not Repro, Postponed, and Won’t Fix. - Vnext Candidate – The bug is put into a Resolved state, and a resolution must be specified. The options are the same as the options for Don’t Fix. 3. If the triage result is Fix, it is assigned to an SDE, who makes the changes that are required to address the issue. Upon check-in to source code control, the bug is in a Resolved state, and the resolution is Fixed. 4. Regardless of the triage result, all bugs that are in the Resolved state are assigned to an SDET so that the resolution can be reviewed. If the resolution is Fixed, the SDET tests the fix to verify correctness. The SDET also acts as a customer advocate, and provides a “check and balance” in the system for other resolution types. For example, an SDET may “push back” on a bug that has a resolution of Postponed, by providing more details or a stronger argument for the triage team to consider. 5. If the SDET supports the resolution, the SDET puts the bug into a Closed state. The SDET gets input from the original bug author before closing the bug. As part of the closing process, the SDET reviews the existing test case collateral and decides whether test cases must be updated to ensure that the product does not regression in the future. 6. Any bugs that have a resolution of Postponed are reactivated in the next release.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще. |
|
04.09.2015, 17:34 | #15 |
Гость
|
Просматривая документ обратил внимание на книжку
How We Test Software at Microsoft и методом поиска обнаружил что есть аналог, человек который уже свалил из Гугл в Микрософт http://habrahabr.ru/post/210634/ и даже выпустил книжку с похожим названием "How Google Tests Software" переведенную на русский "Как тестируют в Google" (которую можно даже поискать, например вместе с coollib) Имхо занимательно. PSИ чтобы два раза не ходить по Agile http://msk15.agiledays.ru/ Тыкнув на понравившийся доклад в расписании можно просмотреть видео И чуть позже будет http://msk16.agiledays.ru/ Последний раз редактировалось axm2013; 04.09.2015 в 17:49. |
|
24.08.2015, 22:41 | #16 |
Участник
|
Соглашусь с fed. По сути - это просто дорого получается, заказчик не готов, как правило, за это платить.
__________________
Ivanhoe as is.. |
|
25.08.2015, 11:12 | #17 |
Участник
|
Дали мне как-то фичу довести до ума, которую написал за несколько месяцев до этого фрилансер. Фичу эту никто не использовал, т.к. она просто не работала, и нужно было это дело исправить.
Сначала я было разгреб эти конюшни вручную, но когда это стало подавать признаки жизни, посыпались новые требования и сценарии использования. Вот тогда-то я и понял, что если вот прямо сейчас не написать юнит-тест или что-то такое, то через месяц-другой будет очень скучно тестировать одно и то же. В итоге получился большой класс, в котором было штук пятнадцать методов, по одному на каждый сценарий. Класс мог исполняться только на моей машине, поскольку там были специально для теста созданы данные -- Майкрософт зажимает классы, которые создают данные специально для юнит-тестов, а писать такие методы самому было как-то поморочено, а местами, где логика зашита в формы, даже очень поморочено. Без этого класса, меня свезли бы в дурку в конце концов, потому-что проверять руками все предыдущие сценарии после каждой новой доработки не было ни желания, ни времени. Очень рекомендую написать такой класс при малейших намеках на регулярные новые требования для одной и той же фичи. |
|
25.08.2015, 11:17 | #18 |
Участник
|
axm2013 с вами тяжело вести диалог, вы все к своему сводите. Коллеги с вами поделились мнениями, мнения плюс минус одинаковые, почему вы считаете, что вы правы, а оппоненты нет?
Чтобы понимать контекст, сколько проектов вы сделали?
__________________
Ivanhoe as is.. |
|
25.08.2015, 11:37 | #19 |
Гость
|
Возможно.
Работаю над тем чтобы было легче, если видите какие то спорные моменты буду рад если укажите проблемы. Цитата:
А вы? И сколько раз вы лично использовали Unit test framework? Почему? |
|
25.08.2015, 11:43 | #20 |
Участник
|
целая коллекция методологий, познавательно
Fear Driven Development Hope Driven Development Debt-Driven Development Ping Pong Development http://blogerator.ru/page/bagopedija...rammista-sleng |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|