Loading...

Spring/Tistory / / 2022. 5. 26. 12:12

블로그-V3. JUnit, TDD, Logger

반응형

내가 모르는 내용을 테스트 할 수 있다.

(기능 검증)

 

내가 모르는 내용을 프로젝트에 바로 적용하면 어떤 문제가 발생할 수 있을까?

 

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

 

메타코딩 : 네이버 카페

코린이들의 궁금증

cafe.naver.com

메타 코딩 유튜브

https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9

 

메타코딩

문의사항 : getinthere@naver.com 인스타그램 : https://www.instagram.com/meta4pm 깃헙 : https://github.com/codingspecialist 유료강좌 : https://www.easyupclass.com

www.youtube.com

 
반응형