자바스크립트 도구 다루기

도구 다루기

자바스크립트 패턴과 테스트 2장의 내용을 요약한 글

테스팅 프레임워크(TDD)

---

TDD는 코드 결함을 최대한 빨리, 곧 코드 생성 직후 감지하며, 작은 기능 하나라도 테스트를 먼저 작성한 뒤, 최소한의 코드만으로 기능을 구현한다. 테스트를 먼저 작성하란 건  코드의 테스트성을 차후에 두고 볼 문제가 아니라 우선적인 주요 관심사로 생각하는 것이다. 어떤 코드의 테스트 용이성과 그 코드의 테스트가 얼마나 잘 이루어졌는지는 직접적인 상관 관계가 있다.

꼭 필요한 코드만 작성하기

작은 기능 하나를 검증하려면 실패하는 테스트를 먼저 작성한 뒤, 테스트를 성공시킬 만큼만 최소한으로 코딩한다. 그 후 내부적으로 구현 세부를 변경하는 리팩토링 과정을 거쳐 개발 중인 코드에서 중복 코드를 들어낸다.

안전한 유지 보수와 리팩토링

예전에 잘 돌아가던 코드가 지금은 제대로 작동하지 않는 회귀 결함은 코드 품질과 믿음성을 떨어뜨리는 요인이다

여타 보험 정책이 그렇듯, 혜택은 없고 짐만 되는 재발 비용이 발생한다. 단위 테스트의 경우 테스트 꾸러미를 개발/보수하느라 재발 비용이 들어가는데, 보험과 마찬가지로 이 재발 비용을 지불하는 부담에서 벗어나는 시점이 온다.

실행 가능한 명세

TDD 실천 결과, 탄탄하게 구축된 단위 테스트 꾸러미는 테스트 대상 코드의 실행 가능한 명세 역할도 한다. 재스민에서 스펙이라 부르는 개별 테스트는, 테스트하여 검증할 작동 로직을 이상문장으로 표현하면서 시작한다. 각 테스트를 실행할 때마다 이 문장들은 재스민의 테스트 결과 기본 포매터로 화면에 표시된다. 단위 테스트가 선사하는 '실행 가능 명세'는 프로젝트 참여 개발자에게도, 과거에 자신이 작성한 코드를 다시 찾아보게된 원래 개발자에게도 톡톡히 한몫한다.

최신 오픈 소스 및 상용 프레임워크

D.O.H / Qunit / jasmine

의존성 프레임워크(DI)

---

어떤 코드를 테스트할 때 그 코드가 어떤 다른 코드에 의존하고 있다면 구체화 시킨 코드를 의존하기 보다는 모의체같은 테스트성 코드를 통해서 의존하는 것이 한결 간단하다. 하드코딩된 의존성 주입이 아닌 전문가 다운 의존성 주입 프레임워크는 아래와 같이 작동한다.

1. 애플리케이션이 시작되자마자 각 인젝터블(주입 가능한 모든 의존성을 집합적으로 일컫는 말) 명을 확인하고 해당 인젝터블이 지닌 의존성을 지칭하며 순서대로 DI 컨테이너에 등록한다.

2. 객체가 필요하면 컨테이너에 요청한다.

3. 컨테이너는 일단 요청받은 객체와 그 의존성ㅇ르 모두 재귀적으로 인스턴스화한다. 그런 다음, 요건에 따라 필요한 객체에 각각 주입한다.

DI는 코드 재사용을 적극적으로 유도한다. 의존성을 품은, 하드 코딩한 모듈은 무거운 짐을 질질 끌고 다니는 터라 보통 재사용하기 여럽다.

다음 한 가지라도 Yes 라면 직접 인스턴스화하지 말고 주입하는 방향으로 생각을 전환하자.

• 객체 또는 의존성 중 어느 하나라도 DB, 설정 파일, HTTP,  기타 인프라 등의 외부 자원에 의존하는가?

• 객체 내부에서 발생할지 모를 에러를 테스트에서 고려해야 하나?

• 특정한 방향으로 객체를 작동시켜 할 테스트가 있는가?

• 이 서드파티 제공 객체가 아니라 온전히 내가 소유한 객체인가?

최신 의존성 주입 프레임워크

리콰이어JS / 앵귤러JS

Aspect Tool Kit(AOP)

---

AOP는 단일한 책임 범위 내에 있지 않은 하나 이상의 객체에 유용한 코드를 한데 묶어 눈에 띄지 않게 객체에 배포하는 기법이다.

AOP용어

어드바이스(advice) : 배포할 코드 조각

애스펙트(aspect) 혹은 횡단 관심사(cross-cutting concern) : 어드바이스가 처리할 문제

AOP로 믿음직한 코드 만들기

• AOP는 함수를 단순하게 유지한다. 함수 각자의 단일 책임을 수행할 뿐이다. 단순함은 곧 믿음성이다.

• AOP는 코드를 DRY하게 해준다. 어떤 코드가 여기저기 출몰하면 나중에 다른 개발자가 잘 못 건드릴 여지도 많고, 그러다 보면 동기화가 꺠질 가능성이 당연히 커진다

• AOP는 애플리케이션 설정을 한 곳에 집중시칸다. 애스팩트 설정이 단일 책임인 함수가 하나만 있으면 부속 기능 전체를 찾을 때 이 함수만 뒤지면 된다. 무엇보다 디버깅할 때 손쉽게 캐싱 같은 기능을 끄거나 인자 체크 기능을 켤수 있어 좋다. 엔드 유저의 기호에 따라 활성/비활성화하고 싶은 애스팩트도 있을 것이다.

AOP 라이브러리

aop.js / 애스펙트JS / AopJS 제이쿼리 플로그인 / YUI Do 클래스

자바슼립트 AOP는 구현하기 쉽지만, 쓸만한 도구는 그리 많지 않다. 하지만 그리 심각한 문제는 아니다. 덩치 큰 라이브러리 개발은 중단됐으나, 업데이트할 일 거의 없이 최소한의 필수 기능만 구현된 대체 라이브러리가 있다.

코드 검사 도구

---

코드 검사 도구는 코드를 실행하지 않은 상태에서 소스 코드의 구조/구문을 조사하는 , 정적 분석을 수행한다. 코드 실행 시 에러가 날 것 같은, 프로그래밍 언어를 부정확하게 사용한 곳을 찾아 알려주는 일이 주된 임무다.코딩 스타일 규칙을 어긴 코드를 찾아내면서 계산 복잡도 같은 유용한 지표를 보고하는 정적 분석 도구도 있다.

린팅은 특히 자바스크립트 코딩 시 긴요하다. C#/자바 출신 개발자는 문장 끝에 세모콜론을 빠뜨리거나 중괄호를 닫지 않는 식의, 허용되지 않는 구문 에러를 컴파일러가 알려주는 데 익숙하다. 인터프리터 언어인 자바스크립트는 개발자가 실수해도 뭐라고 얘기해주는 컴파일러가 없어서 코드를 실행해 보기 전에는 구문 에러를 알 길이 없다.

제품 코드를 작성하기 전에 한 조각씩 일일이 테스트를 작성하며 확인하는 TDD 방식으로 개발하면, 코드가 제대로 잘 작동함을 단위 테스트로서 밝힐 수 있으므로 굳이 린터까지 설정하고 사용해야 하나 하는 귀찮은 생각이 들지 모른다.

린터는 코드의 정확성을 판별하는 도구가 아니다. 함수가 정확한 값을 반환하는지도 알 수 없다. 함수 안에 써넣은 코드가 의심스러운 모습을 띠고 있어서 혹여 이상한 값이 반환될지도 모른다는 귀띔을 할 뿐이다.

JSHint 대체 도구 및 모드

JSLint / ESLint / 엄격 모드('use strict')