210311_TIL

* 어제의 다짐

- 테스트 마저 완성하기

=> 테스트가 깨지는 문제가 심각하여 고치느라 하루의 대부분을 소요

 

- Effective 자바 1장 블로그 마저 올리기

- crsf, frameOption 방지법에 대해 살펴보기

- @Component와 @Configuration 차이 정리

=> 테스트를 하면서 제대로 확인하지 못함, 다음날 할 예정

*오늘 한 일

- 암호화를 한 프로젝트를 기반으로 테스트를 작성하였다. 테스트에 추가되야 하는 가장 큰 특징은 토큰 검사에 대한 부분이었다. 토큰을 검사하는 서비스 레이어에서 제대로 변환이 되지 않아서 굉장히 시간이 많아 소요되었다. 또한 UTF-8로 설정하는 것을 filter에 연결해서 하였는데, 새로 사용하는 filter와 충돌해서 그런지 제대로 사용할 수가 없어서 힘들었다.

 

- 토큰 해석을 Dto를 반환하던 구조에서 String을 반환하도록 전환하였다. 테스트 시, parseToken은 Filter에서 결과를 항상 null로 내었다. 나의 테스트코드 작성 능력이 부족한 것이 1차 원인이라고 생각하는데, 이것이 해결되지 않아 단순한 String으로 변형하였다. Service에서는 모두 Dto를 사용하고 싶었는데, 어떻게 이것을 생각해야 할까?

 

- 클린코드 5장의 형식맞추기를 읽고 일부 테스트를 수정하였다. 특히, static 변수명을 먼저, private 인스턴스변수를 쓰며, 생성자를 쓰는 순서를 기억하였다. 또한 의미가 비슷한것끼리 새로로 묶으며, 변수는 실제로 선언되는 위치에 최대한 가깝게 배치하도록 변경하였다.

 

- 전체 주석에 사용하는 용어의 통일성을 맞췄다. "수정 할", "수정하고자 하는" 이 2개는 같은 의도를 나타내지만, 엄밀하게 말하면 사용 방식이 통일되지는 않았다. 따라서 대부분의 매개변수에 대한 설명문을 ""OO 하고자 하는" 형식으로 통일을 맞췄다.

 

- Controller 테스트의 반환을 테스트하기 위해서 containsString을 사용할 때, 변수가 아닌 값에 대한 부분은 문자열에서 분리하여  "\"id\":" + resultProductTwo.getId() 이런식으로 대입하도록 바꾸었다. 테스트가 깨질 때 좀 더 확실하게 알아볼 수 있도록 하였다. 

 

 

*내일 할 일

- 피드백에 따라 수정하기

- Effective Java 1장 모두 블로그에 올리기

- Clean Code 5장, 자바 가이드라인을 통해 전반적으로 형식 수정하기

- @Component와 @Configuration 차이 정리