개요오늘도 평화롭게 코드를 작성하고 있었어요..저희 팀은 organazation으로 같이 코드를 관리하고 있기에 팀원들의 코드를 염탐해 봤습니다.그런데!!처음보는 코드를 발견하였습니다. 그건 바로 Embedded 요건 멀까?찾아보니 JPA에서 임베디드 타입을 제공하는 방법이었습니다.~~~~~이걸 활용하면 단위 테스트를 사용할때, 생성자 파라미터의 갯수를 줄일 수 있을꺼 같다!!!생각해보니...기존에 사용했었던 빌더 패턴도 생성자 파라미터 갯수를 줄일 수 있지 않나??갑자기 궁금해졌다. 뭐가 좋은걸까???그래서 뭘 테스트 했는데.초반에 다음처럼 단위 테스트를 작성하고 싶었습니다.String userId = "userI123456";CoreException result = assertThrows(CoreEx..
TDD를 학습하다보면 테스트 더블이라는 말이 나온다. 그렇다면 테스트 더블은 테스트를 두번하는걸까?gpt한테 물어보니 이 용어는 영화 용어에서 스턴트 더블에서 왔다고 한다.그리고 찾아보니 더블이 두배라는 뜻이 있지만 대역이라는 뜻이 있다고 한다.그럼 뜻을 다시 해석해보면 테스트를 하기 위해 대역을 쓰는거라고 이해하면 될거 같다.요런 관점에서 생각을 해본다면테스트 더블에는 총 5가지의 대역들이 존재한다.mock, spy, stub, fake, dummy요렇게 5가지가 있다고 한다.이제 대역이라는 것을 바탕으로 생각을 해보면mock은 구현에 대한 대역spy는 구현에 대한 대역stub은 값에 대한 대역fake은 구현에 대한 대역dummy는 값에 대한 대역요렇게 나눌수 있을거다.근데 이상한건 구현3에 값이2개다..
오랜만에 디자인 패턴을 공부하는 것 같다. 이 패턴에 대해 간략하게 설명하자면, 공통 부분을 미리 만들어 놓고 그것을 가져다 쓰는 방식이다. 이 패턴은 상속을 통해 이뤄진다. 상속? 상속을 사용한다는 뜻은 부모와 자식의 관계가 명확하다는 이야기다. 즉, 부모쪽에 공통 부분을 뽑아 내고 자식 쪽에서 그것을 오버라이딩 하는 것이다. 예제를 고민해봤는데 생각보다 쉽지 않을 것 같다. 간단하게 숫자를 계산하는 계산기를 만들어 보려구 한다. 시작 public int calculate() { return get(1, 2, 3, 4); } private int get(int... numbers) { int result = 1; for (int number : numbers) { result *= number; } r..
퍼사드는 사실 불어다. 건물 외각이라는 뜻을 가졌다. 퀴즈를 하나 낼 태니 한번 맞춰보시길 이 회사에는 현재 몇명의 개발자가 일하고 있는가? (어디든 앉아서 일하고 있는 사람만) 이 회사는 어떤 회사일까? 첫 번째 질문 같은 경우는 즉, 화장실에 갔던가 휴가 중인 인원 등을 제외하라는 뜻이다. 아마 100%확률로 틀릴 것이다. 심지어 이 회사를 다니고 있는 사람들 모두 이 문제를 틀릴 것이다. 왜냐하면 화장실를 간 사람들을 일일이 세면서 이 문제를 맞출 이유는 없기 때문이다. 아니 애초에 말도 안되는 문제이기 때문이다. 어떻게 외각만을 보고 문제를 맞춘다는 건 말이 되지 않기 때문이다. 하지만 두 번째 질문은 대답이 가능하다. 이런식으로 외부 코드만 확인해서 외부 코드만 보고서 어떤 동작을 하는지 대략적..
디자인 패턴을 공부하면서 놓쳐서면 안되는 사실은 절대로 코드로 학습을 하면 안된다는 사실이다. 나는 브릿지 패턴을 공부하면서 이에 더 실감했다. 물론, 코드 자체도 디자인 패턴이지만 사실 그것 보다 중요한 건 어떻게 그 코드를 작성했는가가 중요하다. 인터페이스를 사용하고 클래스를 사용하는 건 그렇게 까지 중요한건 아니다. 아무튼 지금 내가 작성 하는 부분은 브릿지 패턴이다. 브릿지는 다리라는 뜻이다. 즉, 코드 상에서 다리를 내려줘야 하는데 어떤걸로 하는 것이 유리할까? 클래스로 해도 상관없고 인터페이스로 해도 상관없다. UML을 보면 인터페이스로 되어있는데 이는 사실 인터페이스 interface 이게 아니다. 그냥 추상적으로 표현 할 수 있다는 뜻이다. 저번 포스팅에서 전략 패턴에 대해 공부하였다. 전..
이 패턴 생각보다 쉽지 않다. 패턴에 대해 간략하게 설명하면 전략을 구분짓는 패턴이다. 당연한 이야기 지만 이런이야기는 누구나 할 수 있다. 그러면 다음 코드를 보고 이것이 어떤 패턴인 맞출 수 있을까? Template template = new Template(new Action()); 지금까지 학습한 팩토리, 추상 팩토리, 빌링, 프로토 패턴인데 이것만 봐도 아쉽게도 전략패턴인지 확신을 가질 수 없다. 이는 저번 포스트에서 말했듯이 관점에 따라 패턴의 이름이 달라질 수 있다. 디자인 패턴을 공부하면서 빌더 패턴 처럼 딱 떨어지는 패턴이 있는 반면에 대부분 패턴들은 딱 떨어지지 않는다는 사실을 알 수 있다. 누군가가 위 코드는 추상 팩토리 패턴이라고 말한다면, 틀린것일까? 지금은 추상 팩토리와 전략 패..
디자인 패턴을 공부하면서 하나씩 공부할때는 생각보다 쉬운데 여러개를 동시에 공부하거나 다른 패턴을 공부를 해야 되는 상황이라면 헷갈리는 경우가 굉장히 많았다. 디자인 패턴에서는 이러한 양상이 종종 발생이 되며, 대표적으로 팩토리 메소드 패턴이랑 추상 팩토리 패턴이 존재한다. 이렇게 비슷한 패턴들이 많은 이유는 관점때문이라고 한다. 그러면 이 두개의 패턴은 어떻게 관점이 다른지 확인해보자. 어떻게 보면 두 개모두 팩토리 즉, 공장에서 무언가를 만드는 듯한 느낌을 준다. 그러면 뭐가 다른 걸까? 이름 부터 이 두가지 패턴은 다르다는 느낌을 강력하게 받는다. 처음에 팩토리 패턴을 생각했을 때, 인터페이스 또는 추상 클래스를 통해 만든것을 직접적으로 사용한다고 생각했다. 물론, 이게 맞을 수 있겠지만, 이 접근..
싱글톤 패턴은 내가 생각하기에 가장 만들기 쉬우면서 가장 위험한? 패턴이라 생각이 든다. 원래 블로그를 작성하지 않고 머릿속에 정리할 생각이 었지만 아무리 생각해도 답이 나오지 않다는 생각에 이렇게 작성하게 되었다. 일단 싱글톤 패턴이 무엇인지 부터 생각 해야 된다. 싱글톤 패턴은 싱글, 즉 객체가 하나로 나오는 패턴이다. 우리가 알기로는 일반적으로 객체는 생성할때마다 다른 객체가 나오는 것이 당연한이야기다. 다시말해 사람이라는 클래스가 존재한다면, 각자 다른 사람인것 처럼 객체도 마찬가지로 생성할때마다 다르게 나오는게 정상이다. 싱글톤 패턴은 이 정상적인 행동을 제약하는 패턴이라 생각이 든다. 위에서 언급했듯이 싱글톤 패턴을 이용하게 되면 아무리 객체를 많이 만들어도 같은 객체가 나온다는 뜻이다. 근데..
나는 얼마전 스프링 시큐리티를 설치하고, 유저를 만들어서 진행을 한적이 있었다,. 그리고 오늘 프로잭트를 실행시켰다. 하지만 결과는 참담했다. 모든 테스트가 틀렸다고 나온다는 것을 알 수 있었다. 이상했다. 나는 분명... 한적이 없는데.. 알고보니 스프링 시큐리티 자체에서 유저를 만들고, 그것을 모든 테스트 코드에 적용하기 때문이라고 했다. 그래서 나온 상태코드가 403 (권한이 없다)가 나온것도 그 때문인것 같다. 그러면 어떻게 이 문제를 해결해야 될까? @Configuration @EnableWebSecurity public class SpringConfig extends WebSecurityConfigurerAdapter{ } 이걸 추가하게 되면 스프링 시큐리티에서 적용되는 시큐리티는 더 이상 적..
원래는 스프링 시큐리티에 대해 공부하고 하려다가 너무 오래 걸릴 것 같아 생략하고 적용하는것부터 진행하려고 한다. 아무튼 스프링 시큐리티를 적용하는 이유는 게시글을 만든 유저만 수정이 가능하게 만들기 위해 적용하는걸로 알고 있다. 아무튼... 적용해보자. org.springframework.security.oauth.boot spring-security-oauth2-autoconfigure 2.1.10.RELEASE 이것을 추가해줘야 스프링 시큐리티를 사용할 수 있게 된다. (이글은 백기선님 강의를 보고 작성한 글이기때문에 start.security를 사용하지 되지 않습니다.) 생각해보니 vo를 만들지 않았다. @Getter @Setter @Builder @NoArgsConstructor @AllArgs..
이번에는 강의를 듣기전에 먼저 작성하기로 해보자. 이벤트 수정의 경우는 1. 수정이 정상적으로 실행이 되었을때 : 200 2. 수정이 잘못된 경우 - 비어있는 객체가 들어있을 경우. - 잘못된 객체가 들어올 경우.. - 권한이 없는 사람이 접근했을 경우 - 페이지가 존재하지 않는 경우 이렇게 들 수 있는데... 솔직히 2-3은 지금당장은 하지 못할 것 같다. 왜냐하면 유저를 고려하지 않았기 때문이다. 테스트 코드를 작성해보자. @Test void update_event() throws Exception { Delivery delivery = generateEvent(100); DeliveryDto deliveryDto = modelMapper.map(delivery, DeliveryDto.class); ..
곧 회사일이 바빠진다고 한다. 바빠지기 전에 열심히 공부 하자! 간단하게 테스트 부터 작성해보자. @Test public void create_event() throws Exception { Delivery delivery = generateEvent(100); this.mockMvc.perform(get("/api/delivery/{id}",delivery.getId())) .andDo(print()) .andExpect(status().isOk()) .andExpect(jsonPath("id").exists()) .andExpect(jsonPath("_links.self").exists()) .andExpect(jsonPath("_links.profile").exists()); } 이것을 실행하면 어..
