Hej,
piszę sobie backend RESTowy do pewnej aplikacji. Żeby uniknąć wrzucania logiki w kontrolerach metody serwisów mają typ zwracany np. ResponseEntity<Something>
w przypadku metod GET, lub ResponseEntity<?>
w przypadku POST, PATCH itd. Zrobiłem to w taki sposób, ponieważ nie chciałem sprawdzać, czy Optional z obiektem jest pusty w kontrolerze, tylko w serwisie.
Fajnie to wygląda, bo dzięki temu metoda dodawania w serwisie wygląda tak:
public ResponseEntity<?> addNewDiskType(DiskType diskType){
Set<ConstraintViolation<DiskType>> validationErrors = validator.validate(diskType);
if(!validationErrors.isEmpty())
return new ResponseEntity<>(HttpStatus.BAD_REQUEST);
if(getDiskTypeByName(diskType.getDiskType()).isPresent())
return new ResponseEntity<>(HttpStatus.CONFLICT);
diskTypeRepository.save(diskType);
return new ResponseEntity<>(HttpStatus.CREATED);
}
natomiast kontroler jest treściwy i schludny:
@PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<?> addDiskType(@RequestBody DiskType diskType){
return diskTypeService.addNewDiskType(diskType);
}
Jednak nauczyłem się przedwczoraj testowania kodu i te testy dziwnie wyglądają. Boję się, że będę miał trudność z wyciąganiem np. ilości obiektów z obiektu ResponseEntity itd. Spójrzcie jak wyglądają moje testy:
assertEquals(HttpStatus.OK,diskTypeService.getResponseWithDisk(1L).getStatusCode());
assertEquals(new ResponseEntity(HttpStatus.NOT_FOUND), diskTypeService.getResponseWithDisk(3L));
assertEquals(new ResponseEntity(HttpStatus.CREATED), diskTypeService.addNewDiskType(testDisk));
assertEquals(new ResponseEntity(HttpStatus.CONFLICT), diskTypeService.addNewDiskType(testDisk2));
assertEquals(new ResponseEntity(HttpStatus.BAD_REQUEST), diskTypeService.addNewDiskType(testDisk3));
Potrzebuje wskazówki, czy wycofywać się z takiego projektowania backendu? Łatwiej mi będzie zrefaktoryzować kod teraz, niż później :) Z góry dzięki za pomoc i pozdrawiam Was w ten piątkowy poranek.