기능 테스트 내에서 격리
고전적인 테스트 문제를 남겨두고 왔다. 테스트와 테스트 사이에 발생하는 "격리" 문제와 관련이 있다. 기능 테스트를 실행할 때마다 앞 테스트의 목록 아이템이 테이터베이스에 남아있다. 이것은 다시 다음 테스트 결과 해석을 방해하게 된다.
단위 테스트를 실행하면 django 테스트 실행자가 자동으로 새로운 테스트 데이터베이스(실 데이터베이스와 별도로)를 생성한다. 이를 통해 개별 테스트 실행 시마다 안전하게 데이테베이스가 초기화 된다. 하지만 현재 기능 테스트는 "실제" 데이터베이스인 db.sqlite3를 이용하고 있다.
django에서 제공하는 LiveServerTestCase라는 클래스를 이용해서 이 문제를 해결할 수 있다. 이것은 자동으로 테스트용 데이터베이스를 생성하고(단위 테스트와 만찬가지로) 기능 테스트를 위한 개발 서버를 가동한다. 몇 가지 제한사항이 있어서 별도 작업이 필요하다.
LiveSercerTestCase는 django의 manage.py를 이용해서 실행할 수 있다. django는 'test'로 시작하는 파일을 자동으로 찾는다. 깔끔한 작업을 위해서 기능 테스트용 폴더를 만들도록 한다. 즉 테스트를 앱으로 만드는 것과 같다. 이폴더를 django가 인식하게 하려면, 유효한 파이썬 패키지 디렉토리로 만들어주면 된다.
$ mkdir fuctional_tests
$ touch functional_tests/__init__.py기능 테스트 파일 functional_test.py를 fuctional_tests 앱의 tests.py 파일로 이동한다.
$git mv functional_test.py functional_tests/tests.py수정
LiveServerTestCase를 사용하기 위해 임포트하고 상속받는다.
포트 8000번을 이용하는 로컬 호스트 접속을 하드코딩하는 대신에 LiveServerTestCase가 제공하는 live_server_url 속성을 이용한다.
이제 django의 테스트 실행자를 이용해서 기능 테스트를 실행할 수 있다. functional_test 앱에 대해 test를 실행하면 된다.
테스트를 여러번 실행해도 이전에 생성된 목록 아이템이 남아있지 않다는 것을 알 수 있다. 테스트 후에 결과물을 삭제한 것이다.
커밋
$ git commit -m 'functional_tests 앱 생성 및 LiveServerTestCase 사용'필요한 경우에는 최소한의 설계를
TDD는 애자일(Agile)개발 방법과 밀접한 관련이 있다. 개발 초기 단계에 요구사항 분석과 설계에 많은 시간을 할애하는 것이 전통적인 소프트웨어 공학인데, 이에 상반된 방법론이 애자일이다. 애자일은 이론보다는 실제 상황을 통해 문제를 해결하려는 것을 근간으로 하고 있다. 특히 가능한 빨리 사용자가 애플리케이션을 접할 수 있도록 하는 것이 특징이다. 긴 설계 과정 대신에 "동작하는 최소한의 애플리케이션"을 빠르게 만들고, 이를 이용해서 얻은 실제 사용자 의견을 설계에 점진적으로 반영해 가는 방식이다.
하지만 이것이 설계에 대해 생각하지 않아도 된다는 것을 의미하는 것은 아니다.
"최소한의 기능을 가진 작업 목록 앱"을 어떻게 설계할 지 생각해보도록 하자.
- 각 사용자가 개별 목록을 저장하도록 한다.
- 하나의 목록은 여러 개의 작업 아이템으로 구성된다. 이 아이템들은 작업 내용을 설명하는 텍스트다.
- 다음 방문 시에도 목록을 확인할 수 있도록 목록을 저장해두어야 한다. 현 시점에선 각 목록에 해당하는 개별 URL을 사용자에게 제공하도록 한다. 이후에는 사용자를 자동으로 인식해서 해당 목록을 보여주도록 수정할 필요가 있다.
YAGIN
설계에 대해 한 번 생각하기 시작하면 생각을 멈추는 것이 쉽지 않다. YAGIN는 "You ain't gonna need it"의 약자다. 소프트웨어 개발자로서 우리는 무언가 만드는 것을 즐긴다. 또한 아이디어가 생각나서 그것을 직접 구축해보고 싶어서 안달이 나는 경우도 있을 것이다. 하지만 대개는 그걸 사용하지 않고 끝나는 경우가 많다. 오히려 사용하지 않는 코드로 가듣 차서 애플리케이션이 복잡해지기도 한다.
REST
REST(Representational State Transfer)는 웹 설계 방법 중 하나다. 일반적으로 웹 기반 API를 이용해서 설계하도록 유도한다. 사용자 중심의 사이트를 설계할 때는 REST규칙을 엄격히 적용하는 것이 어렵지만,, 그래도 설계에 도움이 되는 좋은 힌트를 준다.
REST는 데이터 구조를 URL 구조에 일치시키는 방식이다. 이 앱에선 작업 목록과 아이템을 URL 구조로 표현할 수 있다. 각 목록은 다음과 같이 개별 URL을 가진다.
목록(list)를 보려면 GET요청(브라우저를 이용한 일반적인 페이지 접속)을 사용한다.
/lists
새로운 목록을 만드려면 다음과 같은 URL을 사용해서 POST 요청한다.
/lists/new
기존 목록(list)에 새로운 작업 아이템 추가
/lists/<목록 식별자>/add_item
REST 규칙을 완벽하게 따르진 않았다. 원래 REST는 POST 대신에 PUT을 사용한다.
TDD를 이용한 새로운 설계 반영하기
작업 메모장
FT가 끝난 후에 결과물을 제거한다.- 모델을 조정해서 아이템들이 다른 목록과 연계되도록 한다.
- 각 목록별 고유 URL을 추가한다.
- POST를 이용해서 새로운 목록을 생성하는 URL을 추가한다.
- POST를 이용해서 새로운 아이템을 기존 목록에 추가하는 URL을 만든다.
