Gradle Test task 로깅 설정하기

TDD의 맹신자는 아니지만 보통 개발을 진행할 때 테스트 케이스를 먼저 만들면서 코딩하느라 디버깅을 테스트 케이스로 많이 하는 편인데 Gradle test 태스크는 기본적으로 console 로깅이 disable된 채로 구동된다.

개발시에는 stacktrace를 상세하게 볼 필요도 있는데 아래 설정을 통해 볼 수 있다.

Gradle reference는 잘되어 있는 듯 잘 안되어 있는(?) 뭔가 하나씩 빠져 있는 느낌이랄까..

기본값이 어떤값으로 되어 있다던지 어떤 값이 적절하게 들어가는지 상세하게 안나와 있는 경우가 좀 있는 편인거 같다.

Test task 로깅 설정

test {
    testLogging {
        // test jvm의 standard out and standard error을 console에 출력한다.
        showStandardStreams = true
        showCauses = true
        showExceptions = true
        showStackTraces = true
        exceptionFormat = 'full'
    }
}

참고 TestLogging Property

Property Description
displayGranularity 로그로 기록되는 이벤트의 표시 단위.
"0"으로 세팅할 때 메소드 단위 이벤트는 "Test Run > Test Worker x > org.SomeClass > org.someMethod"로 표시된다.
"2"로 세팅하면 같은 이벤트는 "org.someClass > org.someMethod"로 표시된다.
events 로깅될 이벤트.
TestLogEvent (FAILED, PASSED, SKIPPED, STANDARD_ERROR, STANDARD_OUT, STARTED)
exceptionFormat showStackTrace가 true 여야만 활성화
로깅하려는 test exception 포맷
TestExceptionFormat(FULL, SHORT)
maxGranularity 로깅되는 이벤트 표시방식(max)
"0" test를 수행하는 gradle test suite 전체
"1" test가 수행되는 각 test JVM 정보
"2" 테스트 클래스
"3" 테스트 메소드.
minGranularity maxGranularity 와 동일
showCauses showException가 true여야만 활성화
테스트 수행 시 exception이 발생 했을 때 causes 정보를 보여준다.
showExceptions 테스트 수행 시 exception이 발생 했을 때 exception정보를 로깅한다. 보통 "Failed" 이벤트 발생 시 수행한다.
showStackTraces 테스트 수행 시 exception이 발생 했을 때 showStackTraces정보를 보여준다.
showStandardStreams standard out, standard error 를 로깅한다.
stackTraceFilters test stack trace 정보를 filter를 통해 정제한다.
TestStackTraceFilter를 사용

Reference

https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.logging.TestLogging.html

Read more

나의 프로그래밍 폰트 사용 일대기

나의 프로그래밍 폰트 사용 일대기

시작은 2003년 이제 막 프로그래머로써 첫발을 내딛을 때부터 나는 프로그래밍 폰트에 대해서 관심이 많은 편이었다. 화면 붙잡고 매일 글자들과 씨름하는 직업이다보니 당연하게도 좀더 눈에 잘 보이고, 보기에 좀더 미려하고 조화스러운 폰트를 찾는 것이 어찌보면 약간 본능(?)적으로 관심을 가졌던게 아닌가 싶기도 하고 말이다. 최근까지도 이 주체할 수 없는 본능에 따라

By Kevin H. Kwon
Istio 를 통한 path(url) 기반 Local Rate Limit 적용

Istio 를 통한 path(url) 기반 Local Rate Limit 적용

몇 년 전인지는 기억나진 않지만 Rate Limit 적용은 항상 애플리케이션 쪽에서 처리하는 것이 당연하다는 것이 주된 의견이었다. 그래서 그때 당시 Bucket4J 를 통해서 Spring 쪽에서 처리하고 했던 기억이 있다. 이제는 당연하게도 Istio와 같은 Service Mesh쪽에서 처리하는 것이 응당 맞다고 생각되는 것이 개발 세상이 이제 점점 더 클라우드향으로 이동된다는 느낌이다. 강력한

By Kevin H. Kwon
Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

Istio를 통한 header기반 API 라우팅/호출 시 cors preflight request 이슈 트러블슈팅 기록

현재 개발하고 있는 일부 컨테이너 기반의 서비스들을 Istio를 통해 서비스들을 구성하고 트래픽을 관리하고 있다. 이때 컨테이너 서비스가 같은 규격이 여러개가 같은 url과 port를 할당 받아서 사용해야는 애로 사항이 있어 Istio에서 header 기반으로 특별한 헤더가 있는 경우에만 라우팅이 될 수 있도록 구성하고 테스트를 진행했었다. Istio Request Routing 예제와 같이 header

By Kevin H. Kwon