끄적끄적

Spock의 Mock, Stub, Spy에 대해서 정리해두려고 한다. Spock으로 테스트코드를 작성하며 mocking을 위해 Stub이나 Mock, Spy를 자주 사용하게 된다. jUnit을 위주로 짜던 사람을 Stub이 약간 생소할 수도 있다. Mock - 기대한 값을 받을 것으로 예상되는 객체를 의미하고(Stub과 유사), 테스트를 하는 함수가 잘 동작되는지 행위검증을 위해 사용된다. Stub - 테스트 중에 만들어지며 정의된 응답을 리턴한다.(정의되지 않으면 응답값은 없다.) Spy - 일부분만을 정의하여 사용한다. 나머지는 그대로 동작한다. 이렇게 알고 코드를 작성하다보면 Mock과 Stub이 제일 많이 헷갈리게 된다. 간단하게 차이라고 말하면 Mock은 Stub과 유사하지만 Mock으로 지정된..

@Transactional이란 @Transactional 을 사용 하여 데이터베이스 트랜잭션에서 메서드를 래핑할 수 있습니다. 이를 통해 트랜잭션에 대한 전파, 격리, 시간 초과, 읽기 전용 및 롤백 조건을 설정할 수 있습니다. 트랜잭션 관리자를 지정할 수도 있습니다 . 트랜잭션 구현 세부정보 Spring은 트랜잭션의 생성, 커밋 및 롤백을 관리하기 위해 프록시를 생성하거나 클래스 바이트 코드를 조작합니다. 프록시의 경우 Spring은 내부 메소드 호출에서 @Transactional 을 무시합니다. 간단히 말해서, callMethod 와 같은 메소드가 있고 이를 @Transactional 로 표시하면 Spring은 호출된 @Transactional 메소드 호출 주위에 일부 트랜잭션 관리 코드를 래핑합니다..

최근에 보안 취약점으로 문제가 있었던 log4j에 대해 어디를 업데이트해야되는지 기록해두려한다. 취약 버전은 2.0 beta9

개발을 하다보면 필연적으로 많이 듣게 되는.. 또는 많이 겪게 되는 것 중 하나가 가비지 컬렉터일 것이다. 예를들면 jvm out of memory 에러같은? 그래서 오늘은 가비지컬렉터에 대해 정리를 해둘까한다. 먼저 가비지 컬렉터가 뭔지 알아보자. 쓰레기 수집가.. 그렇다 가비지란 원래는 정리되었어야하는 또는 정리되지 않은 메모리를 쓰레기라고 생각하면 될꺼같다. 컬렉터는 수집기.. 한마디로 가비지 컬렉터란 정리되어있지 않은 메모리를 수집하여 해제시키는 것이다. 본격적으로 알아보자. 일단 전공과목이나 수업에서 공부할때 C언어에 대해 배울땐 직접 메모리를 해제 시켜줬었던걸로 기억한다. #include #include // malloc, free 함수가 선언된 헤더 파일 int main() { int num..

Junit을 이용해서 간단하게 몇가지 테스트코드 작성 예제를 기록해 두려한다. 일단 테스트코드의 필요성부터 알아보자 내가 무엇을 구현해야하는지 머리 속에 있는 또는 요구사항을 인/아웃풋에 대한 테스트코드로 미리 만들어둔다. 테스트코드를 작성함으로써 테스트 시에 번거롭게 직접 API를 호출해보거나 결과를 일일히 확인 안해봐도 된다. - 개발 -> 실행 -> API 호출 -> 결과값에 대한 직접확인 -> 수정 -> 반복.. - 위와같은 확인 방법을 개발 -> 테스트코드실행 -> 테스트코드 성공/실패 확인(간단해짐) 테스트코드를 잘 짜두면 아무래도 눈으로 직접확인하며 사람이 검증하는 것보다 확실하게 버그를 줄일 수 있다. 빌드 배포시에 테스트코드가 통과되야 배포가 되게 끔 설정해두면 서비스에 반영되기전 버그를..

junit test를 하다가 No tests found for given includes 와 같은 에러가 났다. 해결방법은 Settings > Build,Execution,Deployment > Build Tools > Gradle > "Run tests using: IntelliJ IDEA" 로 변경해주면 된다.

최근 생각도 못했던 문제가 있어 또 한번 고생한 경험이 있다. JPA를 쓰는 환경에서는 대체로 아래와 같이 릴레이션에 대한 조인을 걸어두고 쓰는 경우가 많을 것이다. queryDsl로 리스트를 만들어주는 부분에서 조인걸린 테이블에 대한 조건처리를 해야할 경우가 생겼다. 왜 여태까지 이런 경우가 많이 없었는지 이해가 안되지만.. 또 한번의 삽질이 시작되었다. queryDsl에 조인을 걸고 조인걸린 부분에 대한 조건을 추가하고 확인해본결과 이상한 데이터가 자꾸 포함되어 조회가 되는것이였다. 로그에 남겨진 쿼리를 모두 분석하기 시작했다.. 쿼리가 나뉘어서 날라가면서 발생한 문제였다. 부모 테이블에서 조건처리에 대한 부분을 필터링 한 다음에 id를 기반으로 다시 IN을 하는것이다. 튜닝을 위해 찾아보기 시작했다..

https://fe-churi.tistory.com/51 기존 포스팅글에서 이넘에 대한 삽질을 했고 날짜 형식에서 문제가 생겨 JavaTimeModule을 추가했었다. 이어서 추가적으로 타임 포멧팅을 해줄 필요가 생겼다. 패턴을 "yyyy-MM-dd HH:mm:ss"패턴으로 리스폰스시에 변경해줄 필요가 생긴것이다. 방법은 간단하다. JavaTimeModule javaTimeModule = new JavaTimeModule(); LocalDateTimeSerializer localDateTimeSerializer = new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss").withZone(ZoneId.of("Asia/Seo..