- 예외처리 같은 것들은 단위 테스트로 검증을 하는 것이 좋다
- 응답 상태만으로도 테스트 격리가 가능
- return 할 때 (혹은 매개변수로 보낼 때) 제네릭처럼 사용하는 거인듯? 확인 필요
- 도메인 모델 구현보다는 TDD와 ATDD 에 익숙해지는 것에 집중할 것
- DB도 붙여야 하고 웹요청도 받아야 하는데 TDD를 어떻게 하나?
-
Inside out: 도메인 지식이 먼저 선행 되었을 때 수월
-
Outside in: 모킹이나 스터빙을 하여 세부사항을 나중에 연기함. 도메인 지식이 부족해도 괜찮음.
- outside in 을 지지하는 TDD 파를 Mockist 라고 부르는데 행위 검증을 좋아함
-
내가 요구사항의 도메인 지식을 알고 있다면 Inside out 방식으로
-
도메인 지식이 부족하다면 Outside in 방식으로
-
스턴트 더블이라는 말에서 옴
-
메소드가 호출되었다는 것을 검증 -> 행위 검증: mock
-
return 값이 나오는 것을 검증 -> 상태 검증: stub
- 상태 검증
- 테스트 더블 객체라는 스파이가 있다. 특정 메소드의 응답만 받고 싶을 때 spy 를 사용
- 행위 검증에서 사용
-
실제 객체가 아닌 다른 객체지만 테스트를 위해서만 사용
-
5개의 메소드를 가지고 있는 인터페이스가 있다고 했을 때 메소드 5개를 다 구현해서 만든다고 하면 fake 를 사용
-
메소드를 구현하지 않는다면 stub 만으로도 충분 i.e. JPA 리포지토리를 하나의 메소드만 사용한다면 stub, 전부 메소드를 구현한다면 fake
- given method 는 bdd 스타일.
- jgrapht 와 같은 라이브러리를 사용할 때는 해당 서드파티 라이브러리의 코드를 수정할 수도 없고 자신이 제어할 수도 없기 때문에 단위 테스트가 필요가 없으며 이 서드파티 라이브러리를 사용하고 결합한 method 들을 테스트하는 통합테스트를 진행하면 된다.
- 모든 빈을 가져오지 않고 일부분만 가져올 수 있다. 인자에 class 타입을 넣어주면 되는 듯
-
컨트롤러에서 슬라이스 테스트를 할 때 사용
-
2주차에서는 컨트롤러 단위 테스트를 하지 않고 인수 테스트만 수행한다
-
테스트 코드 작성 시에 생성자에 필요한 의존성을 넣어줄 수 있음
-
또한 setter 로 DI를 해주는 것은 set 을 까먹는 경우에 NPE 가 발생할 수도 있지만, 컴파일 단계에서 에러도 잡아낼 수 있음
-
하지만 의존관계를 가지는 bean 이 많을 때에는 생성자에 매개변수를 많이 넣어줄 수 있으니까 setter 를 쓰는 것이 좋다.
- request 와 response 에 대한 내용이 콘솔에 찍힌다. header 와 content-type 이 찍혀서 api 제작에 좋다
- requestDTO, responseDTO
- Outside in 방식으로 TDD 를 하는 것이 수월
- Acceptance test 생성 후 Acceptance test를 성공하기 위한 controller 를 만들고, controller 를 만들다보면 service 도 만들게 되고 그러다보면 DAO도 만들고 도메인 모델도 만들고 그 도메인 모델에서 단위테스트를 생성해주는 방식으로 해보자.
- 인수테스트 생성 -> 인수테스트 실패 -> 인수테스트를 성공할 수 있는 mock 서버 생성(도메인 정보가 전혀 없는 값을 주는 서버임) -> mock 서버가 인수테스트를 통과하면 그 이후부터는 컨트롤러 단위 테스트를 만든다 -> 컨트롤러 단위 테스트가 실패하면 그 이후 컨트롤러 구현. 이런 방식으로
- DTO 사용에서는 .를 연달아 사용해서 가져다 쓰는 것도 괜찮다.