[이동훈] 1차시 미션 제출합니다. #106

dh2906 · 2025-07-31T08:53:45Z

겨울 방학때 초록 스터디를 진행하며 머지된게 있다보니 문제 해결하고 겸사겸사 깃 공부하는데 시간이 꽤 걸린거 같네요..
깃 열심히 공부해야겠다는 생각이 듭니다..

아래는 미션을 진행하면서 생긴 궁금증을 질문으로 남겼습니다!

단위 테스트는 같은 기능에 대해서도 다양한 케이스를 각 메소드로 분할하여 작성하는 것이 맞나요?
- 예를 들어 문자열 계산기에서 문자열을 정수로 변환하는 과정에서 음수거나 문자열이라면 예외를 발생하는데,
  음수인 케이스와 문자열인 케이스를 각각의 메소드로 분리하는 것이 맞는지 궁금합니다.
- 웬만하면 모두 나누는 것이 단위 테스트의 정의에 합하다 생각은 하는데 맞을까요??
베스트 케이스에 대해서 값을 주입할 때는 보통 여러 형태의 값을 넘겨주는 편인가요?
- ex) 사칙연산 계산기 테스트에서 덧셈으로 인자를 (1, 2) 만 넘겨주는 지, 더 다양하게 (3, 4), (100, 200) 등 여러 값을 추가로 테스트하는 지 궁금합니다.
테스트 코드를 작성해보니 대부분 코드가 비슷하거나 중복도 꽤 존재하는데, 비즈니스 로직과 다르게 테스트 코드는 이러한
부분은 어느정도 감수하고 넘어가도 될까요?

dldb-chamchi · 2025-07-31T11:54:46Z

1차시 수고하셨습니다! 궁금증에 대해서 저의 의견도 남겨보겠습니다!

저 또한 동훈님처럼 진행하였습니다. 단위 테스트라는 것이 어떤 기능에 대해서 가장 작은 단위의 테스트인것이니 맞다고 생각합니다.
저는 일단 여러 값을 테스트 하는 형식으로 진행하였습니다. 오버플로우 같은 특수한 경우가 아니라면 다 같은 동작을 할테니 필요가 없다고 생각될수도 있지만 다양한 추가 테스트를 넣는다고 해서 나쁠 건 없다고 생각하였습니다!
이거는 1차시 미션이 굉장히 작은 규모라서 그런 것 같기도 합니다! 이 부분에 대해서는 저도 잘 모르겠네요... 👀

dldb-chamchi · 2025-07-31T11:58:53Z

src/main/java/domain/StringCalculator.java

+    public static final String EMPTY_STRING = "문자열이 비어있습니다.";
+    public static final String CUSTOM_DELIMITER_NOT_FOUND = "커스텀 구분자를 찾을 수 없습니다.";
+    public static final String NEGATIVE_NUMBER_NOT_ALLOWED = "음수는 처리할 수 없습니다.";
+    public static final String INVALID_STRING = "문자열은 처리할 수 없습니다.";


오! 이런식으로 에러메세지를 관리하니 아주 좋네요. 한수 배워갑니다 ㅎㅎ

dldb-chamchi · 2025-07-31T12:01:14Z

src/main/java/domain/Calculator.java

+        if (num2 == 0)
+            throw new ArithmeticException(DIVIDE_BY_ZERO);


dldb-chamchi · 2025-07-31T12:05:29Z

src/main/java/domain/StringCalculator.java

+    public int calculate(String str) {
+        if (str == null || str.isBlank()) {
+            throw new RuntimeException(EMPTY_STRING);
+        }


계산기 구현 요구사항에는
예: “” => 0
이런 식으로 되어있는데 이 로직이면 요구사항과 맞지 않아 보입니다!

오 이건 제가 놓친 사항이네요!
알려주셔서 감사합니다!!

dldb-chamchi · 2025-07-31T12:07:18Z

src/test/java/StringCalculatorTest.java

+    @ValueSource(strings = {
+            "1,2,3:4",
+            "1 , 2: 3,4 "
+    })


이런 어노테이션도 있었군요!

어노테이션을 통해 테스트 메소드 파라미터에 값을 주입해줄 수 있습니다!

위와 비슷한 어노테이션이 많으니 찾아보시면 도움 되실 것 같아요!!

dradnats1012

1주차 미션 고생하셨습니다
남겨주신 궁금증에 대해 제 생각을 남길게요 😄

예외 케이스를 각각의 테스트 메서드로 분리하는 것이 맞나요?

저는 각각의 테스트 메서드로 분리하는 것이 맞다고 생각합니다. 예외 케이스별로 다 다른 상황이라고 생각하면 단위 테스트 의 역할에 부합한다고 생각합니다.

베스트 케이스에 대해서 값을 주입할 때는 보통 여러 형태의 값을 넘겨주는 편인가요?

여러 형태의 값을 넘겨주되 저는 보통 최대 3개까지 넘겨주는것을 선호합니다. 베스트 케이스인 만큼 3개를 초과하는 케이스의 경우 되려 코드가 지저분해질 수 있다고 생각해서 3개까지만 넣는 편입니다. 다만 이때 경계값을 위주로 테스트하고 있습니다.

테스트 코드를 작성해보니 대부분 코드가 비슷하거나 중복도 꽤 존재하는데, 비즈니스 로직과 다르게 테스트 코드는 이러한 부분은 어느정도 감수하고 넘어가도 될까요?

테스트 코드에서는 어느정도의 중복은 허용해도 된다고 생각합니다. 중복이 발생하는 부분은 보통 비슷한 로직에서 발생할것 같은데 비슷한 로직인만큼 중복 코드가 어느정도는 발생할 수밖에 없다고 생각합니다.

다른 분들의 의견과는 다를 수 있는 저의 의견이라 생각해서 동훈님만의 기준을 잡아보는것도 좋을것 같습니당

dradnats1012 · 2025-08-01T07:41:32Z

src/main/java/domain/Calculator.java

+
+public class Calculator {
+
+    public static final String DIVIDE_BY_ZERO = "0으로 나눌 수 없습니다.";


에러 메시지를 static final 로 선언하면 어떤 장점이 있을까요?

private 으로 안하신 이유가 있나요?

static 선언으로 인해 객체의 생성 없이 사용 가능해지며, 외부 클래스인 테스트 클래스에서도 사용 가능합니다. final 선언을 통해 값의 불변성을 보장하여 런타임 중 변경될 수 없음을 나타낼 수 있습니다.

위에서 말씀드린대로 테스트 클래스에서도 사용가능 해야 하므로 public으로 선언했습니다. 그러나 해당 부분은 원래 enum을 통해 관리 하려고 했으나 ErrorMessage.DIVIDE_BY_ZERO.getMessage() 와 같이 코드가 길어져서 enum으로 관리하는 것은 잠시 포기했습니다. enum을 사용하는게 맞는 방식인거 같아 고민 해보고 리팩토링 진행해 보겠습니다!

dradnats1012 · 2025-08-01T07:46:00Z

src/main/java/domain/Calculator.java

+    public static final String DIVIDE_BY_ZERO = "0으로 나눌 수 없습니다.";
+
+    public int add(int num1, int num2) {
+        return Math.addExact(num1, num2);


~~Exact() 메서드는 어떤 장점이 있나요?
일반 연산자(+, - 등) 과 어떤 차이점이 있나요?

대표적인 예로 addExact는 비트 연산을 통해 int 타입인 두 수의 합이 int형의 저장 가능 범위를 벗어난다면 예외를 발생시켜주고 있습니다.
일반적인 연산자를 사용한다면 오버플로우 발생 시 부호 비트가 값의 크기를 나타내기 위한 비트로 사용되서 결과 값이 예상치 못한 값으로 나올 수 있습니다.

dradnats1012 · 2025-08-01T07:48:02Z

src/main/java/domain/StringCalculator.java

+                .toList();
+    }
+
+    public int parseTokenToInt(String token) {


내부에서만 사용하는 메서드같아서 private 으로 선언해도 될 것 같아요!

아! 이걸 놓치고 있었네요!
수정해두겠습니다

dradnats1012 · 2025-08-01T07:50:56Z

src/test/java/CalculatorTest.java

다양한 상황에 대한 예외 테스트까지 잘 작성해주셨네요 👍

dradnats1012 · 2025-08-01T07:51:09Z

src/test/java/StringCalculatorTest.java


 public class StringCalculatorTest {
+
+    private final StringCalculator stringCalculator = new StringCalculator();
+
    @ParameterizedTest


이건 어떤 역할을 하는건가요?

@ParameterizedTest는 값을 외부에서 주입받는 테스트 임을 명시합니다.
@valuesource, @nullsource 등 다양한 어노테이션을 통해 메소드 파라미터에 값을 주입할 수 있으며 이를 통해 하나의 테스트 메소드에 여러 형태의 값에 대한 반복적인 테스트할 수 있습니다.

혹시 문자열 계산기를 주입하는 부분을 말씀하신거라면 문자열 계산기의 테스트를 위해 필드에서 객체를 생성했습니다.
혹은 @beforeach 를 통해 매번 테스트 메소드를 시작하기 전 초기화 작업을해줄 수도 있는데 여기서 주입을 하는 경우도 있습니다.

dradnats1012 · 2025-08-01T08:04:30Z

src/test/java/StringCalculatorTest.java

-    @DisplayName("공백을 줬을 경우 테스트")
-    public void testEmptyValue(String value) {
-        assertThat(StringCalculator.calculate(value)).isEqualTo(0);
+    @CsvSource({


신기한 어노테이션이 많네요! 😄

dradnats1012 · 2025-08-01T08:06:18Z

src/test/java/StringCalculatorTest.java

파싱에 대한 검증도 하시고 꼼꼼한 테스트 좋아요 👍

dh2906 · 2025-08-01T11:19:28Z

1주차 미션 고생하셨습니다 남겨주신 궁금증에 대해 제 생각을 남길게요 😄

예외 케이스를 각각의 테스트 메서드로 분리하는 것이 맞나요?

저는 각각의 테스트 메서드로 분리하는 것이 맞다고 생각합니다. 예외 케이스별로 다 다른 상황이라고 생각하면 단위 테스트 의 역할에 부합한다고 생각합니다.

베스트 케이스에 대해서 값을 주입할 때는 보통 여러 형태의 값을 넘겨주는 편인가요?

여러 형태의 값을 넘겨주되 저는 보통 최대 3개까지 넘겨주는것을 선호합니다. 베스트 케이스인 만큼 3개를 초과하는 케이스의 경우 되려 코드가 지저분해질 수 있다고 생각해서 3개까지만 넣는 편입니다. 다만 이때 경계값을 위주로 테스트하고 있습니다.

테스트 코드를 작성해보니 대부분 코드가 비슷하거나 중복도 꽤 존재하는데, 비즈니스 로직과 다르게 테스트 코드는 이러한 부분은 어느정도 감수하고 넘어가도 될까요?

테스트 코드에서는 어느정도의 중복은 허용해도 된다고 생각합니다. 중복이 발생하는 부분은 보통 비슷한 로직에서 발생할것 같은데 비슷한 로직인만큼 중복 코드가 어느정도는 발생할 수밖에 없다고 생각합니다.

다른 분들의 의견과는 다를 수 있는 저의 의견이라 생각해서 동훈님만의 기준을 잡아보는것도 좋을것 같습니당

좋은 의견 감사합니다!! 덕분에 고민되는 부분에 대한 방향성을 잡을 수 있을 것 같아요!

dh2906 added 19 commits July 31, 2025 18:15

feat. 사칙연산 계산기 구현

4ee4ba1

feat. 0으로 나누는 경우 예외 발생

54afa40

fix. 연산 후 int 범위를 벗어나면 예외 발생하도록 수정

06502aa

feat. 누락된 메소드 접근 제어자 추가

faa2f88

feat. 사칙연산 단위 테스트 추가

6aaeab5

fix. 0으로 나눌 경우 발생하는 예외 종류 수정

eae23cd

feat. 사칙연산 예외 발생 단위 테스트 추가

0b0bd61

feat. 문자열 계산기 구현

4a76f60

feat. 문자열 계산기 테스트 추가

4b08af2

build. AssertJ 의존성 추가

11d80e0

refactor. 사칙연산 계산기 테스트 코드 JUnit -> AssertJ로 리팩토링

682929a

fix. 문자열이 비어있는지 검증하기 전 커스텀 구분자 파싱으로 발생하는 문제 해결

65e7e2c

refactor. 문자열 계산기 테스트 코드 JUnit -> AssertJ로 리팩토링

98b0f3f

refactor. 에러 메시지를 하드 코딩 방식에서 상수 변수로 분리

2394319

refactor. 에러 메시지 포함 검증 시 상수 변수 활용

6546a24

style. 개행 컨벤션 적용

3357666

refactor. 메소드 책임 분할

6e1cc54

fix. 단어 철자 오타 수정

015db6f

fix. 메소드 명 수정

98575d9

dh2906 force-pushed the main branch from a24b6f5 to 98575d9 Compare July 31, 2025 09:22

dldb-chamchi reviewed Jul 31, 2025

View reviewed changes

dradnats1012 reviewed Aug 1, 2025

View reviewed changes

dh2906 closed this Aug 1, 2025

dh2906 reopened this Aug 1, 2025

dh2906 added 4 commits August 2, 2025 09:50

chore. 이전에 구현한 계산기 클래스 삭제

32da58d

fix. 공백 문자열이 들어온 경우 계산 결과 0 반환하도록 수정

fa35922

fix. 문자열로 공백이 들어온 경우 테스트 분할

f7824c7

feat. 에러 메세지 집합 클래스 생성

640f52e

dh2906 added 5 commits August 2, 2025 12:17

refactor. ErrorMessage 상수 사용하도록 변경

e71b3db

refactor. 구분자 정규 표현식 필드 변수 -> 메소드 지역 변수로 수정

859680d

refactor. 문자열 유틸 클래스로 분할

b2a779c

refactor. 유틸 테스트 클래스 분할

d8d8ecc

fix. 잘못된 에러 메시지 반환하는 문제 수정

a5edf2c

		if (num2 == 0)
		throw new ArithmeticException(DIVIDE_BY_ZERO);


		public class Calculator {

		public static final String DIVIDE_BY_ZERO = "0으로 나눌 수 없습니다.";

[이동훈] 1차시 미션 제출합니다. #106

Are you sure you want to change the base?

[이동훈] 1차시 미션 제출합니다. #106

Uh oh!

Conversation

dh2906 commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dldb-chamchi commented Jul 31, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dradnats1012 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dh2906 commented Aug 1, 2025

Uh oh!

Uh oh!

dh2906 commented Jul 31, 2025 •

edited

Loading