"프리코스 10일차" 미션 분석과 설계, 단위 테스트와 TDD 공부

📝 오늘의 Todo 리스트 체크

1. "자동차 경주" 미션 분석과 설계
     - 기능 목록 작성 ✅
     - use case 시나리오/다이어그램 설계 ✅
     - MVC 구조 설계 ✅

2. 테코톡 

     - (학습) 단위 테스트와 TDD 공부 ✅

---

목차

• [ 2주 차 미션 "자동차 경주" 분석과 설계 ]
  • 기능 목록과 예외 사항 작성
  • USE CASE 시나리오 및 다이어그램
  • MVC 구조 고민
    • 상수 관리를 Enum으로 하는게 맞을까, Common으로 하는게 맞을까?
    • Model과 Domain이 서로 어떻게 다를까?
  • MVC 구조 설계
  • 확장 가능성 고려하기
• [ 단위 테스트와 TDD]
  
  • 단위 테스트의 개념과 특징
  • 단위 테스트를 적용할 수 있는 방법들 중에 TDD
  • TDD 개념 설명과 장점
  • JUnit5와 AssertJ
• 내일 todo 리스트

---

1. 기능 목록과 예외 사항 작성

이번주 미션이 확실히 1주 차 미션보다 어려워졌다는 것이 오늘 미션 분석과 설계할 때부터 느껴졌다.😭 

계획 짤 때는 오늘 설계만하면 시간이 많이 남을테니 단위테스트 공부  많이 할 수 있겠다 생각한 내가 너무 웃겨...

 

그럼 기능 목록부터 살펴보면 ~

 

누구나 생각할 수 있는 기본적인 예외를 제외하고, 내가 고민하다가 추가한 2가지 예외는 다음과 같다.

1) 입력된 자동차 이름이 최소 2개는 있어야한다: 처음에는 자동차 1대만 입력되도 결국에 그 자동차가 우승할거니까 실행과정에서는 문제가 없다고 판단했다. 하지만 다시 한번 더 미션 이름을 생각해봤을 때 "자동차 경주"? "경주"? "시합"? "경기"?와 같은 개념들을 함께 떠올랐고, 자연스럽게 경쟁하는 최소 2팀 또는 2플레이어를 연상하게 되었다. 그래서 자동차 경주를 하려면 최소 자동차 2대는 입력이 되야된다고 판단했다. 

 

2) 자동차 이름이 숫자로만 구성되면 안된다: 숫자를 이름에서 아예 빼는것을 처음에는 생각했다. 하지만 다시 생각해보니 "Alexsander2세"와 같은 이름도 존재하니까 숫자를 포함한 이름은 허용되지만 숫자로만 구성된 이름은 예외 처리하기로 했다. 숫자로만 구성된 이름을 가진 사람을 본적이 없다.

 

2. USE CASE 시나리오 및 다이어그램

 

유스케이스 시나리오를 기본 이벤트 흐름과 대체 또는 예외 흐름으로 표현했다. 확실히 1주차 미션 기본 흐름 길이와 비교하면 2주차 미션이 난의도가 올라간 것을 체감할 수 있다.😅

 

3. MVC 구조 고민

1주 차 미션 끝나고 다른 사람들의 코드를 리뷰했을 때 다양한 폴더 구조를 볼 수 있었고 다음과 같은 것들이 궁금해졌다.

 

1) 상수 관리를 Enum으로 하는게 맞을까, Common으로 하는게 맞을까?

상수 관리를 누구는 Enum으로 누구는 Common으로 했다. 그들의 정확한 차이점이 궁금해져서 찾아보았다.

Enum도 상수를 관리하고, Common 클래스도 상수를 관리한다. 이 때문에 두 방식이 비슷하게 보일 수 있지만 실제로는 타입 안전성이나 가독성 측면에서 차이가 있다. Common 클래스는 모든 메시지를 한 곳에 모아 관리할 수 있는 편리함을 제공하고, 규모가 커지면 복잡해질 수 있다. 반면 Enum은 특정 메시지 그룹(예: 성공/실패 메시지, 예외 메시지 등)을 더 체계적으로 관리하기 위한 것이다. Enum을 사용하면 타입 안전성을 보장받을 수 있지만 Common 클래스의 상수 문자열은 실수로 잘못된 문자열을 사용할 가능성이 있다. 

요약하자면 

메시지에 의미가 있고, 메시지가 한정적인 경우 Enum을 사용하는게 맞다. 예를 들어, 성공/실패/에러 메시지처럼 특정한 값들의 집합을 정의하는 경우가 있을 수 있다.

여러 종류의 메시지를 한 곳에서 관리하고 싶을 때는 Common 클래스를 사용할 수 있다. 예를 들어, 다양한 곳에서 쓰이는 공통 메시지들이 많은 경우에는 Common 클래스를 사용하는 것이 더 간편할 수 있다.

 

그래서 나는 상수 관리를 Enum을 사용하는 방식으로 결정했다. 예외가 발생했을 때 출력되는 문자열 상수들을 Enum으로 관리하고, 입출력 메시지도 동적으로 변하는 것이 아니라 고정된 메시지임으로 Enum으로 관리하는것이 매우 효과적이라고 판단했다.

 

2) Model과 Domain이 서로 어떻게 다를까?

비즈니스 로직 처리를 Model에서 하는 경우와 Domain에서 관리하는 차이점이 궁금해졌다.

정의에 따르면 MVC 패턴에서 Domain 폴더는 애플리케이션의 핵심 비즈니스 로직을 처리하는 엔터티, 값 객체, 도메인 서비스 같은 클래스들을 담고 있으며 도메인 모델은 외부 의존성 없이 독립적으로 동작해야 한다. 반면, Model 폴더는 데이터베이스와 상호작용하거나 데이터를 전송하기 위한 DTO, 리포지토리와 같은 클래스를 포함하며 데이터의 저장과 표현, 전송을 담당한다.

요약하면 Domain은 비즈니스 규칙에, Model은 데이터 처리에 중점을 둔다. 프리코스 미션들은 비즈니스 로직에 집중되어 있어 Domain 개념이 더 적합하다. 하지만 저는 MVC 패턴에 중점을 두고 프리코스 미션을 수행하고 있으므로 Model을 유지하는 것이 더 적절하다고 판단했다.

 

그래서 추가로 찾아본 자료에 따르면 초기 단계의 단순한 프로젝트에서는 Domain과 Model 폴더를 하나의 Model 폴더로 합쳐 사용하는 것은 문제 없다고 나와있었다. 즉, 비즈니스 로직과 데이터 처리를 단일 Model 폴더로 관리하는 것이 가능하다.

 

이에 따라 나는 프리코스 미션을 위한 나의 MVC 디자인 페턴에서는 비즈니스 로직 처리를 Model로 하기로 결정했다.

 

4. MVC 구조 설계

업데이트된 MVC 구조에 대한 생각과 지식으로 2주 차 미션 MVC 구조를 다음과 같이 설계했다.

이번에도 MVC 구조를 설계할 때 다음과 같은 규칙을 준수했다.
1. TDA(Tell, Don’t Ask) 원칙을 준수하기

2. 단일 책임 원칙(Single Responsibility Principle, SRP) 준수하기

3. 클래스, 메소드, 변수 이름을 축약하지 않기

4. 각 메소드가 "뭐뭐 하기"로 설명 가능하게 설계하기

 

그리고 지난주 미션을 리팩토링하는 과정에서 알게 된 Tell, don't ask 원칙까지 생각하면서 설계했다. 이원칙은 간단히 말하자면 객체가 자신의 상태를 외부에서 물어보는 대신, 필요한 작업을 직접 수행하게 해야 한다는 개념이다. 이를 통해 객체의 자율성을 보장하고, 캡슐화를 유지하여 비즈니스 로직이 객체 내부에서 관리되도록 한다. 이 원칙을 지키기 위해 클래스가 자기의 속성에 대한 직접적인 Getter, Setter 메서드가 없어야한다.

 

4. 확장 가능성 고려하기

그리고 이번 주 차부터 주어진 미션에 대한 기능적인 요구 외에, 앞으로 이 애플리케이션에서 확장으로 추가 할 수 있는 로직을 고려하면서 구현하기로 했다. 이번 "자동차 경주" 애플리케이션에서 다음과 같은 2가지 확장 기능을 생각해봤다.

 

5. 단위 테스트의 개념과 특징

예전부터 궁금했던 단위 테스트 개념을 이제 제대로 공부해본다.😅

단위 테스트는 하나의 모듈을 독립적으로 테스트하는 가장 작은 단위의 테스트이다. 모듈은 보통 애플리케이션의 메소드나 클래스와 같은 작은 기능 단위로 이해할 수 있다. 단위 테스트는 개별 기능이 의도한 대로 작동하는지 검증하는 것이 목적을 가지고 있으며 이를 통해 개발자는 시스템의 작은 부분이 제대로 동작하는지 확인할 수 있다. 단위 테스트는 독립적으로 수행되기 때문에 빠르고 간단하게 실행될 수 있는 특징이 있고, 코드의 안정성과 유지보수성을 높이기 위한 필수적인 도구이다.

 

6. 단위 테스트를 적용할 수 있는 방법들 중에 TDD

단위 테스트를 효과적으로 적용하는 방법 중 하나가 TDD(Test-Driven Development)이다. TDD는 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 즉, TDD는 테스트 코드를 먼저 작성하고, 그 테스트를 통과할 수 있도록 실제 코드를 구현하는 개발 방법론이다.

 

7. TDD 개념 설명과 장점

TDD는 "Red, Green, Refactor"의 세 단계를 따른다. 먼저 실패하는 테스트(Red)를 작성하고, 그 테스트를 통과할 수 있도록 최소한의 코드를 작성(Green)한다. 그 후, 테스트가 통과된 코드를 리팩토링(Refactor)하여 중복을 제거하고 코드의 가독성과 효율성을 높인다. TDD의 가장 큰 장점은 요구사항을 명확하게 정의하고, 테스트를 통해 결함을 방지할 수 있다는 점이다. 또한, 코드 리팩토링을 자유롭게 할 수 있어, 코드 품질을 지속적으로 유지하고 개선할 수 있다. 테스트 코드가 존재하기 때문에 리팩토링 후에도 기능이 정상적으로 작동하는지를 쉽게 확인할 수 있는 장점이 있다.

 

8. JUnit5와 AssertJ

오늘을 JUnit5와 AssertJ의 간단한 개념만 알아보았다.

 

JUnit5는 자바에서 단위 테스트를 작성할 때 가장 널리 사용되는 테스트 프레임워크이다. JUnit5는 유연한 구조와 다양한 어노테이션을 제공하여 테스트 작성과 관리가 편리하다. 특히, 테스트 케이스를 작성할 때 테스트의 가독성을 높여주고, 간단하게 테스트 결과를 확인할 수 있게 해주는 도구이다.

 

AssertJ는 JUnit5와 함께 사용하는 어서션 라이브러리로, 더 직관적이고 읽기 쉬운 테스트 코드를 작성하는 데 도움을 준다. AssertJ는 풍부한 어서션 메소드를 제공하여 테스트 결과에 대한 검증을 쉽게 할 수 있다. 이를 통해 개발자는 더욱 명확하고 이해하기 쉬운 테스트 코드를 작성할 수 있다.

 

9. 내일 todo 리스트

• (학습) JUnit5와 AssertJ 어노테이션과 함수 알아보기 🔳
• 2주 차 미션 코드 구현 🔳

 

참고자료

[Spring] 협업을 위한 에러 코드 Enum으로 관리하기

 

Java Enum 활용기 | 우아한형제들 기술블로그

 

[TDD] 단위 테스트(Unit Test) 작성의 필요성 (1/3)

 

[Java] TDD 어떻게 하는가?

 

[Java] JUnit5 과 AssertJ 로 단위 테스트 작성하기

 

끝.