내가 모르는 내용을 테스트 할 수 있다.
(기능 검증)
내가 모르는 내용을 프로젝트에 바로 적용하면 어떤 문제가 발생할 수 있을까?
1. 테스트가 너무 거대하다.
간단하게 샘플링 할 수 있는 것을 크게 해야한다.
2. 테스트가 거대하면 시간도 오래 걸린다.
서버 올리는데 2~3분이 걸릴수도 있고 10분이 걸릴수도 있다.
3. 눈이 빠진다. (sysout 출력)
4. 연동이 힘들다.
기존에 거대한 프로젝트에 새로운 기능을 연결하는게 힘들다.
해결할 방법은 단 하나
샘플링해서 테스트한다.
디버거 사용.
단위 테스트
내가 알고있는 기능이든 모르는 기능이든, 모든 기능을 테스트화 시킨다.
단위 테스트를 하지 않았을 때 :
잘 돌아가는 프로젝트에 수정을 하나 했다.
서버도 잘 돌아가고 문제가 없었다.
1년에 한 번 때려지는 메서드 하나가 일년만에 때려졌는데 오류가 터졌을 때 잡지 못한다.
하나를 수정하면 언젠가 터지는 시한폭탄을 가지고 있어야 한다.
단위 테스트를 했을 때 :
단위테스트 사용 도구 XUnit -> 자바에서 사용하는게 JUnit
모든 메서드에 대한 테스트 파일이 다 만들어져있으면
junit이 1~2분 안에 다 때려보고 자동 검증해준다. 빠른시간안에!
디버거나 sysout 처럼 눈으로 확인할 필요 없다.
모든게 assert를 사용해 true, false로 검증결과가 나온다.
검증이 완료되면 git에 commit 하면 된다.
junit이 완벽하게 잡을 수 없다.
핫픽스 : 실시간으로 문제가 발생하면 자다가 일어나야한다.
TDD(테스트 주도 개발)와 단위 테스트는 다른 것이다.
좋은 테스트의 특징 FIRST
Fast 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
Independent 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
Repeatable 어느 환경에서도 반복 가능해야 한다.
Self-Validating 테스트는 성공 또는 실패의 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
Timely 테스트는 적지에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.
Logging
DEBUG : 개발시에 필요한 로그
INFO : 정상 로그
WARN : 경고 로그 "혹시 너 잘못될 수도 있어"
ERROR : 에러 로그
[ 레벨 순서 ]
DEBUG < INFO < WARN < ERROR
로그 레벨 : INFO로 설정 시
INFO, WARN, ERROR 로그만 보인다.
보통 배포시에는 INFO 혹은 WARN으로 설정하고,
개발할 때는 DEBUG로 로그 레벨을 설정한다.
그래야 서버쪽에서 서버가 터졌을 때 stack trace처럼 로그가 남는다.
insert, delete, update같이 DB에 변화주는 일을 했을 때는 성공 로그를 남겨주는게 좋다.
그래서 우리는 배포시에 INFO로 로그 레벨을 설정할것이다.
[출처]
https://cafe.naver.com/metacoding
메타 코딩 유튜브
https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9