Mockito / PowerMockito проверяет возврат

#java #methods #mockito #return #powermockito

#java #методы #mockito #Возврат #powermockito

Вопрос:

В принципе, у меня есть класс, и важная часть выглядит следующим образом:

 class A{
double num = 2;

public double getNum(){
return num;
  }

}
  

Я хочу убедиться, что это не выглядит так:

 class A{

public double getNum(){
return 2;
  }

}
  

Есть ли способ сделать это с помощью Mockito или PowerMockito?

Я новичок в PowerMockito и всего несколько месяцев в Mockito, поэтому извините, если это глупый вопрос.

Комментарии:

1. Зачем вам это проверять? Я считаю, что тесты больше касаются поведения, чем внутренней реализации (ваше поле является закрытым для пакета и не имеет установщика).

2. Да, я использую Mockito немного нетрадиционно. Это для робототехники в старших классах, и мы учим новых учеников управлять роботом. Я не хочу, чтобы они устанавливали мощность двигателя на 0,2; или что-то еще, я хочу, чтобы это была переменная из перечисления, которое мы им дали. Длинная история, я просто хотел знать, могу ли я проверить, является ли это переменной или просто числом. Поскольку мы используем фреймворк, созданный WPILib, это что-то вроде устаревшего кода, поскольку определенные вещи должны выполняться определенным образом. Это упрощенная версия моей проблемы. Тем не менее, спасибо за ответ. Я думал, что это невозможно, но…

3. «Я не хочу, чтобы они устанавливали мощность двигателя на 0,2» — это то, что может охватить тест. Но вам пришлось бы подумать наоборот. Вместо утверждения возвращаемого значения средства получения вам пришлось бы проверить аргумент соответствующего средства установки (например motor.setPower(...) ). В этом случае вы бы тестировали поведение: «не следует устанавливать мощность двигателя на 0,2».

Ответ №1:

 class A{
  private double num;
  
  public constructor(double num){
    this.num = num;
  }

  public double getNum(){
    return num;
  } 
}
  

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

Комментарии:

1. К сожалению, это не так. Я понимаю, что Mockito был разработан для проверки поведения, но я просто надеялся, что я что-то упустил :/. Я пишу эти тесты, чтобы помочь другим ученикам старших классов научиться программировать роботов во время пандемии, поскольку они не могут использовать робота для тестирования. Поскольку жестко кодировать числа — плохая практика, я хотел найти способ проверить, что они использовали переменную. Но число остается тем же, просто у нас есть общедоступное перечисление, в котором мы меняем все числа. Это просто потому, что я хочу, чтобы они изучили хорошую практику до того, как я закончу, и у меня нет времени проверять вручную. Ну что ж. :/

2. У меня также была такая же проблема с тестированием некоторое время назад. Я хотел, чтобы код работал очень строгим образом, который проверяется тестом. Теперь я понимаю, что способ модульного тестирования не такой. Это делается для проверки того, что конкретный метод или функция ведет себя так, как мы ожидаем. Поскольку не имеет значения, каким образом оно получает значение, если оно проходит тест. Способ, которым нам нужно добиться этого, — это использовать набор модульных тестов со всеми возможными сценариями.