Приближение к рефакторингу

Если вы этого не сделали, прочитайте «Работайте эффективно с устаревшим кодом» Michael Peathers - он имеет дело с именно такой ситуацией, и предлагает множество методов для решения с ним.

Один ключевой момент, который он делает, - это попытаться получить некоторые тесты на месте перед рефакторингом. Поскольку он не подходит для модульных тестов, попробуйте получить несколько сквозных испытаний на месте. Я считаю, что QT имеет собственную структуру тестирования для вождения графического интерфейса, поэтому добавьте тесты, которые манипулируют GUI против известной базы данных и проверяют результат. Когда вы убираете код, вы можете заменить или увеличить сквозные тесты с помощью модульных тестов.

Если вы хотите извлечь все части GUI вашего приложения из всех других частей, чтобы проверить все ваше приложение, вы должны использовать модель-представление: вы можете найти Некоторое объяснение здесь и здесь .

С этой моделью все ваши службы вашего приложения используют докладчики, тогда как только пользователь может напрямую взаимодействовать с видами (деталями GUI). Докладчики управляют взглядами из приложения. У вас будет такая часть GUI, независимая от вашего приложения в том случае, вы хотите изменить Framework GUI. Единственное, что вам придется изменить, являются докладчиками и самими взглядами.

Для тестов, которые вы хотите, вам просто нужно написать модульные тесты для ведущих. Если вы хотите проверить используемые GUI, вам необходимо создать тесты интеграции .

Надеюсь, что поможет!

Идеальное решение будет совместимым в браузере, и это предложение не; Я проверил его только на Ubuntu 9.10, хотя и с хром, Firefox, Epiphany и Opera, и, похоже, надежно работает в тех, что подразумевает надежность в своих коллегах Windows. Очевидно, то есть совершенно другой чайник рыбы.

Это сказано:

Эта идея основана на следующем (X) HTML:

<form>
    <fieldset>
        <button disabled title="this is disabled">disabled button</button>
    </fieldset>    
</form>

и использует следующие CSS для достижения чего-то близкого к вашей цели:

button  {
    position: relative;
}

button:hover:after {
    position: absolute;
    top: 0;
    left: 75%;
    width: 100%;
    content: attr(title);
    background-color: #ffa;
    color: #000;
    line-height: 1.4em;
    border: 1px solid #000;
}

 Кнопка {Position: относительна;  Размеры коробки: пограничная коробка;  } Кнопка: Наведите курсор: после {положение: абсолют;  Вершина: 0;  Слева: 75%;  Ширина: 100%;  Содержание: attr (название);  Фон-цвет: #ffa;  Цвет: # 000;  Высота линии: 1.4em;  Граница: 1PX Solid # 000;  Коробка-тень: 2PX 2PX 10PX # 999;  } 

 <Форма> 
 <кнопка отключено заголовок = "Это отключено"> кнопка отключения    

Это не идеально, но это был лучший без JavaScript Идея, с которой я мог придумать.

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

Рефакторинг - это то, где он действительно ценен, чтобы точно увидеть, где изменился эффект некоторой операции, и где тот же вызов производит другой результат. Это то, о чем все это тестирование: вы хотите посмотреть, сломаете ли вы что-то, вы хотите увидеть все непреднамеренные изменения.

Итак, сделайте тесты теперь для всех частей, которые все еще должны создавать те же результаты после рефакторинга. Испытания не для идеального кода, который останется прежним навсегда, тесты для кода, необходимого для изменения, код, который необходимо изменять, код, который будет повторно. Тесты, чтобы убедиться, что ваш рефакторинг действительно делает то, что вы собираетесь делать.