- 단위 테스트 / 통합 테스트
- 통합 테스트 작성 이유
- controller, repository, service Testcode 작성하면서 생각해보게 된 것들
- 테스트 통과 화면
단위 테스트
- 코드가 제대로 작동하는지 확인하기 위해 애플리케이션의 개별 모듈을 독립적으로 테스트 (종속성과의 상호 작용없이)하는 것
- 모듈은 프로그램 내의 하나의 기능을 담당하는 것으로, 모듈을 테스트한다는 의미는 하나의 기능만이 잘 동작하는지를 확인하는 과정
- 테스트하려는 모듈을 실행하려면 해당 모듈을 실행할 수 있는 환경 구성이 필요 -> 테스트 모듈을 호출하여 실행하는 모듈이 있을 수 있으며, 반대로 테스트하려는 모듈이 다른 모듈을 호출하여 실행하는 경우도 있을 수 있음
- 위의 2가지 경우의 수의 모듈이 모두 존재해야 정확한 테스트가 가능 -> 가상의 모듈을 만들어 사용
통합 테스트
- 모듈 통합 과정에서 모듈 간 호환성의 문제를 찾아내기 위해 수행되는 테스트 -> 모듈 간 인터페이스가 올바르게 작동하는지를 테스트
- 통합 모듈이 올바르게 연계되어서 동작하는지를 테스트하는 것 : 빅뱅 통합 기법, 점진적 통합 기법(상향식, 하향식)
ex.
* 로그인 페이지
- 계정 / 사용자 이름
- 암호
- 로그인 / 로그인 버튼
* 단위 테스트
- 필드 길이 : 사용자 이름 및 암호 필드
- 입력 필드 값 유효성 테스트
- 로그인 버튼 : 두 필드에 유효한 값 (형식 및 세로)을 입력 했을 때 활성화 체크
* 통합 테스트
- 사용자가 유효한 값을 입력하고 로그인 버튼을 누르면 환영 메시지 표시
- 환영 메시지 표시 이후 환영 페이지 또는 홈 페이지로 이동
* 단위/통합 테스트 완료된 후 추가 기능 테스트 위해 고려되는 테스트 케이스 :
- 예상되는 동작이 확인됩니다. 즉, 유효한 사용자 이름과 암호 값을 입력 한 후 로그인 버튼을 클릭하여 로그인 할 수있는 사용자입니다.
- 로그인에 성공하면 환영 메시지가 표시됩니까?
- 잘못된 로그인에 표시되어야하는 오류 메시지가 있습니까?
- 로그인 필드에 저장된 사이트 쿠키가 있습니까?
- 비활성화 된 사용자가 로그인 할 수 있습니까?
- 비밀번호를 잊어 버린 사용자를위한 '비밀번호 찾기'링크가 있습니까?
...
테스트 코드를 공부하면 TDD 라는 말을 가장 먼저 듣게 될 지도 모른다. TDD(Test Driven Development)는 테스트 주도 개발을 를 의미한다.
그런데 이번 프로젝트는 이미 테스트 코드 없이 개발을 1차적으로 마치고 프론트와 맞춰보았다. api 테스트는 ARC를 통하여 작동하는 것을 확인하였다.
이후에 테스트 코드를 공부하게 되면서 단위 테스트도 도전하려고 했지만 쉽지 않았다.
모듈이 독립적이지 않고 연관 관계를 맺고 있거나 종속적인 상태가 되어 테스트 코드를 처음 만드는 나에게 어려운 일이었다.
그래서 통합 테스트로 방향을 틀었다.
연관 관계와 종속을 넘어서 단위 테스트 코드를 짤 수 있다. 처음부터 다시 작성하거나, Mock으로 받아오는 service 나 repository 를 수정 혹은 비슷한 모양으로 새롭게 만드는 것이다.
(ex. BoardServiceImpl -> service 코드를 살리면서 세부 내용을 수정하여 받아온다)
하나로 뭉쳐져 있는 코드를 단위로 테스트 하려고 자르고 붙이면서, 단위라는 것은 그렇게 독립적이고 작은 모양일 때부터 체크해줘야 한다는 것을 경험적으로 느낀 것 같다.
repository -> service -> controller 순서로 테스트 코드를 작성하였다.
처음에는 실제 작동하는 코드와 똑같은 모습으로 통과되면 테스트 코드를 작성했다고 하는 것인가? 라는 생각을 했다.
테스트 코드 작성에 대한 근본적인 질문이 들었던 것 같다. '왜 테스트 코드를 작성할까?', '테스트 코드를 작성해서 무엇을 확인하고 싶은 것일까?'
아무 것도 모른 채 이것저것 테스트 코드라는 모양으로 만들어보려다가 given, when, then 을 보게 되었고
(이것만 보았을 때도 무엇을 given 하고 when은 언제를 말하며 then은 뭘 확인하고자 하는지 파악하기 어려웠던 것이 사실이다)
구글을 계속 헤엄치다가 나의 궁금증을 해결해주는 자료를 찾게 되었다.
다른 사람들과 마찬가지로 테스트 코드를 작성하고 큰 설명 없이 올려놓은 자료였지만, 코드를 보면서 repository와 service, 그리고 controller에서 확인하고 싶어하는 것이 무엇인지 생각하게 된 것 같다.
테스트를 하는 사람에 따라 같은 repository를 통해서도 확인하고자 하는 것은 다를 수 있다. 개발에는 정답이 없다.
나의 경우에는 repository를 통해 account, board, likePost 각 repository에 저장이 되는지, 저장된 자료가 내가 저장하고자 한 자료와 동일한지, 저장된 자료를 불러왔을 때 동일한 값이 나오는지 확인하고자 했다.
이렇게 의도가 분명해지니 given, when, then 이 분명히 나왔고 다른 사람의 코드를 보고도 나에게 맞추어 작성할 수 있었다.
service 에서는 account(회원가입 / 로그인) , board(게시물 조회/등록/수정/삭제), likePost(추가/삭제)에 있는 각 기능들을 확인하고자 했다.
controller 작성이 제일 어려웠는데, controller는 mock을 안 쓸래야 안 쓸 수 없었기 때문이다. (방법이 있는지 모르겠지만 찾아본 레퍼런스에서는 한계였다)
mock을 썼다고 controller는 단위로 테스트 했느냐? 그건 아니다. mock을 만들었으니 주입을 끊어봐야겠다고 어노테이션을 바꾸어 달았지만,
ApplicationContext를 찾지 못했다고 반복해서 이야기하는데 ... 시간은 많지 않고 도무지 모르겠어서 그냥 SpringBootTest를 달아서 세팅을 맞추었다.
controller 에서 확인하고 싶은 것은 repository, service와 달랐다. api가 잘 작동하는지 확인하는 개념이라고 해야할까?
그래서 http status를 확인한다는 생각으로 접근했다. status code는 200으로 잘 왔는지, header에 담겼는지, json 방식으로 잘 갔는지 이러한 것들을 체크했다.
테스트 코드가 재미있었다. magazine 프로젝트를 진행할 때, jwt 부터 접근했다가 모든 기능 테스트를 전체 코드 완성 뒤에 했어서 ... 그 어려움이 역으로 작용했는지 모르겠다.
(게시물을 작성해야 다른 api 들을 테스트 할 수 있음 -> 게시물 작성하는 기능에 토큰이 필요 -> 토큰 생성하고 주고 받는 것에 모든 project의 9할 정도 시간을 쏟았다고 할 수 있다)
그래서인지 테스트 코드는 재미있었다. 테스트 주도 개발에 대해서도 더 공부하고 제대로 해보고 싶다는 생각도 들었다. (물론 시간이 부족한 실전 때는 용기가 나지 않는다 .... ㅜ)
테스트 코드 관련 블로그를 보다가 '초록색을 보면 마음이 편해진다' 라는 말이 기억에 남는다.
