Создайте тест JUnit для метода, охватывающего все его вызовы в рабочей области Eclipse.

Question

Предположим, следующий класс Java:

class MyClass {
   public String methodA( String data, String expression ) {
      // expression is evaluated using data
      // ...
      // this leads to a result which is returned
      return result;
   }
}

Обратите внимание, что expression является экземпляром языка выражений (DSL).Таким образом, оценка expression с использованием data зависит от сочетания того и другого.Обычно, expression это фиксированная величина, которая не меняется часто и data может меняться во время всех вызовов.

Ну, через некоторое время обнаружена ошибка в MyClass.methodA(String,String).Ошибка находится в каком-то базовом классе и возникает только при определенной комбинации expression и data.Для этого особого случая легко написать тест JUnit, который можно исправить.

К сожалению, этот метод часто используется во всем проекте.Иерархия вызовов Eclipse определяет более 97 других методов, в которых используется этот метод.Теперь я боюсь регресса, если просто применю исправление.Чтобы чувствовать себя в большей безопасности, я хотел бы провести регрессионное тестирование.

Обычно модульные тесты должны учитывать все важные типы вызовов, особенно пограничные случаи.Но expression Это DSL, который может сильно различаться, поэтому нелегко протестировать все возможные варианты использования.Кроме того, эти тесты не выявят ложное использование, основанное на ошибке.

Поэтому моя идея состоит в том, чтобы действовать следующим образом:

1. Найдите все вызовы этого метода (например, используя «Иерархию вызовов» в Eclipse) и извлеките все значения для expression.

2. Отберите достаточное количество реальных значений для data (например.из базы данных) и перекрестно оценить все выражения с первого шага, используя исходную версию MyClass.methodA(String,String).Спасите тройки (data, expression, result) в файл.

3. Внедрить исправление ошибок.

4. Метод испытания MyClass.methodA(String,String) используя приведенный выше файл, чтобы убедиться, что результаты не изменились.

Следующие вопросы:

Что вы думаете об этом подходе?

Используя иерархию вызовов в Eclipse, я могу только копировать и вставлять в буфер обмена вызывающие методы, но не точный вызов, включая аргументы (см.шаг 1).Мне пришлось бы копировать вызывающий вызов вручную для каждого найденного метода.Как мне удобно извлечь вызовы (во всем рабочем пространстве Eclipse, то есть в нескольких проектах)?

ИМХО, я тестирую только один метод, поэтому тесты охватывают только один модуль.Можно ли использовать JUnit для шага 4 или есть что-то более сложное?

Answer 1

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

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