2.4.4.6 문자열 계산기에 음수를 전달하는 경우 RuntimeException 예외를 throw 한다

HINT)
구글에서 "junit4 expected exception" 으로 검색해 해결책을 찾는다.

 

public class StringCalculatorTest {

    ...

    @Test(expected = RuntimeException.class)
    public void add_ne() throws Exception {
        assertEquals(6, cal.add("//;\n1;2;3"));
    }

}

JUnit에서 기대하는 결과 값이 예외(Exception)인 경우 @Test 어노테이션의 expected 속성에 기대하는 Exception 클래스를 전달할 수 있다.

 

import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class StringCalculator {

    public int add(String text) {
        if (isBlank(text)) {
            return 0;
        }
        return sum(toInts(split(text)));
    }

    private boolean isBlank(String text) {
        return text == null || text.isEmpty();
    }

    private String[] split(String text) {
        Matcher m = Pattern.compile("//(.)\n(.*)").matcher(text);
        if (m.find()) {
            String customDelimeter = m.group(1);
            return m.group(2).split(customDelimeter);
        }
        return text.split(",|:");
    }

    private int[] toInts(String[] values) {
        int numbers[] = new int[values.length];
        for (int i = 0; i < values.length; i++) {
            numbers[i] = toPositive(values[i]);
        }
        return numbers;
    }

    private int toPositive(String value) {
        int number = Integer.parseInt(value);
        if (number < 0) {
            throw new RuntimeException();
        }
        return number;
    }

    private int sum(int[] numbers) {
        int sum = 0;
        for (int number : numbers) {
            sum += number;
        }
        return sum;
    }

}

 

마지막까지 극단적으로 메서드를 분리했다. 처음 요구사항에서 메서드를 분리했다면 메서드명을 toInt()로 했을 가능성이 높다. 그런데 요구사항이 추가되면서 toPositive()가 더 적합하다는 생각이 들었다. 이와 같이 요구사항이 추가되면서 메서드명, 변수명을 변경하는 것 또한 중요한 리팩토링이다.

지금까지 문자열 계산기의 모든 요구사항에 대한 구현 작업을 완료했다. 각자 개발한 소스코드와의 차이점과 구현 과정을 비교해보면 학습에 도움이 된다. 좋은 점은 배우고, 나쁜 점은 버리면 된다.

 

마지막으로 지금까지 과정을 정리한다.

 

· 각 단계의 개발 과정은 구현 => 테스트를 통해 결과 확인 => 리팩토링으로 진행했다. 이 단계에서 개발자들이 소홀히 하는 부분이 리팩토링인데, 깔끔하고 읽기 좋은 코드를 구현하기 위한 개발자가 갖추어야 할 중요한 역량인 만큼 꾸준히 연습한다. 다시는 건드리고 싶지 않은 코드가 아닌 계속해서 관심을 갖고 리팩토링하고 싶은 코드로 만들자.

 

· 추가 요구사항 3가지 원칙을 지키도록 노력한다. 리팩토링을 할 때 가장 막막한 점 중의 하나가 리팩토링할 부분을 찾는 것이다. 리팩토링할 부분을 찾기 힘들 때 이 3가지 원칙을 생각하면서 찾는다면 약간의 힌트를 얻을 수 있다.

 

· 리팩토링을 극단적으로 진행했다. 이 같은 리팩토링 연습을 할 수 있었던 것은 테스트 코드가 있었기 때문이다. 리팩토링을 통해 프로덕션 코드를 변경하더라도 테스트 코드를 통해 바로 검증할 수 있기 때문에 부담없이 연습할 수 있었다. 현장에서 프로젝트를 진행할 떄도 중요하다. 테스트 코드가 없고, 테스트를 수동으로 해야 하는 상황이라면 리팩토링에 대한 부담이 생겨 꺼려진다. 따라서 리팩토링을 통해 소스코드를 개선하고 싶다면 테스트 코드가 뒷받침 되어야 한다. 테스트와 리팩토링은 분리할 수 없는 동반자 관계이므로 같이 연습해야 한다.

참고도서 : https://roadbook.co.kr/169

[신간안내] 자바 웹 프로그래밍 Next Step