[회고] 220111
테스트를 작성하다가 계속 혼란이 왔던 부분이 있었다. 잘 작성해놓은걸 테스트하는건 로그를 이용해서 하면되는데, 굳이 이렇게 어렵게 작성하는 이유가 있을까..? 하는 의문이었다. 테스트에서 사용되는 서비스나 컨트롤러가 이미 모두 완성되어있고, 그것에 대한 기능을 테스트하는 순서로 진행되었기 때문에 계속적으로 혼란이 왔던 것이었다. TDD는 테스트를 먼저 작성하고, 테스트에 맞게 클래스나 메소드를 완성시키는 방식이다. 따라서, 지금처럼 이미 완성을 다 하고 난 뒤, 잘 동작하는지 테스트하는 것이 아니라 빈 클래스를 이렇게 사용할 것이다~ 하고 가정하고 그 틀을 먼저 마련 한 뒤, 점차 실제 클래스를 채워나가는 방식으로 진행하는 것이다.
이것은 이해가 되었지만, 아직 when에서 서비스를 굳이 사용하는 이유나, Service를 검증하는 이유가 아직은 너무 애매모호하다. 하지만, 개발 전 어떤 틀을 잡아놓고, 그것을 채워나가는 방식은 확실히 안전성이 보장된다는 깨달음은 얻긴했다. 내일은, 빈 메소드에 대한 테스트를 작성해보고, 그것을 테스트에 맞게 채워나가는 식으로 진행해봐야겠다.
[TodayKeywords] 오늘 공부한 키워드
BDD(Behavior Driven Development): TDD에서 파생된 개념으로서, 단위테스트 보단 어떤 행동에 대한 테스트 즉, 시나리오를 이용한 테스트를 의미한다. given->when->then의 순서가 이 개념에서 나온다.-
SSL Handshake과정:- 서비스에서 CA인증기관에 자신의 서비스에 대한 SSL인증서를 요청하여 발급받는다. SSL인증서 안에는 CA정보, 공개키 등이 있다. (서버 -> CA)
- 유저가 브라우저를 이용해 서비스에 접속한다. 이 때, 랜덤데이터와 사용가능한 인증방식을 서버로 전송한다. (유저 -> 서버)
- 서버는 유저가 보낸 인증방식에 해당되는 SSL인증서와 함께 랜덤데이터를 유저에게 전달한다.(서버 -> 유저)
- 유저의 브라우저는 CA리스트를 보고, SSL인증서가 인증된 CA에서 작성된 인증서인지 확인하고, 인증기관에서 미리발급되어 저장된 공개키로 인증서를 복호화한다. (유저 -> CA)
- 복호화된 인증서안에 있는 공개키와 서버로 부터받은 랜덤데이터를 이용하여 임시키를 생성하여 서버에 전달한다.(유저 -> 서버)
- 서버는 전달받은 임시키를 자신이 가지고 있는 비밀키로 복호화하여, 유저를 신뢰하여 대칭키를 만들어 유저에게 보낸다.
- 유저는 전달받은 대칭키를 이용해 이후에 통신을 주고 받는다.
[NextKeyworks] Study Queue
- SOLID
- loop label
- CSV
- 파일입출력
- UML
- UTC
- epoch time / Instant time
- MVC
- URL ClassLoader
- Secure ClassLoader
- JNI
- GC
- HOF
- 자바 해시코드(hashCode)
- OSI 7 계층
- PCB
- 스프링 설계철학
- RESTful
- 준 영속성
- 지연로딩
- 프록시객체
- jpa - mybatis 의 차이
- orm - mapper 의 차이
- 쿠키/세션/로컬 스토리지
- HttpMessageConverter
- 서블릿
- ACID