분류 전체보기 87

테스트 케이스를 작성하지말자.

글 제목은 나도 한번 어그로 끌고싶어서 작성했다.... 외부 API를 사용할 때 그 외부 API 기능에대한 테스트 케이스에대한 나의 고민을 적어보려한다. 어제 AWS S3를 이용해 이미지를 업로드하는 기능의 개발을 마치고 테스트 코드를 작성중.. S3의 경우 Service Layer의 통합테스트 진행시 실제 S3객체를 이용해 테스트할시 테스트를 진행 할 때마다 S3로 업로드가 진행되어 프리티어를 이용하는 나에겐 큰 부담이 됬다. (비용을 떠나서 E2E테스트도 아닌 통합 테스트인데 굳이 S3에 이미지를 보내야하나 싶기도하고...) 구글링을 통해 S3 를 모킹 할 수 있는 객체를 발견했고 테스트를 코드를 작성하기위해 실제 프로덕션 코드를 보다... 문득 StackOverFlow에서 우문현답을 찾았던 경험이 ..

Decorator Pattern

Proxy Pattern과 많이 유사하지만 그 의도에 따라 나뉜다. 프록시를 통해 접근 제어가 목적 -> Proxy 프록시를 통해 기능 부가 -> Decorator 데코레이터는 인터페이스를 의존한다. 인터페이스의 구현체는 String을 반환함. 데코레이터는 인터페이스를 구현한 뒤 실제 객체 혹은 데코레이터를 주입받는다. MessageDecorator에서 String값에 ******을 앞뒤로 추가해주고, TimeDecorator에서 실제 객체의 메서드 실행시간을 구해준다. 클라이언트 또한 인터페이스를 의존하며 주입받은 객체의 메서드를 이용하여 요청을 완료한다. 실 객체 인스턴스를 생성 -> 데코레이터가 실 객체를 주입받음 -> 클라이언트는 데코레이터를 주입받아 요청을 실행.

공부/Java 2024.01.09

Test were not recieved

Verification에서 전체 테스트를 실행하다가 발생함. 보통 이 에러가 발생하면 인텔리제이 빌드 세팅을 그레이들에서 인텔리제이로 바꿔서 해결하는 블로그가 많이 뜬다. 나 역시도 그렇게 진행해봤지만 여전히 Test were not recieved 가 해결되지않았다. bulid.gradle 의 dependency에도 큰 문제가 없었고 테스트 모듈에 뭔가 문제가 있을거라 판단. 역시나 이전에 클래스명을 잘못생성해 프로덕션 모듈에는 존재하지않는 테스트 클래스가 남아있었다. 삭제해주니 정상적으로 전체 테스트 실행이 됬다. 다행!

Error 2024.01.09

조회수 동시성문제 비관적 Lock을 선택한이유.

조회수 기능을 어제 추가했는데 조회수같은 기능의 단골주제가 또 동시성문제다. 100명의 유저가 웹 사이트에 접속해있을 때 동시에 한개의 글 조회를 요청한다면 어떤 일이 발생할까? 우선 조회수가 증가하는 방식은 간단하게 설정해놨다. ( 아직 사용자마다 중복된 조회수를 방지하는 기능은 개발하지않아서 ) 유저가 글 조회 요청을하면 해당 글의 viewCount를 1씩 증가 시켰다. 테스트코드나, PostMan에서는 조회수가 이쁘게 딱딱 나오는걸 확인했지만 동시에 100명의 유저가 요청을 한다면 을 가정하고싶어 Jmeter 라는 프로그램을 사용하기로함. 1초안에 100명의 사용자가 get요청을 보내도록 설정을 했다. 그 결과는... 분명 100이 글을 조회했으니까 최종 조회수는 100이여야 한다. 하지만 조회수는..

Proxy Pattern

A객체가 B객체로 직접 요청을하는것이 아닌 어떠한 대리자를 통해 간접적 요청하여 접근을 제어하는 패턴 손님이 식당에 토시살 3인분을 주문했는데 식당에서 직접 횡성으로가서 한우를 잡아오지않고 냉장되어있던 토시살을 꺼내오는 느낌.. 요청은 실제 객체를 호출하지않고 대리자인 Proxy에 요청해 값을 넘겨받는다. 또한 요청은 interface에 의존하므로 요청자는 의존하는것이 Proxy인지 실제객체인지 알 수 없음. 강의중 학습 테스트를 통해 더 이해하게됬다. RealSubject는 실제 객체며 이 클래스의 역할은 호출시 로그를 출력하고 1초간 쓰레드를 잠시 멈춘다. 실 객체인 RealSubject는 Subject라는 인터페이스의 구현체이다. 요청을 하는 객체인 ProxyPatternClient는 Subjec..

공부/Java 2024.01.08

명령어 기초

프롬프트는 유저명@호스트명 으로 이루어져있다. 명령어에 " 를 나타낸다. 이후 " 를 닫으면 " " 사이에 입력했던 명령어가 입력된다. MacOS의 터미널은 대소문자를 구분하지 않기도하지만 Ubuntu에서는 대소문자를 구별한다. 명령어 입력시 대소문자를 구별해 입력하자. Arguments command argument ex) rm test.txt 명령어 이후 매개변수를 줘서(Space로 공백을 줘 구분) 특정한 결과값을 얻을 수도 있다. ncal에 년도를 입력해 1993년도의 달력을 조회 Option command -option 명령어에 옵셜을 줄 수 있다. 옵션 앞에는 - 를 붙여야함. 당연히 대소문자 구분 여러개의 옵션을 묶어서 같이 사용 할 수도있다. ex) ncal -3 -h, ncal -3h l..

공부/Linux 기초 2024.01.07

Layer간 의존성 줄이기 - 1 -

현재 내 프로젝트의 Layerd Architecture 전통적인 3계층을 따르고있다. Presentaion Layer ⬇️ Business Layer ⬇️ Persistence Layer 이러한 계층형 아키텍쳐를 설계한 이유의 첫번째는 테스트 코드 작성을 중요하게 여겨서다. 계층별로 관심사를 분리하면 테스트 코드 작성이 쉬워진다. 특히 Presentaion Layer인 Controller의 단위 테스트를 작성할 때 3계층 아키텍처를 고려하지않고 무분별하게 프로덕션 코드를 작성했다면 Service Class뿐아니라 Persistence Layer들의 객체까지도 Mocking했어야할것이다. 그런데, 최근 계층형 아키텍쳐에대해 공부하며 내 개인 프로젝트를 만들며 문제점을 발견했다. 나의 개발 방향성을 지속적으..

12장 창발성

창발적 설계로 깔끔한 코드를 구현하자 몇가지 설계 규칙으로 우수한 설계를 이끌어내자 켄트 백이 제시한 단순한 설계 규칙 4가지를 소개하고있다. 1. 모든 테스트를 실행하라 다양한 테스트 코드를 작성하는 시스템을 만드려 애쓰면 설계 품질이 높아진다. 개발자는 테스트 코드를 많이 작성하고 쉽게 테스트를 진행하려하기에 SRP , DIP와 같은 원칙을 지키려 추상화, 인터페이스, 의존성 주입등의 기술을 사용해 결합도를 낮춘다. 이에따라 자연스럽게 테스트 코드를 많이 작성하려 노력할수록 프로덕션코드의 설계 품질또한 같이 높아진다. 2. 리팩토링 테스트 케이스를 작성후 안전하게 코드와 클래스를 정리할 수 있다. ( 테스트라는 안전망이 존재하기때문에 ) 리팩토링 단계에서는 응집도를 높이고, 결합도를 낮추고, 관심사를..

책/CleanCode 2024.01.06