Блог

 Class QueryGenerator
..
  String generateQuery()
  {
   final String jsonString = anotherClass1.method();
   final Map<String, List<POJO> map = someMethod1(jsonString);
   final List<POJO> pojos = someMethod2(map);
   final POJO chosen_pojo = anotherClass2.method();
   final String query = ... //do something to generate the query;
  }
..
  someMethod1() { //do something};
  someMethod2() { //do something};
}
  

Этот класс имеет строку json и извлекает из нее строку запроса. Между ними есть много шагов (десериализация, сохранение в POJO и т. Д.), И каждый шаг обрабатывается другим классом. Все эти классы вызываются из этого метода.

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

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

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