Simple is IT, 누구나 보고 누구나 깨닫는 IT

나는 무엇을 두려워했는가.

currenjin — Tue, 12 Aug 2025 21:56:29 +0900

https://medium.com/@jung23e/%EB%82%98%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%84-%EB%91%90%EB%A0%A4%EC%9B%8C%ED%96%88%EB%8A%94%EA%B0%80-d8bc49f87da3

도전은 연결된다. — 5년차 소프트웨어 엔지니어편

currenjin — Sat, 2 Aug 2025 22:07:58 +0900

https://medium.com/@jung23e/%EB%8F%84%EC%A0%84%EC%9D%80-%EC%97%B0%EA%B2%B0%EB%90%9C%EB%8B%A4-5%EB%85%84%EC%B0%A8-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%ED%8E%B8-f26edb188a9f

도전은 연결된다. — 5년차 소프트웨어 엔지니어편

Intro: 문제 해결은 도전에서 시작된다

medium.com

Spring Bean Lifecycle

currenjin — Thu, 31 Oct 2024 21:14:08 +0900

Life Cycle

(블로그보단 아래 위키의 가독성이 더 좋다. 추천한다)

https://currenjin.github.io/wiki/spring-bean/#life-cycle

Spring Bean

currenjin.github.io

Bean이라는 녀석은 어떤 타이밍에 생성되고, 또 소멸될까?

순서

크게 다음과 같은 순서를 갖는다.

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

순서만 봐서는 와닿지 않을 것이다. 아래와 같은 예제를 생각해보자.

@Service
public class UserService {
   private final UserRepository userRepository;

   public UserService(UserRepository userRepository) {
      this.userRepository = userRepository;
   }
}

@Repository
public class UserRepository {
}

생성자 호출

Bean의 생명주기에 따라 콘솔 출력을 해보자. 첫 번째로는, 생성자를 호출하는 것이다.

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

UserService의 생성자에 콘솔을 작성해보자.

public UserService(UserRepository userRepository) {
  System.out.println("1. 생성자 호출: Bean 인스턴스 생성");
  this.userRepository = userRepository;
}

이를 확인하기 위한 테스트는 다음과 같이 작성할 수 있다.

@SpringBootTest
class UserServiceBeanTest {
   @Test
   void lifeCycleTest() {
      AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
      context.register(UserService.class);
      context.register(UserRepository.class);
      context.refresh();

      context.getBean(UserService.class);

      context.close();
   }
}

실행해보면, 아래와 같이 출력된다.

1. 생성자 호출: Bean 인스턴스 생성

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

의존성 주입

의존성 주입도 확인해보자. UserService가 UserRepository를 의존하고 있기 때문에 UserRepository의 생성자에 다음과 같은 콘솔을 추가한다.

@Repository
public class UserRepository {
    public UserRepository() {
        System.out.println("2. 의존성 주입: Properties 세팅");
    }
}

테스트 코드를 실행해보자. 아래와 같은 순서로 출력될 것이다.

2. 의존성 주입: Properties 세팅
1. 생성자 호출: Bean 인스턴스 생성

숫자를 2로 마킹해서 그렇지, 당연한 결과다. UserService를 호출하기 위해 UserRepository 인스턴스가 먼저 생성되어야 하기 때문이다. (1, 2번의 순서대로 출력될 거라 생각한 사람은 다시금 깨닫는 계기가 될 수 있다)

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

@PostConstruct 메서드 실행

이제, PostConstruct 메서드로 넘어가보자.

PostConstruct 메서드는 이름과 같이, 생성자를 호출한 이후 호출되는 메서드이다.

UserService, UserRepository 모두 적용해보자.

@Service
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        System.out.println("1. 생성자 호출: Bean 인스턴스 생성");
        this.userRepository = userRepository;
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("3. PostConstruct 메서드 실행: UserService");
    }
}

@Repository
public class UserRepository {
    public UserRepository() {
        System.out.println("2. 의존성 주입: Properties 세팅");
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("3. PostConstruct 메서드 실행: UserRepository");
    }
}

결과가 어떻게 나올지 상상해보고 테스트를 실행해보자. 어떻게 나올 것 같은가?

결과는 다음과 같다.

2. 의존성 주입: Properties 세팅
3. PostConstruct 메서드 실행: UserRepository
1. 생성자 호출: Bean 인스턴스 생성
3. PostConstruct 메서드 실행: UserService

감이 좀 잡히는가?

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

afterPropertiesSet() 메서드 실행

이제는 afterPropertiesSet 메서드를 상속받아 실행해보자.

afterPropertiesSet 메서드는 우리가 application.yml 등에서 정의한 환경변수가 스프링의 빈에 의해 주입된 이후 실행되는 메서드다.

확인하기 위해서는 InitializingBean을 상속하여 메서드를 오버라이딩 해야한다.

@Service
public class UserService implements InitializingBean {
   // ...

   @Override
   public void afterPropertiesSet() {
      System.out.println("4. afterPropertiesSet 메서드 실행: UserService");
   }
}


@Repository
public class UserRepository implements InitializingBean {
   // ...


   @Override
   public void afterPropertiesSet() {
      System.out.println("4. afterPropertiesSet 메서드 실행: UserRepository");
   }
}

실행해보면 다음과 같다.

2. 의존성 주입: Properties 세팅
3. PostConstruct 메서드 실행: UserRepository
4. afterPropertiesSet 메서드 실행: UserRepository
1. 생성자 호출: Bean 인스턴스 생성
3. PostConstruct 메서드 실행: UserService
4. afterPropertiesSet 메서드 실행: UserService

어떤 차이인지 모르겠다면 UserService에서 Value Annotation을 통해 Properties를 주입받도록 해준다. (cacheEnabled)

@Service
public class UserService implements InitializingBean {
   @Value("${user.cache.enabled:true}")
   private boolean cacheEnabled;

   private final UserRepository userRepository;

   public UserService(UserRepository userRepository) {
      System.out.println("1. 생성자 호출: Bean 인스턴스 생성. property : " + cacheEnabled);
      this.userRepository = userRepository;
   }

   @PostConstruct
   public void postConstruct() {
      System.out.println("3. PostConstruct 메서드 실행: UserService. property : " + cacheEnabled);
   }

   @Override
   public void afterPropertiesSet() {
      System.out.println("4. afterPropertiesSet 메서드 실행: UserService. property : " + cacheEnabled);
   }
}

결과가 어떨지 상상해보자.

2. 의존성 주입: Properties 세팅
3. PostConstruct 메서드 실행: UserRepository
4. afterPropertiesSet 메서드 실행: UserRepository
1. 생성자 호출: Bean 인스턴스 생성. property : false
3. PostConstruct 메서드 실행: UserService. property : true
4. afterPropertiesSet 메서드 실행: UserService. property : true

무언가 이상하지 않은가? PostConstruct를 호출하는 시점에 이미 properties가 주입되어있는 상태이다. 그렇다면, PostConstructor와 afterPropertiesSet은 도대체 무슨 차이일까?

극명한 차이는 다음과 같다. PostConstruct는 javax 패키지에 있고, afterPropertiesSet 메서드는 springframework 패키지에 있다. 특히 정의된 afterPropertiesSet 메서드를 보면, Exception을 던질 수 있다.

void afterPropertiesSet() throws Exception;

이로 인해, afterPropertiesSet 메서드는 property 값에 따라 예외를 핸들링 할 수 있다. 그 외에는 큰 차이가 없으므로 스프링 프레임워크에 의존하지 않는 PostConstruct 어노테이션이 주로 사용된다.

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

@PreDestroy 메서드 실행

PreDestroy 또한 어노테이션이 존재한다. UserService와 UserRepository에 다음과 같이 적용해보자.

@Service
public class UserService implements InitializingBean {
   // ...

   @PreDestroy
   public void preDestroy() {
      System.out.println("5. PreDestroy 메서드 실행: UserService. property : " + cacheEnabled);
   }
}

@Repository
public class UserRepository implements InitializingBean {
   // ...

   @PreDestroy
   public void preDestroy() {
      System.out.println("5. PreDestroy 메서드 실행: UserRepository");
   }
}

그리고 테스트 코드에서 destroy의 구분을 위해 콘솔을 추가한다.

@SpringBootTest
class UserServiceBeanTest {
    @Test
    void lifeCycleTest() {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        context.register(UserService.class);
        context.register(UserRepository.class);
        context.refresh();

        context.getBean(UserService.class);

        System.out.println("============================");

        context.close();
    }
}

자, 이번엔 결과가 어떨지 상상해보자. 이제는 예상이 가지 않는가? 자연스럽게 상상해보자.

결과는 다음과 같다.

2. 의존성 주입: Properties 세팅
3. PostConstruct 메서드 실행: UserRepository
4. afterPropertiesSet 메서드 실행: UserRepository
1. 생성자 호출: Bean 인스턴스 생성. property : false
3. PostConstruct 메서드 실행: UserService. property : true
4. afterPropertiesSet 메서드 실행: UserService. property : true
============================
5. PreDestroy 메서드 실행: UserService. property : true
5. PreDestroy 메서드 실행: UserRepository

context.close 메서드가 호출되면, UserRepository를 의존하는 UserService에서 먼저 Destroy가 진행된다. 당연한 결과다.

생성자 호출 (Bean 인스턴스 생성)
의존성 주입 (Properties 세팅)
@PostConstruct 메서드 실행
afterPropertiesSet() 메서드 실행
@PreDestroy 메서드 실행
destroy() 메서드 실행

destroy() 메서드 실행

이제 마지막 단계인 destroy() 메서드는 어떨까?

@Service
public class UserService implements InitializingBean, DisposableBean {
   // ...

   @Override
   public void destroy() {
      System.out.println("6. destroy 메서드 실행: UserService. property : " + cacheEnabled);
   }
}

@Repository
public class UserRepository implements InitializingBean, DisposableBean {
   // ...

   @Override
   public void destroy() {
      System.out.println("6. destroy 메서드 실행: UserRepository");
   }
}

결과는 대부분 예상할 수 있을 것이다.

2. 의존성 주입: Properties 세팅
3. PostConstruct 메서드 실행: UserRepository
4. afterPropertiesSet 메서드 실행: UserRepository
1. 생성자 호출: Bean 인스턴스 생성. property : false
3. PostConstruct 메서드 실행: UserService. property : true
4. afterPropertiesSet 메서드 실행: UserService. property : true
============================
5. PreDestroy 메서드 실행: UserService. property : true
6. destroy 메서드 실행: UserService. property : true
5. PreDestroy 메서드 실행: UserRepository
6. destroy 메서드 실행: UserRepository

눈치챈 사람도 있겠지만, PreDestroy는 javax 패키지에 존재하고, destroy 메서드는 springframework 패키지에 존재하며 에러 핸들링이 가능하다는 차이가 있다.

앤 드루얀의 코스모스: 가능한 세계들

currenjin — Sat, 12 Oct 2024 22:22:55 +0900

이 광대한 코스모스의 시작은 어디이며, 끝은 어디인가. 우리가 바라보는 시선은 시작으로 향할 것인가.

시간이 지나고, 우리의 끝은 이 거대한 서사의 시작에 한 번이라도 닿았을까.

칼 세이건의 코스모스 - 두 가지 질문

currenjin — Thu, 3 Oct 2024 15:12:50 +0900

이 책의 682(마지막)페이지를 넘긴 후에는 두 가지의 질문만이 머릿속에 맴돈다.

나는 지금까지 어떻게 살아왔는가? 그리고 또 어떻게 살아갈 것인가?

벌써 몇 번째 정독하는 건지 모를. 이번에 가장 기억에 남는 키워드는 바로 ‘핵전쟁’이다. 누군가가 나에게 ‘핵전쟁은 비극인가?’라는 질문을 한다면 나는 확신을 담아 대답할 수 있다. “절대 비극이다.” 핵전쟁에 사용되는 핵무기는 도대체 왜 탄생하게 됐을까?

개인의 생존 위협과 분노에 ‘살인’과 같은 상황이 펼쳐지듯, 국가의 생존 위협과 분노에 ‘전쟁’이라는 상황이 수없이 발생해왔다. 나는 ‘심리적 관점에서 전쟁은 살인과 같다’는 칼 세이건의 말에 전적으로 동의한다. 2차 세계대전이 한창일 때, 추축국 독일은 핵무기 제작에 돌입했었으며, 연합국 미국이 이를 지켜볼 수만은 없었다. 이후 수많은 학자를 미국으로 데려와 말도 안 되는 짧은 시간 안에 이론을 검증했고, 결과적으로 끔찍하기 그지없는 ‘핵무기’가 탄생했다.

왜 우리는 서로 같은 문명끼리 화해할 줄 모르고, 증오심으로 가득 차 자기 파괴의 길로 다가서는 것인가? 우주에서 내려다본 지구는 국경선도 없는 창백한 푸른 점에 불과할 뿐인데 말이다. 엄청난 양의 에너지가 뿜어져 나온 대폭발부터, 핵융합 반응이 시작되고, 연료를 소모한 별들은 또 폭발하며 여러 별이 탄생했다. 그리고 그 옆에 핵융합 반응을 일으키기 어려운 질량을 가진 행성들. 그중 하나가 바로 우리의 원시 지구이다. 우주의 변두리에 존재할 뿐인 인간은 자신과 다른 생각을 하는 사람이나 사회를 기괴한 존재로 간주하며 혐오하고는 한다. 스스로에 대한 의심은 갖지 않으면서 말이다.

하지만 수많은 행성 중 생물이 탄생하는 과정은 아주 극한의 어려움이 따른다. 우주에서 벌어진 진화의 단계를 이해한다면, 거대한 ‘수소 산업’의 최종 산물로서 태어난 생물 하나하나가 정말 소중한 존재임을 알게 된다. 그리고 그들이 문명을 이뤄 현재는 스스로 기원을 인식할 수 있는 정도까지 성장해 왔다. 이것이 코스모스의 대서사시가 아니면 무엇이겠는가.

우주에 박힌 미물이면서 기적에 가까운 우리 인간이 자신에게 가장 위험한 존재로 변하다니. 얼마나 끔찍한가? 우리는 아주 오래전부터 사랑의 범주를 넓혀왔다. 자기가 속한 마을에서, 부족으로, 그리고 도시에서, 국가의 순으로 말이다. 그리고 이제는 우리가 사랑해야 할 범주를 지구로 확대해야 하지 않을까?

그렇다면 질문을 해보자. 나는 어떻게 살아왔고, 또 어떻게 살아갈까?

Fixture Monkey를 적용해보자 w/JPA Test

currenjin — Sat, 21 Sep 2024 22:40:14 +0900

Link

Fixture Monkey를 적용해보자

지루함을 편함으로 바꿔주는 Fixture Monkey에 대한 문서이다.

Problem

테스트를 작성하며 각자 느끼는 고충이 있을 것이다. 그 중 많은 사람들이 테스트를 위한 셋업 코드를 작성하며 많은 시간을 소요하고, 지루함을 느끼곤 한다. TDD의 저자 켄트벡은 두려움이 지루함으로 변할 때까지 테스트를 작성하라고 하지만, 나는 더 나아가 반복되는 지루함은 반드시 자동화해야 한다고 생각한다.

테스트 코드를 작성하는 우리의 두려움은 지루함으로 바뀌었으니, 이 지루함의 반복됨을 편함으로 바꿀 수는 없을까?

Fixture Monkey

Fixture Monkey는 이런 고민을 해결해준다. 이 라이브러리를 사용하면,

테스트 데이터 생성을 자동화하여 시간을 아낄 수 있다.
다양한 시나리오를 쉽게 테스트할 수 있다.
테스트 코드의 가독성과 유지보수성이 높아진다.
엣지 케이스를 쉽게 생성하여 더 견고한 테스트가 가능하다.

Fixture Monkey를 사용하면, 테스트 작성에 대한 부담은 줄어들고 실제 비즈니스 로직 테스트에 더 집중할 수 있다.

Spring Boot JPA

Fixture Monkey를 테스트하기 위해 Spring Data JPA 프로젝트에 구현되어있는 테스트 코드를 참고할 생각이다. JPA가 무엇인지, 사용법은 어떻게 되는지는 이 글을 보는 사람이라면 알고 있다고 가정하겠다.

Environment

Spring Boot Framework 2.6.4
Java 17
Fixture Monkey 1.0.25
Spring Data JPA
H2 Database

Domain Model

User Entity

@Entity
@Table(name = "user")
public class User {
    public User() {
        this(null, null, null);
    }

    public User(String firstName, String lastName, String emailAddress) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.emailAddress = emailAddress;
        this.active = true;
        this.createdAt = new Date();
    }

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String firstName;

    private String lastName;

    private boolean active;

    @Column(nullable = false, unique = true)
    private String emailAddress;

    @Temporal(TemporalType.TIMESTAMP)
    private Date createdAt;

    // ...Getter
    // ...Setter
}

User Repository

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

Test

먼저, 우리가 일반적으로 작성하는 테스트 코드로 작성하겠다.

기본 클래스 셋업으로는 아래 코드와 같다.

@DataJpaTest
class UserRepositoryTest {
    @PersistenceContext
    private EntityManager em;

    @Autowired
    private UserRepository repository;

    // ...Test Function
}

설명해보자면,

@DataJpaTest : JPA 테스트를 위한 어플리케이션 컨텍스트만 로드하여 인메모리 데이터베이스를 사용한다.
@PersistenceContext EntityManager : JPA EntityManager를 주입받는다. 테스트에서 직접적인 데이터베이스 조작이 필요한 경우 사용한다.
@Autowired UserRepository : 테스트 대상인 UserRepository를 주입받는다.

Creation AS-IS

첫 번째로, 생성을 위한 테스트를 진행하겠다.

@BeforeEach
void setUp() {
    firstUser = new User("hyunjin", "jeong", "hyun0524e@naver.com");
}

@Test
void creation() {
    Query query = em.createQuery("select count(u) from User u");
    Long before = (Long) query.getSingleResult();

    repository.save(firstUser);

    assertEquals(before + 1L, query.getSingleResult());
}

firstUser 객체를 직접 생성한다.
entityManager를 통해 count 쿼리를 생성한다.
생성 이전 count를 조회한다.
firstUser를 db에 저장한다.
생성 이후 count와 생성 이전 count + 1과 일치한지 확인한다.

위 코드만 보면 우리가 일반적으로 작성하는 테스트 코드로 생각된다.

여기서, firstUser 객체에 더 많은 파라미터를 담게 된다면 어떨까?

@BeforeEach
void setUp() {
    firstUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
}

게다가 객체를 여러 개 생성하여 테스트하려면 어떻게 될까?

private User firstUser;
private User secondUser;
private User thirdUser;
private User fourthUser;
private User fifthUser;

@BeforeEach
void setUp() {
    firstUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    secondUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    thirdUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    fourthUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    fifthUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
}

게다가 우리가 만든 User Entity에서 이메일은 중복할 수 없다는 점은 잊지 말자

@BeforeEach
void setUp() {
    firstUser = new User("hyunjin", "jeong", "hyun0524e@naver.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    secondUser = new User("hyunjin", "jeong", "qwe@test.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    thirdUser = new User("hyunjin", "jeong", "zxc@test.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    fourthUser = new User("hyunjin", "jeong", "dfg@test.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
    fifthUser = new User("hyunjin", "jeong", "asd@test.com", "서울특별시 강남구 태헤란로 xx번길", "xx아파트 xxx동 xxxx호", "010-0000-0000", LocalDate.of(2000, 5, 24));
}

자, 이제 어떻게 할 것인가? 이메일만 따로 받아 객체를 생성하는 메소드를 작성할 것인가? 그러면 완전 다른 값이 필요한 객체는?

결국엔 객체를 생성하며 모든 값을 '생각하고' 넣어주어야 한다는 것이다. Fixture Monkey에서는 우리가 테스트 로직에만 집중할 수 있도록 도와준다.

Dependency & Build object

일단 종속성을 추가하고,

Dependency

dependencies {
    testImplementation 'com.navercorp.fixturemonkey:fixture-monkey-starter:1.0.25'
}

사용을 위해 테스트 클래스에서 FixtureMonkey 객체를 빌드한다.

First SetUp

@DataJpaTest
class UserRepositoryTest {
    FixtureMonkey fixtureMonkey = FixtureMonkey.builder().objectIntrospector(ConstructorPropertiesArbitraryIntrospector.INSTANCE).build();

    // ...
}

Creation TO-BE

아까 정의했던 객체를 FixtureMonkey를 통해 생성해 보자.

@BeforeEach
void setUp() {
    firstUser = fixtureMonkey.giveMeOne(User.class);
}

놀랍게도 이게 끝이다!

fixtureMonkey 객체에서 giveMeOne(class)를 호출하면 필요한 파라미터에 난수값을 적용해 해당 클래스의 객체를 생성해주는 것이다.

Debug를 통해 생성된 객체를 확인해 볼까?

User {
    id = null;
    firstName = "춝䪼ꧏ";
    lastName = "苖⻵ꪘ쫏▷膄톣㷂䱧";
    active = true;
    emailAddress = "ᛩോ튅⛝櫕ᣵ솙칖谌ｰ퀭埘樅㺏㧑⍭規喲ꫮ൐Ὧ륑삲砎鳃抝Фꞻ᣾⤇崆";
    createdAt = "Mon Sep 16 12:18:00 KST 2024";
}

Fixture Monkey 동작

내부 동작이 궁금하지 않다면 넘어가도 좋다.

내부 동작

라이브러리의 소스코드를 파악해 본 결과 다음과 같은 동작 과정을 거친다.

giveMeOne 메서드를 호출한다.
타입 정보를 담은 default builder 인스턴스를 생성한 후 sample 메서드를 호출한다.
sample 메서드에서는 각 필드의 타입에 일치하는 값을 생성하고, 이 값으로 해당하는 타입 인스턴스를 생성한다.
1. resolve 함수가 호출되면 타입에 일치하는 값을 생성한다.
2. conbimed 함수가 호출되면 필드에 생성된 값으로 인스턴스를 생성해 반환한다.

giveMeOne

public <T> T giveMeOne(Class<T> type) {
    return this.giveMe(type, 1).get(0);
}

타입 객체를 넘기며 호출하는 내부 함수 giveMe가 있다.

giveMe

public <T> List<T> giveMe(Class<T> type, int size) {
    return this.giveMe(type).limit(size).collect(toList());
}

public <T> Stream<T> giveMe(Class<T> type) {
    return Stream.generate(() -> this.giveMeBuilder(type).sample());
}

giveMeBuilder를 호출한 후, sample을 호출하는데

먼저 giveMeBuilder를 보자.

public <T> ArbitraryBuilder<T> giveMeBuilder(Class<T> type) {
    TypeReference<T> typeReference = new TypeReference<T>(type) {
    };
    return giveMeBuilder(typeReference);
}

giveMeBuilder에서는 type을 받고, 해당하는 타입에 대한 ArbitraryBuilder를 리턴받는다.

ArbitraryBuilder를 만들어주는 함수를 확인해볼까? 이해하기 쉽게 주석을 달아놨다.

public <T> ArbitraryBuilder<T> giveMeBuilder(TypeReference<T> type) {
    // 1. Type에 대한 정보를 담는다.
    RootProperty rootProperty = new RootProperty(type.getAnnotatedType());

    // 2. Type에 해당하는 ArbitraryBuilder를 매칭한다.
    ArbitraryBuilderContext builderContext = registeredArbitraryBuilders.stream()
        .filter(it -> it.match(rootProperty))
        .map(MatcherOperator::getOperator)
        .findAny()
        .map(DefaultArbitraryBuilder.class::cast)
        .map(DefaultArbitraryBuilder::getContext)
        .orElse(new ArbitraryBuilderContext());

    // 3. Type 정보를 담은 DefaultArbitraryBuilder 인스턴스를 생성한다.
    return new DefaultArbitraryBuilder<>(
        fixtureMonkeyOptions,
        rootProperty,
        new ArbitraryResolver(
            traverser,
            manipulatorOptimizer,
            monkeyManipulatorFactory,
            fixtureMonkeyOptions,
            monkeyContext,
            registeredArbitraryBuilders
        ),
        traverser,
        monkeyManipulatorFactory,
        builderContext.copy(),
        registeredArbitraryBuilders,
        monkeyContext,
        fixtureMonkeyOptions.getInstantiatorProcessor()
    );
}

우리는 User Type을 통해 호출하니 User Type에 대한 정보를 담은 ArbitraryBuilder가 반환될 것이다.

이제 위에서 언급한 sample 메서드가 호출되면 어떤일이 발생할까?

public interface ArbitraryBuilder<T> {
    T sample();
}

// 구현체
public final class DefaultArbitraryBuilder<T> implements ArbitraryBuilder<T>, ExperimentalArbitraryBuilder<T> {
    public T sample() {
        return this.resolveArbitrary(this.context).combined();
    }
}

resolverArbitrary를 호출하면, 해당 컨텍스트 정보에 맞게 값을 생성한다. User class 내 각 필드 타입에 따라 값을 생성한다는 의미다.

여기서 호출하는 resolve 메서드에는 ObjectTree 인스턴스를 구성한다. 일부 코드를 가져와서 확인해보자.

public CombinableArbitrary<?> resolve(
        RootProperty rootProperty,
        ArbitraryBuilderContext builderContext
) {
   // ...

   objectTree -> {
       List<ArbitraryManipulator> registeredManipulators =
           monkeyManipulatorFactory.newRegisteredArbitraryManipulators(
               registeredArbitraryBuilders,
               objectTree.getMetadata().getNodesByProperty()
           );

       List<ArbitraryManipulator> joinedManipulators =
           Stream.concat(registeredManipulators.stream(), manipulators.stream())
               .collect(Collectors.toList());

       List<ArbitraryManipulator> optimizedManipulator = manipulatorOptimizer
           .optimize(joinedManipulators)
           .getManipulators();

       for (ArbitraryManipulator manipulator : optimizedManipulator) {
           manipulator.manipulate(objectTree);
       }
       return objectTree.generate();
   }
}

resolve 메서드의 반환 코드 중 일부인데, ArbitraryManipulator 인스턴스를 이용해 ObjectTree 인스턴스를 컨트롤하고, generate 메서드를 호출해 최종 객체를 완성한다.

resolve 메서드에서 반환되는 객체는 CombinableArbitrary 인스턴스이고, combined 메서드를 호출한다.

combined 메서드가 호출되면 생성되었던 ObjectTree 인스턴스를 이용해 User 인스턴스를 생성하고 반환한다. 결과적으로 아래 값이 반환된다.

User {
    id = null;
    firstName = "춝䪼ꧏ";
    lastName = "苖⻵ꪘ쫏▷膄톣㷂䱧";
    active = true;
    emailAddress = "ᛩോ튅⛝櫕ᣵ솙칖谌ｰ퀭埘樅㺏㧑⍭規喲ꫮ൐Ὧ륑삲砎鳃抝Фꞻ᣾⤇崆";
    createdAt = "Mon Sep 16 12:18:00 KST 2024";
}

Fixture Monkey 문자열 난수

문자열의 난수는 어떤 방식으로 생성될까?

로직 분석

예를 들어, User 클래스의 firstName 타입은 문자열(String)이다. 문자열은 MonkeyStringArbitrary 클래스를 통해 처리된다.

public final class MonkeyStringArbitrary implements StringArbitrary {
}

해당 클래스는 StringArbitrary 인터페이스를 구현했는데, 관련된 함수가 jqwik 라이브러리에 의존하기 때문이다.

아래 코드를 보면 잘 확인할 수 있다.

public final class MonkeyStringArbitrary implements StringArbitrary {
    // 문자 생성 담당
    private CharacterArbitrary characterArbitrary = new DefaultCharacterArbitrary();

    // 문자열 생성 메서드 
    @Override
    public RandomGenerator<String> generator(int genSize) {
        long maxUniqueChars = characterArbitrary
              .exhaustive(maxLength())
              .map(ExhaustiveGenerator::maxCount)
              .orElse((long)maxLength());
        return RandomGenerators.strings(
              randomCharacterGenerator(),
              minLength, maxLength(), maxUniqueChars,
              genSize, lengthDistribution,
              newThreadSafeArbitrary(characterArbitrary)
        );
    }
}

generator 메서드 호출을 통해 jqwik 라이브러리로 위임을 했다. DefaultCharacterArbitrary 클래스를 확인해 보면 아래와 같은 코드가 있다.

private Arbitrary<Character> defaultArbitrary() {
   return this.rangeArbitrary('\u0000', '\uffff').filter((c) -> {
      return !isNoncharacter(c) && !isPrivateUseCharacter(c);
   });
}

기본적으로 유니코드를 생성하고 있는데 이 때문에 여러 언어가 포함된 값이 생성된다. 대신, 비문자와 개인용 문자를 제외한다.

이를 사용하는 과정을 MonkeyStringArbitrary 클래스부터 확인해보자.

// MonkeyStringArbitrary
private RandomGenerator<Character> randomCharacterGenerator() {
   RandomGenerator<Character> characterGenerator = effectiveCharacterArbitrary().generator(1, false);
   if (repeatChars > 0) {
      return characterGenerator.injectDuplicates(repeatChars);
   } else {
      return characterGenerator;
   }
}

// DefaultCharacterArbitrary
public RandomGenerator<Character> generator(int genSize) {
   return this.arbitrary().generator(genSize);
}

private Arbitrary<Character> arbitrary() {
   if (this.partsWithSize.isEmpty()) {
      return this.defaultArbitrary();
   } else {
      return this.partsWithSize.size() == 1 ? (Arbitrary)((Tuple.Tuple2)this.partsWithSize.get(0)).get2() : Arbitraries.frequencyOf(this.partsWithSize);
   }
}

이렇게 defaultArbitrary를 호출하여 값을 생성하는 것을 알 수 있다.

여러 테스트 환경 특성 상 중국어 간체라던가 키릴문자가 나오는 상황이 발생하면 안 될 수도 있다. 알파벳 값만 얻고 싶은가?

@Override
public StringArbitrary alpha() {
  this.characterArbitrary = this.characterArbitrary.alpha();
  return this;
}

친절하게도 MonkeyStringArbitrary 구현체에 구현이 되어있다. 알파벳 뿐만 아니라 ascii, numberic, whitespace 등을 사용할 수 있다.

로직 구현

이를 이용해 모든 문자열 필드는 알파벳만으로 구성해 보겠다.

@BeforeEach
void setUp() {
    firstUser = fixtureMonkey.giveMeBuilder(User.class)
            .set("firstName", new MonkeyStringArbitrary().alpha())
            .sample();
}

// 결과
User {
   id = null;
   firstName = "NiGPfLvWoDwxIrhOdnXkyVYCmtRpASM";
   lastName = "彜ॵ䕥殿騍눭≖鿤ᄭ똊暿즹쓨ᷧ⻐ᣡ媻哙떬បଝ䗳";
   active = true;
   emailAddress = null;
   createdAt = "Mon Sep 16 17:07:37 KST 2024";
}

모든 객체를 생성할 때, 한 번에 적용하고 싶다면? 처음 fixtureMonkey 인스턴스를 빌드할 때 register 해주면 된다.

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
      .objectIntrospector(FieldReflectionArbitraryIntrospector.INSTANCE)
      .register(User.class, arbitraryBuilder ->
              arbitraryBuilder.giveMeBuilder(String.class)
                      .set("firstName", new MonkeyStringArbitrary().alpha())
                      .set("lastName", new MonkeyStringArbitrary().alpha())
      )
      .build();

User {
   id = null;
   firstName = "sZfq";
   lastName = "PbAuticMWIXoUJVLhJZdrVRCPzh";
   active = false;
   emailAddress = "";
   createdAt = "Thu Feb 08 00:00:00 KST 2024";
}

한글 문자열 적용(feat. contribute)

PR Link

문자열에 한글만 적용하고 싶다면 어떻게 할까?

문자열 난수 챕터에서 확인했듯이, FixtureMonkey 인스턴스를 빌드하는 과정에서 MonkeyStringArbitrary를 적용할 수 있을 것이다.

로직 분석

한글만 적용해주기 위해서는 일단 alpha 메서드를 확인할 필요가 있다. (한글만 적용해주는 메서드가 없기 때문이다)

@Override
public StringArbitrary alpha() {
   this.characterArbitrary = this.characterArbitrary.alpha();
   return this;
}

public CharacterArbitrary alpha() {
    return this.range('A', 'Z').range('a', 'z');
}

jqwik 라이브러리를 호출한다.

내부에서 range를 알파벳으로 정의해 주는데, 직접 range를 설정할 수 있는 메서드를 지원하지 않을리가 없다고 생각한다.

@Override
public StringArbitrary all() {
    return this.withCharRange(Character.MIN_VALUE, Character.MAX_VALUE);
}

@Override
public StringArbitrary withCharRange(char from, char to) {
   this.characterArbitrary = this.characterArbitrary.range(from, to);
   return this;
}

MonkeyStringArbitrary 클래스 내에 all 메서드를 발견했는데, 해당 메서드에서는 모든 범위를 직접 지정해준다. 운이 좋게도 withCharRange는 public 메서드여서 직접 정의할 수가 있겠다.

어떤 값을 정의하는가?

jqwik library 내의 defaultArbitrary에서 확인했듯이 Unicode로 범위를 지정해줘야 한다. 한글은 AC00부터 D7AF까지이며, 실질적 사용 범위는 D7A3까지이다. (나머지 문자는 정의되지 않음)

그리고 이를 문자로 봤을 때 가부터 힣 까지이다.

직접 정의해 보면,

FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
   .objectIntrospector(FieldReflectionArbitraryIntrospector.INSTANCE)
   .register(User.class, arbitraryBuilder ->
      arbitraryBuilder.giveMeBuilder(String.class)
         .set("firstName", new MonkeyStringArbitrary().withCharRange('가', '힣'))
         .set("lastName", new MonkeyStringArbitrary().withCharRange('가', '힣'))
      )
   .build();

생성된 객체를 확인해 봤을 때 값은 아래와 같다.

User {
   id = null;
   firstName = "짇쇅";
   lastName = "뚼셃룫욻믉묩돚펇뒄냱쨃뮀튣퇿졷쑂졗징욡뎩몁";
   active = true;
   emailAddress = null;
   createdAt = "Wed Feb 07 00:00:00 KST 2024";
}

Contribute

이는 메서드화될 수 있다고 생각하여 FixtureMonkey Repository를 Fork하여 Pull Request를 진행해 둔 상태이다.

MonkeyStringArbitrary

public StringArbitrary korean() {
   this.characterArbitrary = this.characterArbitrary.range('가', '힣');
   return this;
}

그리고 위 메서드를 검증하기 위한 테스트도 작성했다.

MonkeyStringArbitraryTest

StringArbitrary koreanStringArbitrary = new MonkeyStringArbitrary().korean();

@Test
void koreanShouldGenerateOnlyKoreanCharacters() {
   StringArbitrary arbitrary = koreanStringArbitrary.ofMinLength(1).ofMaxLength(10);

   String sample = arbitrary.sample();

   assertTrue(sample.chars().allMatch(ch -> ch >= '가' && ch <= '힣'));
}

샘플 데이터를 추출하여 Unicode 상 한글 범위에 해당하는지 테스트했다.

@Property(tries = 100)
void koreanShouldAlwaysGenerateStringsWithinKoreanCharacterRange(
    @ForAll @Size(min = 1, max = 50) String ignored
) {
   String sample = koreanStringArbitrary.sample();

   assertTrue(sample.chars().allMatch(ch -> ch >= '가' && ch <= '힣'));
}

마찬가지로 여러번 시도하여 항상 한글 범위에 해당하는지 테스트했다.

@Test
void koreanShouldRespectMinAndMaxLength() {
   int minLength = 5;
   int maxLength = 10;
   StringArbitrary arbitrary = koreanStringArbitrary.ofMinLength(minLength).ofMaxLength(maxLength);

   String sample = arbitrary.sample();

   assertTrue(sample.length() >= minLength && sample.length() <= maxLength);
}

그리고 샘플 데이터 생성을 요청한 길이가 올바른지 또한 검증했다.

해당 PR이 통과할지는 불분명하겠지만, 불편함을 편함으로 바꿔주는 FixtureMonkey를 다루며 편리함을 추구하는 시도는 지속할 것이다.

객체 리스트 생성

객체를 하나하나 정의하기에도 지루함이 느껴질 때가 있다.

private User firstUser;
private User secondUser;
private User thirdUser;
private User fourthUser;
private User fifthUser;

@BeforeEach
void setUp() {
  firstUser = fixtureMonkey.giveMeOne(User.class);
  secondUser = fixtureMonkey.giveMeOne(User.class);
  thirdUser = fixtureMonkey.giveMeOne(User.class);
  fourthUser = fixtureMonkey.giveMeOne(User.class);
  fifthUser = fixtureMonkey.giveMeOne(User.class);
}

@Test
void creation() {
   Query query = em.createQuery("select count(u) from User u");
   Long before = (Long) query.getSingleResult();
   List<User> users = List.of(firstUser, secondUser, thirdUser, fourthUser, fifthUser);

   repository.saveAll(users);

   assertEquals(before + 5L, query.getSingleResult());
}

위 예제 코드와 같이 사용할 수도 있겠지만, 여러 개의 객체를 한 번에 생성하고자 하면 어떻게 해야할까?

로직 분석

동작 과정을 살펴보던 중 giveMeOne 메서드에서 호출하던 giveMe 메서드를 보자.

public <T> T giveMeOne(Class<T> type) {
    return this.giveMe((Class)type, 1).get(0);
}

public <T> List<T> giveMe(Class<T> type, int size) {
   return (List)this.giveMe(type).limit((long)size).collect(Collectors.toList());
}

size 값만큼 객체를 생성해주는 것으로 보인다. 마침, public 메서드이니 우리도 사용할 수 있겠다.

로직 구현

private List<User> userList;

@BeforeEach
void setUp() {
    userList = fixtureMonkey.giveMe(User.class, 5);
}

@Test
void creation() {
   Query query = em.createQuery("select count(u) from User u");
   Long before = (Long) query.getSingleResult();

   repository.saveAll(userList);

   assertEquals(before + 5L, query.getSingleResult());
}

giveMe 메서드를 호출하여 5개의 객체 생성을 요청했다.

테스트는 성공했고, Debug mode로 userList를 확인해 보자.

다섯 개의 User 인스턴스가 생성된 것을 확인할 수 있다.

The End

FixtureMonkey를 활용하면 테스트 데이터 생성의 복잡성을 줄이고 테스트 자체에 더 집중할 수 있다. 이는 코드의 품질을 높이고 개발 생산성을 향상시키는 데 큰 도움이 될 것이다. FixtureMonkey와 함께 더 나은 테스트 문화를 만들어나가길 바란다.

추가로, 사실과 다른 내용이 있다면 댓글로 남겨주길 바란다.

TO-DO(memo)

Nullable 테스트를 고려하기(ex. null인 경우 예외, null이 아닌 경우 예외 등)
특정 포맷을 적용하기(ex. email@test.com)
특정 범위만 허용/제외하기(ex. 1-99)

[Consider - The Clean Coder] 테스트 주도 개발

currenjin — Tue, 25 Jun 2024 12:54:36 +0900

밥 아저씨가 생각하는 테스트 주도 개발

TDD의 세 가지 법칙

실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

확신

FitNesse의 코드는 6만 4천 줄인데, 그중 2만 8천 줄은 테스트 코드다.

어떤 부분이라도 바꾸게 되면 별 생각 없이 단위 테스트 코드를 돌리는데, 통과하면 내가 만든 변경이 다른 부분을 망가뜨리지 않았다고 거의 확신할 수 있다.

용기

믿음직한 테스트 묶음이 있으면 변경에 대한 두려움이 모두 사라진다. 나쁜 코드가 보이면 그저 그 자리를 깨끗이 치우면 된다.

문서화

세 가지 법칙에 따라 만든 각 단위 테스트는 코드로 만든 에제이며 시스템을 어떻게 사용해야 하는지 알려준다.

단위 테스트는 문서다. 시스템의 가장 낮은 단계의 설계를 알려준다. 낮은 단계에 대한 문서 중 가장 훌륭한 형태다.

설계

테스트를 먼저 만드는 일은 의존성이 낮은 좋은 설계를 만드는 힘이 된다.

"나는 테스트를 나중에 만들 수 있어요."라는 말은 틀렸다. 사실이 아니며 만들 수 없다. 일이 벌어진 후에 만드는 테스트는 수비다. 먼저 만드는 테스트는 공격이다.

내가 생각하는 테스트 주도 개발

나는 테스트 주도 개발을 좋아한다. 아니, 좋아하다 못해 사랑한다. TDD가 추구하는 방향은 내가 추구하는 방향과 많은 의미에서 맞닿아 있다.

첫 번째로, 고객(유저) 중심적으로 생각할 수 있다는 점이다. TDD는 결과물을 먼저 테스트 코드로 작성하고 이를 충족하기 위해 로직을 채운다. 로직은 딱 테스트를 충족시킬 만큼만 채운다. 다시 테스트를 추가하고 이를 충족시키는 로직을 채우며 사이클을 반복한다.

나는 사용자에게 빠르면서 핵심적인 가치를 전달하고 싶다. 이를 위해서는 정말 필요한 일들만 하는 훈련이 필요하다. TDD는 나에게 이런 훈련을 위한 도구가 된다.

두 번째로, 안정성을 느낄 수 있다는 점이다. 내가 만드는 결과물이 성장해 나가는 과정에서 스텝마다의 테스트를 통해 확신을 갖고 나아간다. 이 확신은 내가 가치를 전달함에 있어서 안정성을 느끼게 해준다.

세 번째로, 커뮤니케이션 리소스가 줄어든다. 효율적으로 커뮤니케이션할 수 있다는 게 더 명확한 것 같다. 테스트 코드를 남겨놓으면 이 테스트 코드는 다른 사람들이 보고 이해할 수 있는 핵심적인 문서가 될 것이다.

중학생이 보고도 이해가 가는 코드를 짜는 것이 목표인 나에게는 테스트 코드라는 문서를 어떻게 하면 가독성을 좋게 만들 수 있을지 고민하게 하며 나를 성장시킨다.

[Consider - The Clean Coder] 미리 읽어두기

currenjin — Sun, 23 Jun 2024 10:39:28 +0900

태도, 원칙, 그리고 행동

내가 바라는 개발자의 태도

우리는 목적을 함께하는 사람이다.

개발자가 할 수 있는 일은 무엇일까? 소프트웨어를 다루는 프로그램을 만들거나, 기존 프로그램을 개선하는 것이 주된 일일 것이다.

작은 조직에서는 서로의 일이 가까이 있기 때문에 목적을 함께하는 느낌이 강하고, 어떤 일을 진행함에 있어서도 서로 노력할 것이다. 하지만 조직의 규모가 커지면 서로의 일을 멀리서 바라보게 되고, 다양한 이해관계가 생기며 그 목적을 인지하기도, 함께한다고 생각하기도 어려워진다.

그러나 나는 조직이 크든 작든 바라보는 목적이 같아야 한다고 생각한다. 개발자는 서로의 다른 목적을 충족시키기 위해 개발하는 것이 아니라, 함께 목적을 이루기 위해 개발하는 것이다. 그 목적에 다가가기 위해 각자가 가장 잘하는 것으로 빠르게 접근해야 한다.

내가 바라는 개발자의 태도는 단 하나다. 누군가의 요청이나 요구사항이 있을 때 이를 서로 다른 목적으로 인지하는 것이 아닌, 함께 목적을 달성하기 위한 일련의 과정으로 바라보는 것.

내가 바라는 개발자의 원칙

우리가 무엇을 하는지에 대한 정확한 인지와 이해가 필요하다.

일을 하다 보면 여러 이해관계와 설명이 얽히면서 처음 개발하고자 했던 것과 다른 것을 개발하는 경우가 생길 수 있다. 이후 이를 뒤엎고 다시 개발하는 비효율적인 리소스 낭비가 발생할 수 있다.

이런 상황을 겪다 보면 원칙을 좋아하지 않지만 최소한의 원칙은 필요하다는 생각이 든다. 원칙을 정할 때에는 모두의 이해와 공감, 그리고 끊임없이 개선할 수 있는 여지가 있어야 한다.

이러한 과정에서 우리는 모두 한 목표를 바라보고, 같은 목적에 다가가고 있다는 느낌을 받아야 한다. 결국 모두가 한 가지 목적을 인지해야 한다는 원칙을 말하고 싶다.

내가 바라는 개발자의 행동

건설적이고 비판적인 토론

우리에게 중요한 것은 고객에게 닿는 '제품'이다. 제품을 개발하는 개발자는 이 제품이 원하는 목적에 도달할 수 있도록 계속해서 완전한 모습으로 다듬어 나가야 한다.

이 과정에서 발생하는 커뮤니케이션은 불가피하다. 토론, 브레인스토밍 등 다양한 형태의 커뮤니케이션이 발생한다.

비판적으로 접근하며, 목적에 호의적인 자세를 유지한다면 우리는 고객에게 닿는 제품을 더욱 완전하게 만들 수 있을 것이다.

나의 현재 모습(태도, 원칙, 행동)은 어떨까?

목적을 제일 중요하게 여기지만, 현재 나의 모습은 내가 바라는 태도와 원칙, 그리고 행동에 다가가기는 아직 멀었다고 생각한다.

나는 아직도 현 상태에 타협을 하고, 가끔은 정해진 것이 바뀌었을 때 분개하기도 한다. 또한, 커뮤니케이션을 하면서 그만 이야기하고 개발하고 싶다는 생각도 든다.

우리가 목적에 더욱 다가가기 위해서는 모두가 그 목적을 인지해야 한다고 생각하지만, 일이 바쁘다는 핑계로 목적에 대한 설명을 늦추기도 한다. 개인적으로 정말 중요하게 생각하는 가치를 뒤로 미루고 있는 것이다.

어떻게 해야 모두가 목적을 완전하게 인지하며, 빠르게 나아갈 수 있을까? 요즘의 내 고민이다.

[개발자 필독] 개발자를 위한 북마크 모음집

currenjin — Thu, 25 Jan 2024 12:30:54 +0900

https://github.com/currenjin/site-for-developers

GitHub - currenjin/site-for-developers: 개발자를 위한 북마크 모음집

개발자를 위한 북마크 모음집. Contribute to currenjin/site-for-developers development by creating an account on GitHub.

github.com

Kotlin + Spring Multi module Template

currenjin — Thu, 11 Jan 2024 12:37:39 +0900

https://github.com/currenjin/kopring-multi-module-template

GitHub - currenjin/kopring-multi-module-template: Kotlin + Spring Multi module Template(Layered Architecture ️)

Kotlin + Spring Multi module Template(Layered Architecture ️) - GitHub - currenjin/kopring-multi-module-template: Kotlin + Spring Multi module Template(Layered Architecture ️)

github.com

Description

Write the project name and introduction.

This is a Kotlin + Spring Multi-module project template based on layered architecture.

Repository Overview

Write the directory structure.

The Kopring multi-moudle template basically has an api, core module based on layered architecture.

API

Controller, Application Layer is included as a package.

Core

Domain, Infrastructure Layer is included as a package.

Getting Started

Write the 'How to run?' and environment.

Version

Java : 21
Gradle : 8.5

Build

$ ./gradlew build

Example

Write simple instructions and examples.

Simple is IT, 누구나 보고 누구나 깨닫는 IT

나는 무엇을 두려워했는가.

도전은 연결된다. — 5년차 소프트웨어 엔지니어편

Spring Bean Lifecycle

Life Cycle

순서

생성자 호출

의존성 주입

@PostConstruct 메서드 실행

afterPropertiesSet() 메서드 실행

@PreDestroy 메서드 실행

destroy() 메서드 실행

앤 드루얀의 코스모스: 가능한 세계들

칼 세이건의 코스모스 - 두 가지 질문

Fixture Monkey를 적용해보자 w/JPA Test

Fixture Monkey를 적용해보자

Problem

Fixture Monkey

Spring Boot JPA

Links

Environment

Domain Model

Test

Creation AS-IS

Dependency & Build object

Creation TO-BE

Fixture Monkey 동작

내부 동작

Fixture Monkey 문자열 난수

로직 분석

로직 구현

한글 문자열 적용(feat. contribute)

로직 분석

어떤 값을 정의하는가?

Contribute

객체 리스트 생성

로직 분석

로직 구현

The End

TO-DO(memo)

[Consider - The Clean Coder] 테스트 주도 개발

밥 아저씨가 생각하는 테스트 주도 개발

TDD의 세 가지 법칙

확신

용기

문서화

설계

내가 생각하는 테스트 주도 개발

[Consider - The Clean Coder] 미리 읽어두기

태도, 원칙, 그리고 행동

내가 바라는 개발자의 태도

내가 바라는 개발자의 원칙

내가 바라는 개발자의 행동

나의 현재 모습(태도, 원칙, 행동)은 어떨까?

[개발자 필독] 개발자를 위한 북마크 모음집

Kotlin + Spring Multi module Template

Description

Repository Overview

API

Core

Getting Started

Version

Build

Example