JS에서는 TDD를 어떻게 하고 계시나요?
Outsider
녕하세요.)
채수원님의 책을 읽고 TDD를 하기로 맘먹고 있다가 차일피일 미루는 것도 아닌것 같아서 주말용으로 만들고 있던 개인 프로젝트에
적용하기로 맘을 먹었습니다. 사실 처음부터 했어야 했는데 TDD책이 자바책이라 나중에 해야지 하다가 Javascript라도 해보
는게 낫겠다 싶어 뒤늦게 적용했습니다. 기능인 한 70%정도는 완성되었기 때문에 반정도는 유닛테스트적인 접근이라고 할수도 있는
데 고민해 본다는데 의의를 두려고 했습니다.
TDD는 jQuery에서 사용하고 있는 QUnit( http://docs.jquery.com/QUnit )을 적용했구요 가이드보
니까 그렇게 어렵지 않아서 바로 Qunit은 붙혔는데 실제 테스트코드를 작성하려다 보니까 많은 난관에 부딪혀서 결국 테스트메서드
를 하나도 작성하지 못했습니다.
1. 가장 큰 문제는 JS의 특성상 UI랑 커플링이 심하다는 것이었습니다. 예를 들어 diableAllInput이라든지 배열에
서 값을 가져와서 셀렉트박스의 option을 채워넣는다는 것들입니다.
JUnit같은 테스트와는 다르게 QUnit은 별도의 페이지에도 동작하기 때문에 해당테스트를 위해서는 원래 페이지에 있던 HTML
이 있어야만 테스트가 가능하다는 것이 일단 문제였고 그 담으로는 A라는 버튼을 jquery로 diable시켰는데 진짜
diable되었는지 확인하려다 보니 jQuery가 제대로 동작하는지 확인하는게 아닌가 하는 의문이 들었습니다. 함수의 결과가 리
턴이 아닌 HTML엘리먼트에 적용이 되는 것이다 보니 그 적용여부를 jquery나 다른 DOM API를 이용해서 확인해보아야 하
는데 이게 내 함수의 동작을 테스트하는건지 jQuery가 잘 동작했는지 확인하는 것인지가 애매하게 느껴졌습니다.
2. 리스너 등록. 요즘은 JS의 이벤트리스너 등록은 엘리먼트에서 안하고 JS에서 분리해서 하기 때문에 기본 이벤트리스너등록도
별도의 메서드로 분리했었는데 리스너가 제대로 등록되었는지 확인도 1번과 마찬가지로 jQuery의 동작여부를 확인하는것처럼 느껴졌
습니다.
3. 유저액션.... textarea에서 사용자가 엔터키나 컨트롤키를 눌렀을때 검사하는 메서드가 있는데 실제 메서드는 키코드를
받아서 13인지, 17인지를 검사하는게 다였습니다. 이걸 사용자가 키보드를 눌러서 테스트해야 하는데 TDD로 하려니 어려워서 함
수에 파라미터로 13이나 17을 넘겨서 테스트코드를 만들려고 보니 함수는 keycode === 17 해서 맞으면 true를 리턴
하고 아니면 false를 리턴하는데 이렇게 단순한걸 테스트할 필요가 있나 싶었습니다. 실제 유저액션에 대한 반응도 아니었고요 ㅡ
ㅡ;;
이렇다 보니 결과적으로 테스트 코드를 하나도 못짰습니다. ㅠㅠ
처음 적용해 보려는거다 보니 감을 잘못잡은건지 적용하기가 어려운 메서드들만 제가 가지고 있는 것인지 애매하더라구요.
채수원님께 유저액션은 테스트하기 어렵고 기능을 테스트하라는 조언을 듣기는 했는데 다른 한편으로는 테스트하기 어려우면 설계를 의심
해 보라고 하던데 설계가 잘못되었다고 해야할지 테스트하기 어려운 메서드들인지 잘 판단이 서지 않았습니다.
테스트할수 있게 설계를 바꿀까도 고민해보았지만 사이트용 JS인데 사용하는 엘리먼트들을 내부에서 지정하지 않고 파라미터로 다 넘기
고 테스트를 하기 위해서 초기화코드($(document).ready() 같은)를 다른 파일로 분리해내는 등의 작업들은 먼가 오버
엔지니어링인것 같은 느낌이 들었습니다.
좀 고민해본 느낌으로는 이렇게 사이트용 JS보다는 공통라이브러리용 JS를 쓸때 적합한게 아닐까 하는 결론에 다다르기는 했지만 실
제 작업에선 공통라이브러리보다는 일반(?) JS코딩 작업이 더 많기 때문에 다른 분들은 JS에도 TDD를 적용해서 사용하시는
지.. 사용하시면 어떤식으로 적용하시는지 조언을 좀 구해보려고 이렇게 장문의 글을 썼습니다.
긴글 읽어주셔서 감사합니다. ^^
김형진(Hyungjin Kim)
Gloridea
UI 유닛 테스트에서의 기준은, '최소의 코드로 최대한의 효율을' 인 듯합니다.
이건 어디에나 통하는 원칙이지만, UI 테스트 코드에서는 특히 버려야 할 걸 버리지 못하면 괴로움이 많아 지는 것 같습니다.
테스트의 기준은,
1. 잘못 짤 가능성이 있는 곳
2. 이 코드를 맡을 다른 누군가가, 나중에라도 변경하게 될 것 같은 곳
3. 그중에 테스트에 지나치게 많은 비용 안 쓸만한 곳
인 듯하고,
UI테스트에서는 '~이 되었다면 ~이 된 것으로 가정한다'는 식의 처리가 꽤 많이 들어가는 것 같습니다.
가령 innerHTML에 HTML을 대입하였다면, 엘리먼트가 생성되었는지 정도만 보고 정상적으로 생성되었다고 가정하는거죠.
그 이상은 정확도를 높이기도 어렵고, 또 투입하는 노력만큼 효율이 안 나는 것 같습니다.
그리고, 그 중 가장 유용한 방법은, DOM을 외부 리소스로 보고, 리소스에 접근을 담당하는 객체와,
나머지 로직을 담은 객체로 나누고, 전자를 Mock 처리하는 것인데,
이건 UI에 얼마나 복잡한 처리가 들어가느냐에 따라 의미가 있을 수도 있고, 그렇지 않을 수도 있습니다.
또, 얼마만큼의 품질을 확보하고 싶은지도 관건이 될 것 같습니다.
On Aug 9, 6:18 pm, Outsider <outside...@gmail.com> wrote:
> 어디에 질문을 올려야 하나 방황하다가 xper가 아무래도 나을듯해서 질문올려봅니다.(xper에는 처음 글 올려보는것 같네요. 안
> 녕하세요.)
>
> 채수원님의 책을 읽고 TDD를 하기로 맘먹고 있다가 차일피일 미루는 것도 아닌것 같아서 주말용으로 만들고 있던 개인 프로젝트에
> 적용하기로 맘을 먹었습니다. 사실 처음부터 했어야 했는데 TDD책이 자바책이라 나중에 해야지 하다가 Javascript라도 해보
> 는게 낫겠다 싶어 뒤늦게 적용했습니다. 기능인 한 70%정도는 완성되었기 때문에 반정도는 유닛테스트적인 접근이라고 할수도 있는
> 데 고민해 본다는데 의의를 두려고 했습니다.
>
> TDD는 jQuery에서 사용하고 있는 QUnit(http://docs.jquery.com/QUnit)을 적용했구요 가이드보