«Самый лучший гуй — одна большая кнопка
в центре экрана с надписью «Сделай мне хорошо!»
(с) Опытный дизайнер

«Самый лучший гуй — одна большая надпись
в центре экрана «Тебе уже хорошо!»
(с) Опытный программист

Цитата #437964
Неудобства: При работе с программой
приходится нажимать на различные кнопки
(с) bash.org.ru

 

В идеале каждая система должна стремиться к минимизации своего интерфейса.

В качестве плохого примера в системе SAP ERP можно вспомнить транзакцию проводки амортизации AFAB:

Первый экран выглядит очень типично для SAP ERP, поэтому и проблемы у этого экрана старые идеологические:

1. Первый экран (экран выбора) не даёт никакой информации о текущем состоянии

2. Все проверки происходят после заполнения всех параметров и запуска процесса

3. Объем задачи большой, заранее не просчитывается, поэтому установлено простое ограничение на тестовый прогон – 1000 записей

4. Формирование фонового задания и отслеживание его статуса – не самая простая пользовательская операция: пять кликов на запуск, пять кликов на просмотр, причём через непростые малознакомые экраны.

5. Нет никакой отчётливой сигнализации об ошибках расчёта

 

Я просто удивляюсь, почему за последние десять лет никто так и не решился переписать междумордие этой важной задачи.

BTW: Вполне вероятно, что в “Пульте управления закрытием” это и сделано, вот только это тема совсем другого разговора.

Приступим?

(далее…)

Теперь во фреме:

Небольшой периодический аудит в системе разработки, как и периодическое медицинское обследование не бывает лишним. Это может понадобиться, если вы:

• входите на проект с существующим большим историческим слоем разработок;
• принимаете большой объём разработок от подрядчика/субподрядчика;
• просто решаетесь на ежегодную генералку или ревизию.

В данной заметке делается обзор в части аудита диапазонов номеров.

(далее…)

Хочу с экзитами закончить и подвести промежуточные итоги в этой части:

• Код теста получается больше продуктивного кода.
• Во многих случаях подходы TDD оправданы и рекомендуются к употреблению.
• Обзор существующего продуктивного кода без тестов вызывает существенное напряжение мозговых извилин.
• Если пытаться покрыть тестами уже написанный код, то часто без рефакторинга не обойтись. А рефакторинг – несколько другая и более сложная задача, чем само покрытие тестами. Рефакторинг можно отложить до момента, когда вы будете делать с кодом что-то ещё.
• Если у вас есть продуктивный код, который не меняется годами, то его покрывать тестами нужно в последнюю очередь.
• Код может быть остаться непокрытым из-за замкнутой петли: Нельзя сделать правильные тесты, потому что сначала надо сделать серьёзный рефакторинг, а делать рефакторинг не рекомендуется пока нет тестов. Разрывайте эти петли, если тесты всё-таки нужны.
• В некоторых случаях выполнить покрытие тестами не получается. Так бывает. Смиритесь.
• По некоторым метрикам подсчета полноты покрытия гораздо проще добиться 100%, чем по другим. Но это не значит, что нужно делать так, как проще.
• Тесты нужны не для того, чтобы добиться 100%, а для того, чтобы они когда-нибудь правильно упали. Потому что уметь правильно падать – это самое главное. Если это верно для каратистов и велосипедистов, значит и для программистов тоже. Лучше правильно упасть плохо крутя педали, чем неправильно упасть хорошо крутя педали.

Считается, что главной метрикой качества тестов является покрытие. В разработческих интернетах часто можно встретить формулировки в стиле “полное покрытие”. Как правило, под полным покрытием понимается некий абсолют в 100.00%.

Процент покрытия – цифра сомнительная, ровно настолько же сомнительная, как и “средняя температура по больнице”. Процент покрытия по проекту – это среднее покрытие его частей. То есть: Модуль-1 имеет покрытие 90%, Модуль-2 имеет покрытие 10%, в среднем покрытие будет равно 50%, если допустить что модули примерно равны по содержимому.

А что значит равны? И что такое 10%?

(далее…)

Продолжаю записывать мысли на тему.

Для работы ABAP Unit неважно:

• сколько у вас тестовых классов вообще;
• как называется тестовый класс;
• в каком месте он расположен;
• как называются его методы.

Главное, чтоб локальный класс:

• был доступен;
• имел кличку “for testing”;
• имел методы с кличками “for testing”.

 

Но, с другой стороны, даже имена переменных-то тоже не являются случайным набором букв.

Следовательно, у нас по каждому пункту должна быть некоторая условная договорённость, облегчающая общее восприятие картины.

(далее…)

Надев защитный шлем, продолжаем разговор без предисловий.

(далее…)