2015-10-26 7 views
0

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

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

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

Я использую junit 4, mockito, и я не использую TDD. Будет ли TDD помогать мне избежать этой проблемы?

С уважением

+0

Не могли бы вы показать нам код? Кроме того, TDD - это практика, и для того, чтобы привыкнуть, может потребоваться некоторое время. В зависимости от того, на что мы смотрим, трудно сказать, помогло бы вам «избежать» этой проблемы. – Makoto

+0

код пожалуйста? и, удалите вопрос tdd, или ваш вопрос будет закрыт как «слишком широкий», –

ответ

2

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

Итак, первый вопрос, который вы зададите себе, - это, если вам действительно нужны два метода. Это вопрос, на который никто не может ответить без какого-либо кода.

Если вам действительно нужны два метода, то оба являются частью вашего публичного api и должны быть протестированы. Таким образом, вы можете быть уверены, что в вашем сопоставлении параметров нет ошибок (будет смущать, если ваш частный метод работает отлично, но вы не можете дать правильные параметры).

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

public class MyPublicClass { 
    public void method1(Data1 x) { 
     ....call private method 
    } 

    public void method2(Data2 x) { 
     ....call private method 
    } 

    private void methodX(String, int, int, double, String) 
     ...do the work 
    } 
} 

... вы могли бы сделать ...

public class MyPublicClass { 

    private MyNewInterface executor; 

    // probably good idea to make executor final and set it in the constructor 

    public void method1(Data1 x) { 
      executor.method(...); 
    } 

    public void method2(Data2 x) { 
      executor.method(...); 
    } 
} 

Таким образом, вы можете проверить несколько вещей idependently:

  • ли общественные методы дают правильные параметры (с помощью MyNewInterface вашего интерфейса, который вы можете проверить тогда)?
  • Выполняет ли ваш класс реализации правильно (что вам нужно только один раз проверить)?

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

Смежные вопросы