Go에 대해서 아예 무지한 상태로 해당 책을 접하게되었다. 평소 다른 언어를 찍먹해보고 싶은 욕구가 가득하던 찰나에 서평의 기회가 찾아와서 책을 간단히 리뷰해본다. 항상 어떤 새로운 언어를 배울 때는 그 언어가 어떤 목적을 가지고 탄생했는지가 늘 궁금해진다. 나뿐만 아니라 다른 사람들도 똑같지 않을까하는 생각에 1장만 간단하게 요약해려고한다. 😃 Go가 탄생한 이유 Go의 탄생이유는 Go at Google에서 확인할 수 있고 개발 배경은 'Why did you create a new language?'에 있다. 2007년 구글이 개발한 프로그래밍 언어인 Go는 당시 구글이 겪던 아래의 문제들을 해결하기위해 탄생했다. 수십 분, 수 시간이 걸리는 빌드 동일한 내용의 표현 방법이 프로그래머마다 달라서 생기는..
2022년 (처음이자) 새롭게 입사하게 된 맘편한세상(= 맘시터) 개발팀은 매주 1회 사내 스터디를 진행하고 있다. 자율적인 참여이지만, 필참이라는 마인드로 시간이 되는 선에서는 모두 참여하려고 한다. 내가 합류한 시점에는 클린 아키텍처 책 스터디가 막 끝난 상황이었고, 새로운 도서를 선정하게 됐다. 때마침 최근에 읽고있던 '오브젝트'도 희망 서적 중 하나로 언급이되었지만, 최근 SNS상의 많은 개발자분들이 책 구성이 좋다고 언급하는 Unit Testing 책이 선정되었다! 관심이 없지는 않던터라 ( 테스트는 항상 고민해야하는 녀석이기에.. ) 기쁜 마음으로 도서를 구매하였다! 단위 테스트는 단순히 테스트를 작성하는 것보다 더 큰 범주이다. 단위 테스트에 시간을 투자할 때는 항상 최대한 이..
배열이나 리스트에서 원소를 꺼낼 때 ordinal 메서드로 인덱스를 얻는 코드가 있다. 예를들어 다음과 같이 식물을 간단히 나타낸 다음 클래스를 보자 class Plant { enum LifeCycle { ANIMAL, PERENNIAL, BIENNIAL } final String name; final LifeCycle lifeCycle; Plant(String name, LifeCycle lifeCycle) { this.name = name; this.lifeCycle = lifeCycle; } @Override public String toString() { return name; } }정원에 심은 식물들을 배열 하나로 관리하고, 이들을 생애주기별로 묶어보자. 생애주기별로 총 3개의 집합을 만들고 정..
대부분의 열거 타입 상수는 자연스럽게 하나의 정숫값에 대응된다. 그리고 모든 열거 타입은 해당 상수가 그 열거 타입에서 몇 번째 위치인지를 반환하는 ordinal이라는 메서드를 제공한다. 이런 이유로 열거 타입 상수와 연결된 정숫값이 필요하면 ordinal 메서드를 이용하고 싶은 유혹에 빠진다. 다음 코드는 합주단의 종류를 연주자가 1명인 솔로(solo)부터 10명인 디텍트(dectet)까지 정의한 열거 타입이다. public enum Ensemble { SOLO, DUET, TRIO, QUARTET, QUINTET, SEXTET, SEPTET, OCTET, NONET, DECTET; public int numberOfMusicians() { return ordinal() + 1; } } 동작은 하지만 ..
열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 허용하지 않는 타입이다. 자바에서 열거 타입을 지원하기 전에는 정수, 상수를 한 묶음 선언해서 사용하곤 했다. 정수 열거 패턴(int enum pattern) 기법에는 단점이 많다. 타입 안전을 보장할 방법이 없으며 표현력도 좋지 않다. 정수 열거 패턴을 사용한 프로그램은 깨지기 쉽다. 평범한 상수를 나열한 것뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 따라서 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일해야 한다. 다시 컴파일하지 않은 클라이언트는 실행이 되더라도 엉뚱하게 동작할 것이다. 정수 상수는 문자열로 출력하기가 다소 까다롭다. 그 값을 출력하거나 디버거로 살펴보면 단지 숫자로만 보여서 별 도움이 안된다. 같..
개발서적
[서평] - Go 언어로 배우는 웹 애플리케이션 개발
로ᄏｌ2024. 2. 11. 01:51
728x90
Go에 대해서 아예 무지한 상태로 해당 책을 접하게되었다. 평소 다른 언어를 찍먹해보고 싶은 욕구가 가득하던 찰나에 서평의 기회가 찾아와서 책을 간단히 리뷰해본다.
항상 어떤 새로운 언어를 배울 때는 그 언어가 어떤 목적을 가지고 탄생했는지가 늘 궁금해진다. 나뿐만 아니라 다른 사람들도 똑같지 않을까하는 생각에 1장만 간단하게 요약해려고한다. 😃
장표들을 쭉 훑어보면 대략적으로 이 책이 어떤 정보들을 제공하는 것인지 알 수 있을 것이다. Go 언어의 문법이나 기초를 알려주는 책은 아니기 때문에 Go를 완전 처음 접해보는 분이라면 적절한 수준의 책은 아닐거라고 생각되지만 Go의 기본 문법을 다뤄봤고 웹 애플리케이션을 만들어봤다면 궁금해할만한 내용들을 Go 언어로 어떻게 구현하는지를 알려주는 책이다.
Go 언어를 생전 처음 보는거다보니 이 책을 읽으면서도 잘 이해하지 못한 부분들이 많았고 웹 애플리케이션을 개발할 때, 필요한 여러가지 처리들이 있는데 각 처리를 어떻게해야하지? 하고 고민할 때, Go는 이렇게 구현하는구나? 와 같은 방향 가이드를 알려주는 책이다. Go에서는 이런 느낌 식으로 이런 처리를 하는구나?, 이런 기능도 제공하는구나? 와 같이 흥미롭게 책을 읽었다.
또한 Go는 객체지향 프로그래밍이 가능한지에 대한 Chap6의 내용도 흥미로웠다. (YES이면서 NO이기도 하다는 애매한 공식문서의 답변) 객체지향의 대표적인 특징인 캡슐화, 다형성, 상속 중 다형성을 지원하지 않기 때문이다. (일부만 지원)
Go에서는 상속을 표현하기위해서 embedded 를 사용하는 방식을 소개하기도하지만 이는 완전히 상속을 대체할 수 없다. embedded의 개념을 딱 보면서 상속보다는 조합(?)의 개념이 아닐까 싶었는데 책에서도 역시나 이 개념은 composition(= 조합), mixin 과 같은 개념에 더 가깝다고 동일한 이야기를 하고있다. (괜히 뿌듯 😙)
이 외에도 에러 처리는 어떻게 할 것인지 DIP(= 의존성 역전 원칙), 환경 변수 적용 방법, 미들웨어 패턴 등등 혼자서 맨땅에 헤딩하며 공부하기에는 많은 시간과 노력이 소모될 수 있는 내용들에 대해서 전반적인 가이드를 해주고있다. 이 책에 나온 내용들을 숙지하면 모르는 내용을 찾기위해서 구글링하는 시간을 절약하는데 큰 도움이 될 것 같다.
Go 문법에 대해서 어느정도 숙지되어있고 웹 애플리케이션을 개발에 도전하고있는 분이라면 이 책을 읽음으로인해 많은 시간을 절약할 수 있을 것으로 기대된다.
이런 독자들에게 이 책을 추천한다.
Go 문법에 익숙하고 Go로 웹 애플리케이션 개발에 도전하려는 사람
이미 Go로 웹 애플리케이션을 개발하는 중이고 웹 애플리케이션에서 필요한 여러 처리들을 Go에서는 어떻게 해야하는지 잘 모르는 사람
2022년 (처음이자) 새롭게 입사하게 된 맘편한세상(= 맘시터) 개발팀은 매주 1회 사내 스터디를 진행하고 있다. 자율적인 참여이지만, 필참이라는 마인드로 시간이 되는 선에서는 모두 참여하려고 한다. 내가 합류한 시점에는 클린 아키텍처 책 스터디가 막 끝난 상황이었고, 새로운 도서를 선정하게 됐다. 때마침 최근에 읽고있던 '오브젝트'도 희망 서적 중 하나로 언급이되었지만, 최근 SNS상의 많은 개발자분들이 책 구성이 좋다고 언급하는 Unit Testing 책이 선정되었다! 관심이 없지는 않던터라 (
테스트는 항상 고민해야하는 녀석이기에..
) 기쁜 마음으로 도서를 구매하였다!
단위 테스트는 단순히 테스트를 작성하는 것보다 더 큰 범주이다. 단위 테스트에 시간을 투자할 때는 항상 최대한 이득을 얻도록 노력해야하고 테스트에 드는 노력을 가능한 한 줄이고 그에 따르는 이득을 최대화해야 한다. 두 가지를 모두 달성하는 것은 쉽지않다. 이러한 두 균형을 달성한 프로젝트는 무난하게 성장하고 유지 보수가 많이 필요하지 않으며 끊임없이 변화하는 고객의 요구에 신속히 대응할 수 있는 프로젝트다. 반면에 그렇지 못한 프로젝트는 노력을 많이 들이고 단위 테스트를 매우 많이 작성하더라도 많은 버그와 유지비로 프로젝트 진행이 느려지게 된다. 이런 차이는 다양한 단위 테스트 기술 간의 차이 때문이다. 일부는 훌륭한 결과를 만들고 소프트웨어 품질을 지키는데 도움이 된다. 하지만 그렇지 않은 경우도 있는데, 일반적으로 그다지 도움이 되지도 않을뿐더러 자주 고장나고 유지보수가 많이 필요하다.
이 책을 통해서 어떤 단위 테스트 기술이 좋은지를 구별하는 데 도움을 받을 수 있고 테스트에 대한 비용 편익 분석(cost-benefit analysis) 방법을 배우고 특정 상황에서 적절한 테스트 기술을 적용할 수 있을 것이다. 또한 공통적인 안티 패턴(처음에는 괜찮은 것 같지만 미래에 문제를 야기하는 패턴)을 피하는 방법도 배운다.
단위 테스트 현황
이제는 대부분 회사에서 단위 테스트는 필수로 간주될 정도로 당연한 것이다. 대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다. 단위 테스트를 적용해야 하는지는 더 이상의 논쟁거리가 아니다. 한번 작성하고 버리는 프로젝트가 아니라면 단위 테스트는 늘 적용해야한다.
모든 새로운 기술과 마찬가지로 단위 테스트도 계속 발전하고 있다. 논쟁은 단위 테스트를 작성해야 하는가?에서 좋은 단위 테스트를 작성하는 것은 어떤 의미인가?로 바뀌었다. 많은 프로젝트에는 자동화된 테스트가 있으며 심지어 많은 테스트가 실행된다. 그러나 테스트를 해도 개발자들이 원하는 결과를 얻지 못하는 경우가 많다. 프로젝트에는 많은 노력이 필요하다. 새로운 기능을 구현하려면 시간이 많이 들고, 이미 구현된 기능에는 새로운 버그가 지속적으로 나타난다. 도움이 될 것이라 생각한 단위 테스트는 이러한 상황에 전혀 도움이 되지 않고 오히려 상황을 악화시킬 수도 있다.
이는 제대로 작동하지 않는 단위 테스트의 결과다. 좋은 테스트와 좋지 않은 테스트의 차이는 취향이나 개인적인 선호도의 문제가 아니라 현재 작업 중인 중대한 프로젝트의 성패를 가르는 문제다.
어떤 것이 단위 테스트를 좋게 만드는지에 대한 논쟁은 매우 중요하다. 하지만 오늘날 소프트웨어 개발 업계에서 많이 논의되지는 않는다. 기본적인 단위 테스트의 기본적인 내용의 학습에서 그치는 것이 아니라 노력 대비 최대의 이익을 끌어내는 방식으로 단위 테스트를 수행하는 것이다. 이 시점에 도달하면, 대부분의 책은 다음 단계로 가는 방법을 독자들에게 맡기지만, 이 책은 그 다음 단계로 안내한다. 이상적인 단위 테스트에 대해 정확하고 과학적인 정의를 다룬다. 이 정의가 실제 사례에서 어떻게 적용되는지 살펴본다.
단위 테스트의 목표
흔히 단위 테스트 활동이 더 나은 설계로 이어진다고 한다. 이는 사실이다. 코드 베이스에 대해 단위 테스트 작성이 필요하면 일반적으로 더 나은 설계로 이어진다. 하지만 단위 테스트의 주목표는 아니다. 더 나은 설계는 단지 좋은 부수 효과일 뿐이다.
[단위 테스트와 코드 설계의 관계]
코드 조각을 단위 테스트하는 것은 훌륭한 리트머스 시험이지만, 한 방향으로만 작동한다.
이는 괜찮은 부정 지표다. 즉, 비교적 높은 정확도로 저품질 코드를 가려낸다. 코드를 단위 테스트하기 어렵다면 코드 개선이 반드시 필요하다는 것을 의미한다. 보통 강결합(tight coupling)에서 저품질이 나타나는데, 여기서 강결합은 제품 코드가 서로 충분히 분리되지 않아서 따로 테스트하기 어려움을 뜻한다.
안타깝게도 코드 조각을 단위 테스트할 수 있다는 것은 좋지 않은 긍정 지표다.
코드베이스를 쉽게 단위 테스트할 수 있다고 해도 반드시 코드 품질이 좋은 것을 의미하지는 않는다.
낮은 결합도를 보여도 프로젝트는 '대참사'가 될 수도 있다.
단위 테스트의 목표는 무엇인가? 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다. 지속 가능하다는 것이 핵심이다. 프로젝트가 상당히 쉽게 성장할 수 있다. 특히 처음부터 시작할 때 그렇다. 하지만 시간이 지나면서 이렇게 계속 성장하기는 훨씬 어렵다.
테스트가 없는 일반 프로젝트의 성장 추이는 처음에는 발목을 잡을 것이 없으므로 빨리 시작할 수 있다. 아직 잘못된 아키텍처 결정이 없고, 걱정할 만한 코드가 있지도 않다. 그러나 시간이 지나면서 점점 더 많은 시간을 들여야 처음에 보여준 것과 같은 정도의 진척을 낼 수 있다. 결국 개발 속도가 현저히 느려지고, 심지어 전혀 진행하지 못할 정도로 느려질 수 있다.
개발 속도가 빠르게 감소하는 이러한 현상을 소프트웨어 엔트포리(software entropy)라고도 한다. 엔트로피(시스템 내 무질서도)는 소프트웨어 시스템에도 적용할 수 있는 수학적이고 과학적인 개념이다.
소프트웨어에서 엔트로피는 품질을 떨어뜨리는 코드 형태로 나타난다. 코드베이스에서 무언가를 변경할 때마다 무질서도(엔트로피)는 증가한다. 지속적인 정리와 리팩터링 등과 같은 적절한 관리를 하지 않고 방치하면 시스템이 점점 더 복잡해지고 무질서해진다. 하나의 버그를 수정하면 더 많은 버그를 양산하고, 소프트웨어의 한 부분을 수정하면 다른 부분들이 고장 난다. 즉, 도미노 현상과 같다. 결국 코드베이스를 신뢰할 수 없게 된다. 그리고 제일 안 좋은 것은 안정화가 어렵다는 것이다.
테스트로 이러한 경향을 뒤집을 수 있다. 테스트는 안전망 역할을 하며, 대부분의 회귀(regression)에 대한 보험을 제공하는 도구라 할 수 있다. 테스트는 새로운 기능을 도입하거나 새로운 요구 사항에 더 잘 맞게 리팩터링한 후에도 기존 기능이 잘 작동하는지 확인하는 데 도움이 된다.
여기서 한 가지 단점이 있는데, 이러한 테스트는 초반에 노력이 필요하다는 것이다. 그러나 프로젝트 후반에도 잘 성장할 수 있도록 하므로 장기적으로 보면 그 비용을 메울 수 있다. 코드베이스를 지속적으로 검증하는 테스트 없이는 소프트웨어 개발이 쉽게 확장되지 않는다. 지속성과 확장성이 핵심이며, 이를 통해 장기적으로 개발 속도를 유지할 수 있다.
좋은 테스트와 좋지 않은 테스트를 가르는 요인
단위 테스트가 프로젝트 성장에 도움이 되는 것은 맞지만, 테스트를 작성하는 것만으로는 충분하지 않다. 잘못 작성한 테스트는 여전히 같은 결과를 낳는다. 잘못 작성한 테스트도 초반에 코드가 나빠지는 것을 늦출 수 있다. 즉, 테스트가 전혀 없는 상황에 비해 개발 속도가 덜 느려진다. 그러나 거시적인 관점에서는 큰 차이가 없다. 이러한 프로젝트가 침체 단계에 진입하는 데 시간이 더 걸릴 수 있지만, 피할 수는 없다.
모든 테스트가 똑같이 작성되지는 않는다. 일부 테스트는 아주 중요하고 소프트웨어 품질에 매우 많은 기여를 한다. 그 밖에 다른 테스트는 그렇지 않다. 잘못된 경고가 발생하고, 회귀 오류를 알아내는 데 도움이 되지 않으며, 유지 보수가 어렵고 느리다. 프로젝트에 도움이 되는지 여부를 명확하게 파악하지 않고 단위 테스트를 작성하는 데만 빠져들기 쉽다.
프로젝트에 테스트를 더 많이 실행하더라도 단위 테스트의 목표를 달성할 수 없다. 테스트의 가치와 유지 비용을 모두 고려해야 한다. 비용 요소는 다음과 같은 다양한 활동에 필요한 시간에 따라 결정된다.
기반 코드를 리팩터링할 때, 테스트도 리팩터링하라.
각 코드 변경 시 테스트를 실행하라.
테스트가 잘못된 경고를 발생시킬 경우 처리하라.
기반 코드가 어떻게 동작하는지 이해하려고 할 때는 테스트를 읽는 데 시간을 투자하라.
높은 유지 보수 비용으로 인해 순가치가 0에 가깝거나 심지어 0보다 작은 테스트를 만들기 쉽다. 지속 가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야 한다. 고품질 테스트만이 테스트 스위트에 남을 만한 테스트 유형이다.
[제품 코드 vs 테스트 코드]
사람들은 종종 제품 코드와 테스트 코드가 다르다고 생각한다. 테스트는 제품 코드에 추가된 것으로 간주되며, 소유 비용이 없다. 또한 사람들은 종종 테스트가 많으면 많을수록 좋다고 생각한다. 하지만 그렇지 않다. 코드는 자산이 아니라 책임이다. 코드가 더 많아질수록, 소프트웨어 내의 잠재적인 버그에 노출되는 표면적이 넓어지고 프로젝트 유지비가 증가한다. 따라서 가능한 한 적은 코드를 문제를 해결하는 것이 좋다.
테스트도 역시 코드다. 특정 문제를 해결하는 것, 즉 애플리케이션의 정확성을 보장하는 것을 목표로하는 코드베이스의 일부로 봐야 한다.
다른 코드와 마찬가지로 단위 테스트도 버그에 취약하고 유지보수가 필요하다.
좋은 단위 테스트와 나쁜 단위 테스트를 구별하는 방법을 익히는 것은 중요하다. (4장에서 다룬다)
테스트 스위트 품질 측정을 위한 커버리지 지표
이 절에서는 가장 널리 사용되는 두 가지 커버리지 지표(코드 커버리지와 분기 커버리지)를 어떻게 계산하고 어떻게 사용하는지 살펴보고 관련된 문제점도 알아본다. 프로그래머가 특정 커버리지 숫자를 목표로 하는 것이 해로운 이유와 테스트 스위트 품질을 결정하는 데 커버리지 지표에 의존할 수 없는 이유를 알아본다.
커버리지 지표는 테스트 스위트(suit)가 소스 코드를 얼마나 실행하는지를 백분율로 나타낸다.
커버리지 지표는 각기 다른 유형이 있으며, 테스트 스위트의 품질을 평가하는 데 자주 사용된다. 일반적으로 커버리지 숫자가 높을수록 더 좋다. 안타깝게도 그렇게 간단하지만은 않다. 커버리지 지표는 중요한 피드백을 주더라도 테스트 스위트 품질을 효과적으로 측정하는 데 사용될 수 없다. 코드를 단위 테스트하는 것과 같은 상황이다. 즉, 커버리지 지표는 괜찮은 부정 지표이지만 좋지 않은 긍정 지표다.
코드 커버리지가 너무 적을 때는 테스트가 충분치 않다는 좋은 증거다. 그러나 반대의 경우는 그렇지 못하다. 100% 커버리지라고 해서 반드시 양질의 테스트 스위트라고 보장하지는 않는다. 높은 커버리지의 테스트 스위트도 품질이 떨어질 수 있다.
코드 커버리지 지표에 대한 이해
가장 많이 사용되는 커버리지 지표로 코드 커버리지가 있으며, 테스트 커버리지로도 알려져 있다. 이 지표는 하나 이상의 테스트로 실행된 코드 라인 수와 제품 코드베이스의 전체 라인 수의 비율을 나타낸다.
코드 커버리지(= 테스트 커버리지) = 실행 코드 라인 수 / 전체 라인 수
분기 커버리지 지표에 대한 이해
또 다른 커버리지 지표는 분기 커버리지(branch coverage)다. 분기 커버리지는 코드 커버리지의 단점을 극복하는 데 도움이 되므로 코드 커버리지보다 더 정확한 결과를 제공한다. 분기 커버리지 지표는 원시 코드 라인 수를 사용하는 대신 if문과 switch 문과 같은 제어 구조에 중점을 둔다.
분기 커버리지 = 통과 분기 / 전체 분기 수
분기 커버지리 지표를 계산하려면 코드베이스에서 모든 가능한 분기를 합산하고 그 중 테스트가 얼마나 많이 실행되는지 확인해야 한다.
커버리지 지표에 관한 문제점
분기 커버리지로 코드 커버리지보다 더 나은 결과를 얻을 수 있지만, 테스트 스위트의 품질을 결정하는 데 어떤 커버리지 지표도 의존할 수 없는 이유는 다음과 같다.
테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장할 수 없다.
외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없다.
단지 코드 경로를 통과하는 것이 아니라 실제로 테스트하려면, 단위 테스트에는 반드시 적절한 검증이 있어야 한다. 즉, 테스트 대상 시스템이 낸 결과가 정확히 예상하는 결과인지 확인해야 한다. 더구나 결과가 여러 개 있을 수 있다. 따라서 커버리지 지표가 의미가 있으려면, 모든 측정 지표를 검증해야 한다. 커버리지 지표는 기반 코드를 테스트했다고 보장할 수 없으며 일부 실행된 것만 보장한다. 검증이 전혀 없는 테스트의 경우 이보다 더 극단적인 상황이다.
그렇다면 테스트 대상 코드에 대해 각각의 결과를 철저히 검증한다면 분기 커버리지 지표와 함께 신뢰할 수 있는 구조라고 할 수 있을까? 또한 테스트 스위트 품질을 결정하는 데 사용할 수 있는가? 안타깝게도 아니다!
두 번째 문제는 모든 커버리지 지표가 테스트 대상 시스템이 메서드 호출할 때 외부 라이브러리가 통과하는 코드 경로를 고려하지 않는다는 것이다.
수 많은 예외 상황(edge case)에 빠질 수 있지만, 테스트에서 모든 예외 상황을 다루는지 확인할 방법이 없다. 이는 커버리지 지표가 외부 라이브러리의 코드 경로를 고려해야 한다는 것이 아니라(고려하면 안 된다), 해당 지표로는 단위 테스트가 얼마나 좋은지 나쁜지를 판단할 수 없다는 것을 보여준다. 커버리지 지표로 테스트가 철저한지 또는 테스트가 충분한지 알 수는 없다.
특정 커버리지 숫자를 목표로 하기
테스트 스위트 품질을 결정하기에 커버리지 지표만으로는 충분하지 않다는 것을 깨달았을 것이다. 특정 커버리지 숫자를 목표로 삼기 시작하면 위험 영역으로 이어질 수 있다. 커버리지 지표를 보는 가장 좋은 방법은 지표 그 자체로 보는 것이며, 목표로 여겨서는 안 된다.
특정 커버리지를 목표로 하는 것은 단위 테스트의 목표와 반대되는 그릇된 동기 부여가 된다. 사람들은 중요한 것을 테스트하는 데 집중하는 대신 인공적인 목표를 달성하기 위한 방법을 찾기 시작한다. 적절한 단위 테스트는 이미 충분히 어렵다. 커버리지 숫자를 강요하면 개발자들은 테스트 대상에 신경쓰지 못하고, 결국 적절한 단위 테스트는 더욱 달성하기 어려워진다.
시스템의 핵심 부분은 커버리지를 높게 두는 것이 좋다. 하지만 이 높은 수준을 요구 사항으로 삼는 것은 좋지 않다. 그 차이는 미미하지만 매우 중요하다.
다시 말하지만, 커버리지 지표는 좋은 부정 지표이지만 나쁜 긍정 지표다. 커버리지 숫자가 낮으면 문제 징후라 할 수 있다. 코드베이스에 테스트되지 않은 코드가 많다는 뜻이다. 그러나 높은 숫자도 별 의미는 없다. 그러므로 코드 커버리지를 측정하는 것은 품질 테스트 스위트로 가는 첫걸음일 뿐이다.
무엇이 성공적인 테스트 스위트를 만드는가?
제대로 하려면 어떻게 해야할까? 테스트 스위트의 품질을 어떻게 측정해야 하는가? 믿을 만한 방법은 스위트 내 각 테스트를 하나씩 따로 평가하는 것뿐이다. 물론 한 번에 모든 것을 평가할 필요는 없다. 꽤 큰 작업이 될 수 있고, 이에 앞서 노력을 상당히 들여야 할 수도 있다. 평가를 하나씩 늘려가며 수행할 수도 있다. 요점은 테스트 스위트가 얼마나 좋은지 자동으로 확인할 수 없다는 것이다. 개인 판단에 맡겨야 한다.
전체적으로 어떻게 테스트 스위트를 성공할 수 있는지 더 넓게 살펴보자. 성공적인 테스트 스위트는 다음과 같은 특성을 갖고 있다.
개발 주기에 통합돼 있다.
코드베이스에서 가장 중요한 부분만을 대상으로 한다.
최소한의 유지비로 최대의 가치를 끌어낸다.
개발 주기에 통합돼 있음
자동화된 테스트를 할 수 있는 방법은 끊임없이 하는 것 뿐이다. 모든 테스트는 개발 주기에 통합돼야 한다. 이상적으로 코드가 변경될 때마다 아무리 작은 것이라도 실행해야 한다.
코드베이스에서 가장 중요한 부분만을 대상으로 함
모든 테스트가 똑같이 작성되지 않은 것처럼 단위 테스트 측면에서 코드베이스의 모든 부분에 똑같이 주목할 필요는 없다. 테스트가 주는 가치는 테스트 구조뿐만 아니라 검증하는 코드에도 있다.
시스템의 가장 중요한 부분에 단위 테스트 노력을 기울이고, 다른 부분은 간략하게 또는 간접적으로 검증하는 것이 좋다. 대부분의 애플리케이션에 가장 중요한 부분은 비즈니스 로직(도메인 모델)이 있는 부분이다. 비즈니스 로직 테스트가 시간 투자 대비 최고의 수익을 낼 수 있다.
다른 모든 부분은 세 가지 범주로 나눌 수 있다.
인프라 코드
데이터베이스나 서드파티 시스템과 같은 외부 서비스 및 종속정
모든 것을 하나로 묶는 코드
그러나 이 중 일부는 단위 테스트를 철저히 해야 할 수 있다. 예를 들어 인프라 코드에 복잡하고 중요한 알고리즘이 있을 수 있으므로, 테스트를 많이 하는 것이 좋다. 그러나 일반적으로 도메인 모델에 관심을 더 많이 갖는 것이 옳다.
통합 테스트와 같이 일부 테스트는 도메인 모델을 넘어 코드베이스의 중요하지 않은 부분을 포함해 시스템이 전체적으로 어떻게 작동하는지 확인할 수 있다. 이 방법도 괜찮으나 초점은 도메인 모델에 머물러 있어야 한다.
이 지침을 따르려면 도메인 모델을 코드베이스 중 중요하지 않은 부분과 분리해야 한다. 도메인 모델을 다른 애플리케이션 문제와 분리해야 단위 테스트에 대한 노력을 도메인 모델에만 집중할 수 있다.
최소 유지비로 최대 가치를 끌어냄
단위 테스트에서 가장 어려운 부분은 최소 유지비로 최대 가치를 달성하는 것이다. 이것이 이 책에서 말하려는 핵심이다. 테스트를 빌드 시스템에 통합하는 것만으로는 충분하지 않으며, 도메인 모델에 높은 테스트 커버리지를 유지하는 것도 충분하지 않다. 또한 가치가 유지비를 상회하는 테스트만 스위트에 유지하는 것이 중요하다.
이 마지막 속성은 두 가지로 나눌 수 있다.
가치 있는 테스트(더 나아가, 가치가 낮은 테스트) 식별하기
가치 있는 테스트 작성하기
이러한 기술은 비슷해 보일지 모르지만, 선천적으로 다르다. 가치가 높은 테스트를 식별하려면 기준틀(frame of reference)이 필요하다. 반면에 가치 있는 테스트를 작성하려면 코드설계 기술도 알아야 한다. 단위 테스트와 기반 코드는 서로 얽혀 있으므로 코드베이스에 노력을 많이 기울이지 않으면 가치 있는 테스트를 만들 수 없다.
class Plant {
enum LifeCycle { ANIMAL, PERENNIAL, BIENNIAL }
final String name;
final LifeCycle lifeCycle;
Plant(String name, LifeCycle lifeCycle) {
this.name = name;
this.lifeCycle = lifeCycle;
}
@Override
public String toString() {
return name;
}
}
정원에 심은 식물들을 배열 하나로 관리하고, 이들을 생애주기별로 묶어보자. 생애주기별로 총 3개의 집합을 만들고 정원을 한 바퀴 돌며 각 식물을 해당 집합에 넣는다. 이때 어떤 프로그래머는 집합들을 배열 하나에 넣고 생애주기의 ordinal 값을 그 배열의 인덱스로 사용하려 할 것이다.
Set<Plant>[] plantsByLifeCycle = (Set<Plant>[]) new Set[Plant.LifeCycle.values().length];
for (int i = 0; i < plantsByLifeCycle.length; i++) {
plantsByLifeCycle[i] = new HashSet<>();
}
for (Plant plant : garden) {
plantsByLifeCycle[p.lifeCycle.ordinal()].add(p);
}
// 결과 출력
for (int i = 0; i < plantsByLifeCycle.length; i++) {
System.out.println("%s: %s%n", Plant.LifeCycle.values()[i], plantsByLifeCycle[i]);
}
동작은 하지만 문제가 많다. 배열은 제네릭과 호환되지 않으니 비검사 형변환을 수행해야 하고 깔끔히 컴파일되지 않을 것이다.배열은 각 인덱스의 의미를 모르니 출력 결과에 직접 레이블을 달아야 한다. 가장 심각한 문제는 정확한 정숫값을 사용한다는 것을 우리가 직접 보증해야 한다는 점이다. 정수는 열거 타입과 달리 타입 안전하지 않기 때문이다. 잘못된 값을 사용하면 잘못된 동작을 묵묵히 수행하거나 ArrayIndexOutOfBoundsException을 던질 것이다.
좋은 해결책이 있으니 걱정하지말자. 여기서 배열을 실질적으로 열거 타입 상수를 값으로 매핑하는 일을 한다. 그러므로 Map을 사용할 수도 있을 것이다. 사실 열거 타입을 키로 사용하도록 설계한 아주 빠른 Map 구현체가 존재하는데, 바로 EnumMap이다. 다음은 위의 코드를 수정하여 EnumMap을 사용하도록 한 코드다.
Map<Plant.LifeCycle, Set<Plant>> plantsByLifeCycle = new EnumMap<>(Plant.LifeCycle.class);
for (Plant.Life(Cucle lc : Plant.LifeCycle.values())
plantsByLifeCycle.put(lc, new HashSet<>());
for (Plant p : garden)
plantsByLifeCycle.get(p.lifeCycle).add(p);
System.out.println(plantsByLifeCycle);
더 짧고 명료하고 안전하며 성능도 원래 버전과 비슷하다. 안전하지 않은 형변환은 쓰지 않고, 맵의 키인 열거 타입이 그 자체로 출력용 문자열을 제공하니 출력 결과에 직접 레이블을 달 일도 없다. 나아가 배열 인덱스를 계산하는 과정에서 오류가 날 가능성도 원천봉쇄된다. EnumMap의 성능이 ordinal을 쓴 배열에 비견되는 이유는 그 내부에서 배열을 사용하기 때문이다. 내부 구현 방식을 안으로 숨겨서 Map의 타입 안정성과 배열의 성능을 모두 얻어낸 거이다. 여기서 EnumMap의 생성자가 받는 키 타입의 Class 객체는 한정적 타입 토큰으로, 런타입 제네릭 타입 정보를 제공한다.
스트림을 사용해 맵을 관리하면 코드를 더 줄일 수도 있다. 다음은 앞의 예를 그대로 스트림 기반의 코드로 변경한 코드이다.
이 코드는 EnumMap이 아닌 고유한 맵 구현체를 사용했기 때문에 EnumMap을 써서 얻은 공간과 성능 이점이 사라진다는 문제가 있다. 이 문제를 좀 더 자세히 살펴보자. 매개변수 3개짜리 Collections.groupingBy 메서드는 mapFactory매개변수에 원하는 맵 구현체를 명시해 호출할 수 있다.
System.out.println(Arrays.stream(garden)
.collect(groupingBy(p -> p.lifeCycle,
() -> new EnumMap<>(LifeCycle.class), toSet())));
이 예처럼 단순한 프로그램에서는 최적화가 굳이 필요 없지만, 맵을 빈번히 사용하는 프로그램에서는 꼭 필요할 것이다.
스트림을 사용한다면 EnumMap만 사용했을 때와는 살짝 다르게 동작한다. EnumMap 버전은 언제나 식물의 생애주기당 하나씩의 중첩 맵을 만들지만, 스트림 버전에서는 해당 생애주기에 속하는 식물이 있을 때만 만든다. (ex. 정원에 한해살이와 여러해살이 식물만 살고 두해살이는 없다면, EnumMap 버전에서는 3개의 맵을 스트림 버전에서는 2개만 만든다) 두 열거 타입 값들을 매핑하느라 ordinal을 (두 번이나) 쓴 배열들의 배열을 본 적이 있을 것이다. 다음은 이 방식을 적용해 두 가지 상태(Phase)를 전이(Transition)와 매핑하도록 구현한 프로그램이다. 예를들어 액체(LIQUID)에서 고체(SOLID)로의 전이는 응고(FREEZE)가 되고, 액체에서 기체(GAS)로의 전이는 기화(BOIL)가 된다.
public enum Phase {
SOLID, LIQUID, GAS;
public enum Transition {
MELT, FREEZE, BOIL, CONDENSE, SUBLIME, DEPOSIT;
// 행은 from의 ordinal을, 열은 to의 ordinal을 인덱스로 쓴다.
private static final Transition[][] TRANSITIONS = {
{ null, MELT, SUBLIME },
{ FREEZE, null, BOIL},
{ DEPOSIT, CONDENSE, null }
};
// 한 상태에서 다른 상태로의 전이를 반환한다.
public static Transition from(Phase from, Phase to) {
return TRANSITIONS[from.ordinal()][to.ordinal()];
}
}
}
앞서 보여준 간단한 정원 예제와 마찬가지로 컴파일러는 ordinal과 배열 인덱스의 관계를 알 도리가 없다. 즉, Phase나 Phase.Transition 열거 타입을 수정하면서 상전이 표 TRANSITIONS를 함께 수정하지 않거나 실수로 잘못 수정하면 런타임 오류가 날 것이다. ArrayIndexOutOfBoundsException이나 NullPointerException을 던질 수도 있고, 예외도 던지지 않고 이상하게 동작할 수도 있다. 그리고 상전이 표의 크기는 상태의 가짓수가 늘어나면 제곱해서 커지면 null로 채워지는 칸도 늘어날 것이다.
앞에서도 말했지만, EnumMap을 사용하는 편이 훨씬 좋다. 전이 하나를 얻으려면 이전 상태(from)와 이후 상태(to)가 필요하니, 맵 2개를 중첩하면 쉽게 해결할 수 있다. 안쪽 맵은 이전 상태와 전이를 연결하고 바깥 맵은 이후 상태와 안쪽 맵을 연결한다. 전이 전후의 두 상태를 전이 열거 타입 Transition의 입력으로 받아, 이 Transition 상수들로 중첩된 EnumMap을 초기화하면 된다.
public enum Phase {
SOLID, LIQUID, GAS;
public enum Transition {
MELT(SOLID, LIQUID), FREEZE(LIQUID, SOLID),
BOID(LIQUID, GAS), CONDENSE(GAS, LIQUID),
SUBLIME(SOLID, GAS), DEPOSIT(GAS, SOLID);
Transition(Phase from, Phase to) {
this.from = from;
this.to = to;
}
// 상전이 맵을 초기화한다.
private static final Map<Phase, Map<Phase, Transition>>
m = Stream.of(values()).collect(groupingBy(t -> t.from,
() -> new EnumMap<>(Phase.class),
toMap(t -> t.to, t -> t,
(x, y) -> y, () -> new EnumMap<>(Phase.class))));
public static Transition from(Phase from, Phase to) {
return m.get(from).get(to);
}
}
}
상전이 맵을 초기화하는 코드는 매우 복잡하다. 이 맵의 타입인 Map<Phase, Map<Phase, Transition>>은 "이전 상태에서 '이후 상태에서 전이로의 맵'에 대응시키는 맵" (표현이 하기가 너무 어렵다 🥲)이라는 뜻이다. 이러한 맵의 맵을 초기화하기 위해 수집기(java.util.stream.Collector) 2개를 차례로 사용했다. 첫 번째 수집기인 groupingBy 에서는 전이를 이전 상태를 기준으로 묶고, 두 번째 수집기인 toMap에서는이후 상태를 전이에 대응시키는 EnumMap을 생성한다. 두 번째 수집기의 병합 함수인 (x, y) -> y는 선언만 하고 실제로는 쓰이지 않는데, 이는 단지 EnumMap을 얻으려면 맵 팩터리가 필요하고 수집기들을 점층적 팩터리를 제공하기 때문이다. (2판의 내용에서는 코드가 더 장황하기는 하지만 지금(3판) 코드보다 더 이해하기가 쉬울거라는 언급이 있음)
이제 여기에 새로운 상태인 플라스마(PLASMA)를 추가해보자. 이 상태와 연결된 전이는 2개다. 첫 번째는 기체에서 플라스마로 변하는 이온화(IONIZE)이고, 둘째는 플라스마에서 기체로 변하는 탈이온화(DEIONIZE)다. 배열로 만든 코드를 수정하려면 새로운 상수를 Phase에 1개, Phase.Transition에 2개를 추가하고, 원소 9개짜리인 배열들의 배열을 원소 16개짜리로 교체해야 한다. 원소 수를 너무 적거나 많이 기입하거나, 잘못된 순서로 나열하면 이 프로그램은(컴파일은 어찌저찌 통과하더라도) 런타임에 문제를 일으킬 것이다. 반면, EnumMap 버전에서는 상태 목록에 PLASMA를 추가하고, 전이 목록에 IONIZE(GAS, PLASMA)와 DEIONIZE(PLASMA, GAS)만 추가하면 끝이다.
public enum Phase {
SOLID, LIQUID, GAS, PLASMA;
public enum Transition {
MELT(SOLID, LIQUID), FREEZE(LIQUID, SOLID),
BOIL(LIQUID, GAS), CONDENSE(GAS, LIQUID),
SUBLIME(SOLID, GAS), DEPOSIT(GAS, SOLID),
IONIZE(GAS, PLASMA), DEIONIZE(PLASMA, GAS);
...// 나머지 코드는 동일
}
}
나머지는 기존 로직에서 잘 처리해주어 잘못 수정할 가능성이 극히 작다. 실제 내부에서는 맵들의 맵이 배열들의 배열로 구현되니 낭비되는 공간과 시간도 거의 없이 명확하고 안전하고 유지보수하기 좋다.
| 코드를 간략히 하기 위해 해당 전이가 없는 경우, null을 사용했다. 이는 NullPointerException을 일으키는 매우 안좋은 습관이지만 예제를 단순화시키기 위해 예제에서는 사용했다.
열거한 값들이 주로 집합으로 사용될 경우, 예전에는 각 상수에 서로 다른 2의 거듭제곱 값을 할당한 정수 열거 패턴을 사용해왔다.
public class Text {
public static final int STYLE_BOLD = 1 << 0; // 1
public static final int STYLE_ITALIC = 1 << 1; // 2
public static final int STYLE_UNDERLINE = 1 << 2; // 4
public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8
// 매개변수 styles는 0개 이상의 STYLE_ 상수를 비트별 OR한 값이다.
public void applyStyles(int styles) { ... }
}
다음과 같은 식으로 비트별 OR를 사용해 여러 상수를 하나의 집합으로 모을 수 있으며 이렇게 만들어진 집합을 비트 필드(bit field)라 한다.
text.applyStyles(STYLE_BOLD | STYLE_ITALIC);
비트 필드를 사용하면 비트별 연산을 사용해 합집합과 교집합 같은 집합 연산을 효율적으로 수행할 수 있다. 하지만 비트 필드는 정수 열거 상수의 단점을 그대로 가지고 추가적으로 다음과 같은 문제까지 안고있다.
비트 필드 값이 그대로 출력되면 단순한 정수 열거 상수를 출력할 때보다 해석하기가 훨씬 어렵다. 비트 필드 하나에 녹아 있는 모든 원소를 순회하기도 까다롭다. 마지막으로, 최대 몇 비트가 필요한지를 API를 수정하지 않고는 비트 수(32bit or 64bit)를 더 늘릴 수 없기 때문이다.
정수 상수보다 열거 타입을 선호하는 프로그래머 중에도 상수 집합을 주고 받아야 할 때는 여전히 비트 필드를 사용하기도 한다. 하지만 이제 더 나은 대안이 있다. java.util 패키지의 EnumSet 클래스는 열거 타입 상수의 값으로 구성된 집합을 효과적으로 표현해준다. Set 인터페이스를 완전히 구현하며, 타입 안전하고, 다른 어떤 Set 구현체와도 함께 사용할 수 있다. 하지만 EnumSet의 내부는 비트 벡터로 구현되었다. 원소가 총 64개 이하라면, 즉 대부분의 경우에 EnumSet 전체를 long 변수 하나로 표현하여 비트 필드에 비견되는 성능을 보여준다. removeAll과 retainAll 같은 대량 작업은 (비트 필드를 사용할 때 쓰는 것과 같은) 비트를 효율적으로 처리할 수 있는 산술 연산을 써서 구현했다.
그러면서도 비트를 직접 다룰 때 흔히 겪는 오류들에서 해방된다. 난해한 작업을 EnumSet이 다 처리해주기 때문이다. 앞의 예제를 열거 타입과 EnumSet을 사용해서 수정하면 아래와 같다.
public class Text {
public enum STYLE { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }
// 어떤 Set을 ㄴ머겨도 되나, EnumSet이 가장 좋다.
public void applyStyles(Set<Style> styles) { ... }
}
다음은 위의 코드의 applyStyles 메서드에 EnumSet 인스턴스를 건네는 클라이언트 코드다. EnumSet 인스턴스를 건네는 클라이언트 코드다. EnumSet은 집합 생성 등 다양한 기능의 정적 팩터리를 제공하는데, 다음 코드에서는 그중 of 메서드를 사용했다.
applyStyles 메서드가 EnumSet<Style>이 아닌 Set<Style>을 받은 이유를 생각해보자. 모든 클라이언트가 EnumSet을 건네리라 짐작되는 상황이라도 이왕이면 인터페이스로 받는 게 일반적으로 좋은 습관이다. 이렇게 하면 좀 특이한 클라이언트가 다른 Set 구현체를 넘기더라도 처리할 수 있으니 말이다.
대부분의 열거 타입 상수는 자연스럽게 하나의 정숫값에 대응된다. 그리고 모든 열거 타입은 해당 상수가 그 열거 타입에서 몇 번째 위치인지를 반환하는 ordinal이라는 메서드를 제공한다. 이런 이유로 열거 타입 상수와 연결된 정숫값이 필요하면 ordinal 메서드를 이용하고 싶은 유혹에 빠진다. 다음 코드는 합주단의 종류를 연주자가 1명인 솔로(solo)부터 10명인 디텍트(dectet)까지 정의한 열거 타입이다.
public enum Ensemble {
SOLO, DUET, TRIO, QUARTET, QUINTET,
SEXTET, SEPTET, OCTET, NONET, DECTET;
public int numberOfMusicians() { return ordinal() + 1; }
}
동작은 하지만 유지보수하기가 끔찍한 코드다. 상수 선언 순서를 바꾸는 순간 numberOfMusicians가 오동작하며, 이미 사용 중인 정수와 값이 같은 상수는 추가할 방법이 없다. 예컨대 octet('8중주'라는 의미이다) 상수가 이미 있기 때문에 똑같이 8명이 연주하는 double quartet('복4중주')는 추가할 수 없다.
또한, 값을 중간에 비워둘 수도 없다. 예컨대 12명이 연주하는 3중 4중주 (triple quartet)를 추가한다고 가정하자. 그러면 중간에 11명짜리 상수도 채워야 하는데, 11명으로 구성된 연주를 일컫는 이름은 없다. 그래서 3중 4중주를 추가하려면 쓰이지 않는 더미(dummy) 상수를 같이 추가해야만 한다. 코드가 깔끔하지 못할 뿐 아니라, 쓰이지 않는 값이 많아질수록 실용성이 떨어진다.
해결책은 간단하다. 열거 타입 상수에 연결된 값은 *ordinal* 메서드로 얻지말고, 인스턴스 필드에 저장하자.
public enum Ensemble {
SOLO(1), DUET(2), TRIO(3), QUARTET(4), QUINTET(5),
SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8),
NONET(9), DECTET(10), TRIPLE_QUARTET(12);
private final int numberOfMusicians;
Ensemble(int size) {
this.numberOfMusicians = size;
}
public int numberOfMusicians() {
return numberOfMusicians;
}
}
Enum의 API 문서를 보면 ordinal에 대해 이렇게 쓰여 있다.
| "대부분 프로그래머는 이 메서드를 쓸 일이 없다. 이 메서드는 EnumSet과 EnumMap 같이 열거 타입 기반의 범용 자료구조에 쓸 목적으로 설계되었다."
열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 허용하지 않는 타입이다. 자바에서 열거 타입을 지원하기 전에는 정수, 상수를 한 묶음 선언해서 사용하곤 했다.
정수 열거 패턴(int enum pattern) 기법에는 단점이 많다. 타입 안전을 보장할 방법이 없으며 표현력도 좋지 않다.
정수 열거 패턴을 사용한 프로그램은 깨지기 쉽다. 평범한 상수를 나열한 것뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 따라서 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일해야 한다. 다시 컴파일하지 않은 클라이언트는 실행이 되더라도 엉뚱하게 동작할 것이다.
정수 상수는 문자열로 출력하기가 다소 까다롭다. 그 값을 출력하거나 디버거로 살펴보면 단지 숫자로만 보여서 별 도움이 안된다. 같은 정수 열거 그룹에 속한 모든 상수를 한 바퀴 순회하는 방법도 마땅치 않다. 심지어 그 안에 상수가 몇 개인지도 알 수 없다.
정수 대신 문자열 상수를 사용하는 변형 패턴도 있다. 문자열 열거 패턴(string enum pattern)이라 하는 이 변형은 더 안좋다. 상수의 의미를 출력할 수 있다는 점은 좋지만, 경험이 부족한 프로그래머가 문자열 상수의 이름 대신 문자열 값을 그대로 하드코딩하게 만들기 때문이다. 이렇게 하드코딩한 문자열에 오타가 있어도 컴파일러는 확인할 길이 없으니 자연스럽게 런타임 버그가 생긴다. 문자열 비교에 따른 성능 저하 역시 당연한 결과다.
다행히 자바는 열거 패턴의 단점을 말끔히 씻어주는 동시에 여러 장점을 안겨주는 대안을 제시했다. 바로 열거 타입(enum type)이다. 다음은 열거 타입의 가장 단순한 형태다.
public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
public enum Orange { NAVEL, TEMPLE, BLOOD }
자바의 열거 타입은 완전한 형태의 클래스라서 다른 언어의 열거 타입보다 훨씬 강력하다. 자바 열거 타입을 뒷받침하는 아이디어는 단순하다. 열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다. 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다. 따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로 만들어진 인스턴스들은 딱 하나씩만 존재함이 보장된다. 즉 열거 타입은 인스턴스 통제된다. (싱글턴은 원소가 하나뿐이 열거 타입이라 할수 있고 반대로 열거 타입은 싱글턴을 일반화한 형태라고 할 수 있다)
열거 타입은 컴파일타임 타입 안정성을 제공한다. Apple 열거 타입을 매개변수로 받는 메서드를 선언했다면, 건네받은 참조는 (null이 아니라면...) Apple의 원소중 하나임이 확실하다. 다른 타입의 값을 넘기려하면 컴파일 오류가 난다. 타입이 다른 열거 타입 변수에 할당하려 하거나 다른 열거 타입의 값끼리 == 연산자로 비교하려는 꼴이기 때문이다.
열거 타입에는 각자의 이름공간이 있어서 이름이 같은 상수도 평화롭게 공존한다. 열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도 다시 컴파일하지 않아도 된다. 공개되는 것이 오직 필드의 이름뿐이라, 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문이다. 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각이되지 않기 때문이다. 마지막으로 열거 타입의 toString 메서드는 출력하기에 적합한 문자열을 내어준다.
이처럼 열거 타입은 정수 열거 패턴의 단점들을 해소해준다. 열거 타입에는 임의의 메서드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수도 있다. Object 메서드들을 높은 품질로 구현해놨고 Comparable과 Serialiazable을 구현했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨다.
열거 타입에 메서드나 필드를 추가하는 것은 어떨 때 필요한 기능일까? 열거 타입 상수 각각을 특정 데이터와 연결지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다. 열거 타입은 근본적으로 불변이라 모든 필드는 final이어야 한다. 필드를 public으로 선언해도 되지만, private으로 두고 별도의 public 접근자 메서드를 두는 게 낫다.
열거 타입은 자신 안에 정의된 상수들의 값을 배열에 담아 반환하는 정적 메서드인 valeus를 제공한다. 값들은 선언된 순서로 저장된다. 각 열거 타입 값의 toString 메서드는 상수 이름을 문자열로 반환하므로 println과 printf로 출력하기에 안성맞춤이다. 기본 toString 이름이 내키지 않으면 원하는 대로 재정의하면 된다.
열거 타입을 선언한 클래스 혹은 그 패키지에서만 유용한 기능은 private나 package-private(=default) 메서드로 구현한다. 이렇게 구현된 열거 타입 상수는 자신을 선언한 클래스 혹은 패키지에서만 사용할 수 있는 기능을 담게 된다. 일반 클래스와 마찬가지로, 그 기능을 클라이언트에 노출해야 할 합당한 이유가 없다면 private 혹은 package-private으로 선언하라.
널리 쓰이는 열거 타입은 톱 레벨 클래스로 만들고, 특정 톱레벨 클래스에서만 쓰인다면 해당 클래스의 멤버 클래스로 만든다. 예를 들어 소수 자릿수의 반올림 모들르 뜻하는 열거 타입인 java.math.RoundingModesms BigDecimal이 사용한다. 그런데 반올림 모드는 BigDecimal과 관련없는 영역에서도 유용한 개념이라 자바 라이브러리 설계자는 RoundingMode를 톱 레벨로 올렸다. 이 개념을 많은 곳에서 사용하여 다양한 API가 더 일관된 모습을 갖출 수 있도록 장려한 것이다.
더 나아가 상수마다 동작이 달라져야 하는 상황도 있을 것이다. 예를들자면 사칙연산 계산기의 연산 종류를 열거 타입으로 선언하고, 실제 연산까지 열거 타입 상수가 직접 수행했으면 한다고 해보자. 이는 if문이나 swtich문 같은 것으로 해결할 수도 있겠지만, 열거타입은 상수별로 다르게 동작하는 코드를 구현하는 더 나은 수단을 제공한다. 열거 타입에 apply라는 추상 메서드를 선언하고 각 상수별 클래스 몸체, 즉 각 상수에서 자신에 맞게 재정의하는 방법이다. 이를 상수별 메서드 구현이라 한다.
public enum Operation {
PLUS {public double apply(double x, double y) {return x + y}},
MINUS {public double apply(double x, double y) {return x - y}},
TIMES {public double apply(double x, double y) {return x * y}},
DIVIDE {public double apply(double x, double y) {return x / y}},
public abstract double apply(double x, double y);
}
보다시피 apply 메서드가 상수 선언 바로 옆에 붙어 있으니 새로운 상수를 추가할 때 apply도 재정의해야 한다는 사실을 깜빡하기는 어려울 것이다. 그것뿐만 아니라 apply가 추상메서드이므로 재정의하지 않았다면 컴파일 오류로 알려준다. 상수별 메서드 구현을 상ㅅ별 데이터와 결합할 수도 있다.
public enum Operation {
PLUS("+") {public double apply(double x, double y) {return x + y}},
MINUS{"-"} {public double apply(double x, double y) {return x - y}},
TIMES{"*"} {public double apply(double x, double y) {return x * y}},
DIVIDE{"/"} {public double apply(double x, double y) {return x / y}},
private final String symbol;
Operation(String symbol) { this.symbol = symbol; }
public abstract double apply(double x, double y);
}
열거 타입에는 상수 이름을 입력받아 그 이름에 해당하는 상수를 반환해주는 valueOf(String) 메서드가 자동 생성된다. 한편, 열거 타입의 toString 메섣를 재정의하려거든, toString이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께 제공하는 걸 고려해보자.다음 코드는 모든 열거 타입에서 사용할 수 있도록 구현한 fromString이다.
private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(
toMap(Object::toString, e -> e));
// 지정한 문자열에 해당하는 Operation을 (존재한다면) 반환한다.
public static Optional<Operation fromStrnig(String symbol) {
return Optional.ofNullable(stringToEnum.get(symbl));
}
Operation 상수가 stringToEnum 맵에 추가되는 시점은 열거 타입 상수 생성 후 정적 필드가 초기화될 때다. 앞의 코드는 values 메서드가 반환하는 배열 대신 스트림을 사용했다. 자바 8 이전에는 빈 해시맵을 만든 다음 valeus가 반환한 배열을 순회하며 (문자열, 열거 타입 상수) 쌍을 맵에 추가하면 된다.
하지만 열거 타입 상수는 생성자에서 자신의 인스턴스를 맵에 추가할 수 없다. 이렇게 하려면 컴파일 오류가 나는데, 만약 이 방식이 허용되었다면 런타임에 NullPointerException이 발생했을 것이다. 열거 타입의 정적 필드 중 열거 타입의 생성자에서 접근할 수 있는 것은 상수 변수뿐이다. 열거 타입 생성자가 실행되는 시점에는 정적 필드들이 아직 초기화되기 전이라, 자기 자신을 추가하지 못하게 하는 제약이 꼭 필요하다. 이 제약의 특수한 예로, 열거 타입 생성자에서 같은 열거 타입의 다른 상수에도 접근할 수 없다.
fromString이 Optional<Operation>을 반환한다는 점도 주의하자. 이는 주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고, 그 상황을 클라이언트에 대처하도록 한 것이다.
한편, 상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다.
급여명세서에서 쓸 요일을 표현하는 열거 타입을 예로 생각해보자. 이 열거 타입은 직원의 기본 임금과 그날 일한 시간이 주어지면 일당을 계산해주는 메서드를 갖고 있다. 주중에 오버타임이 발생하면 잔업수당이 주어지고, 주말에는 무조건 잔업수당이 주어진다. switch문을 이용하면 case문을 날짜별로 두어 이 계산을 쉽게 수행할 수 있다.
enum PayrollDay {
MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;
int pay(int minutesWorked, int payRate) {
int basePay = minutesWorked * payRate;
int overtimePay;
switch(this) {
case SATURDAY: case SUNDAY: // 주말
overtimePay = basePay / 2;
break;
default:
overtimePay = minutesWorked <= MINS_PER_SHIFT ? 0 : (minutesWorked - MINS_PER_SHIFT) * payRate / 2;
}
return basePay * overtimePay;
}
}
분명 간결하지만, 관리 관점에서는 위험한 코드다. 휴가와 같은 새로운 값을 열거 타입에 추가하려면 그 값을 처리하는 case 문을 잊지 말고 쌍으로 넣어줘야 하는 것이다.
상수별 메서드 구현으로 급여를 정확히 계산하는 방법은 두 가지다.
잔업수당을 계산하는 코드를 모든 상수에 중복해서 넣으면 된다.
계산 코드를 평일용과 주말용으로 나눠 각각을 도우미 메서드로 작성한 다음 각 상수가 자신에게 필요한 메서드를 적절히 호출하면 된다.
두 방식 모두 코드가 장황해져 가독성이 크게 떨어지고 오류 발생 가능성이 높아진다.
가장 깔끔한 방법은 새로운 상수를 추가할 때 잔업수당 '전략'을 선택하도록 하는 것이다. 잔업수당 계산을 private 중첩 열거 타입(다음 코드의 PayType)으로 옮기고 PayrollDay 열거 타입의 생성자에서 이중 적당한 것을 선택한다. 그러면 PayrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여, switch 문이나 상수별 메서드 구현이 필요 없게 된다. 이 패턴은 switch 문보다 복잡하지만 더 안전하고 유연한다.
enum PayrollDay {
MONDAY(WEEKDAY), TUESDAY(WEEKDAY), WEDNESDAY(WEEKDAY), THURSDAY(WEEKDAY), FRIDAY(WEEKDAY),
SATURDAY(WEEKEND), SUNDAY(WEEKEND);
private final PayType payType;
PayrollDay(PatType payType) { this.payType = payType; }
int pay(int minutesWorked, int payRate) {
return payType.pay(minutesWorked, payRate);
}
// 전략 열거 타입
enum PayType {
WEEKDAY {
int overtimePay(int minsWorked, int payRate) {
return minsWorked <= MINS_PER_SHIFT ? 0 :
(minsWorked - MINS_PER_SHIFT) * payRate / 2;
}
},
WEEKEND {
int overtimePay(int minsWorked, int payRate) {
return minsWorked * payRate / 2;
}
};
abstract int overtimePay(int mins, int payRate);
private static final int MINS_PER_SHIFT = 8 * 60;
int pay(int minsWorked, int payRate) {
int basePay = minsWorked * payRate;
return basePay + overtimePay(minsWorked, payRate);
}
}
}
보다시피 switch 문은 열거 타입의 상수별 동작을 구현하는 데 적합하지 않다. 하지만 기존 열거 타입에 상수별 동작을 혼합해 넣을 때는 switch 문이 좋은 선택이 될 수 있다. 예컨대 서드파티에서 가져온 Operation 열거 타입이 있는데, 각 연산의 반대 연산을 반환하는 메서드가 필요하다고 해보자. 다음은 이러한 효과를 내주는 정적 메서드다.
public static Operation inverse(Operation op) {
switch(op) {
case PLUS: return Operation.MINUS;
case MINUS: return Operation.PLUS;
case TIMES: return Operation.DIVIDE;
case DIVIDE: return Operation.TIMES;
default: throw new AssertonError("알 수 없는 연산: " + op);
}
}
추가하려는 메서드가 의미상 열거 타입에 속하지 않는다면 직접 만든 열거 타입이라도 이 방식을 적용하는 게 좋다. 종종 쓰이지만 열거 타입 안에 포함할 만큼 유용하지는 않은 경우도 마찬가지다.
대부분의 경우 열거 타입의 성능은 정수 상수와 별반 다르지 않다. 열거 타입을 메모리에 올리는 공간과 초기화하는 시간이 들긴 하지만 체감될 정도는 아니다.
| 그래서 열거 타입을 과연 언제 쓰란 말일까?
필요한 원소를 컴파일타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자. 본질적으로 열거 타입인 타입은 당연히 포함된다. 그리고 메뉴 아이템, 연산 코드, 명령줄 플래그 등 허용되는 값 모두를 컴파일타임에 이미 알고 있을 때도 쓸 수 있다. 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 열거 타입은 나중에 상수가 추가돼도 바이너리 수준에서 호환되도록 설계되었다.
