[Django] Unit Test 기본 정보
Django의 유닛테스트 기본기.
Django는 project나 app을 생성하게 되면 기본적으로 tests.py라는 파일이 생성된다. 이 파일은 unit test 코드를 이 파일에 작성하라는 의도로 보면 된다.
(unit test가 뭔지에 관해서는 ‘unit test’ 혹은 TDD – Test Driven Development – 에 관해서 검색해 보는 편이 좋다. 혹은 XP개발론 – 정확히 eXtreme Programming – 에 대해 알아보는 것도 좋다)
기본적으로 Python의 Unittest와 동일하게 작성하면 된다.
unittest를 구동하기 위해서는 project를 생성하면 함께 생성되는 manage.py를 이용하면 된다.
이렇게 하면 Django 자체 테스트와 함께 사용자가 구축해놓은 tests.py도 함께 실행시켜서 테스트를 하게 된다. 하지만 자체테스트가 굉장히 크기 때문에 좀 오래 걸릴 수도 있다.
테스트 시에는 Test용 Database를 따로 생성하게 된다. 따라서 해당 사용자는 해당 Test용 Database의 생성/수정/삭제 권한을 가지고 있어야만 한다. 테스트가 끝나면 해당 Test DB는 삭제된다. 만약 기존에 테스트를 중단시켜서 Test DB가 존재하는 상태로 유닛테스트를 실행시키면 기존의 Test DB를 삭제하고 다시 생성시킨다.
테스트 시 오류가 발생하면 self.assertTrue가 Exception을 발생시키기 때문에 실패한 부분을 찾기 쉽다.
만약 project 내에 앱(app)이 하나 이상 존재한다면 특정 app 만을 테스트 할 수 있다. app을 생성하면 각 app 디렉토리 내에도 tests.py가 생성된다는 것을 기억하자.
이렇게 실행시키면 해당 app의 tests.py만을 unittest하게 된다. 장점으로, Django 자체 테스트를 수행하지 않기 때문에 테스트가 굉장히 빨리 끝난다.
물론 Tests.py 파일을 모듈로 분리해서 파일을 여러개로 모듈화 할 수도 있다.
덤으로 Unit Test 코드를 작성할 때 약간의 팁.
테스트 순서는 기본적으로 클래스(class)나 메서드(method)의 이름에 의존된다. 만약 순차적으로 실행되어야 할 테스트가 있다면 class와 method의 이름에 고유번호를 메기는 식으로 순차적으로 실행될 수 있도록 배려하는게 중요하다. (오름차순 정렬이라는 것을 생각하자)
개인적으로는 class와 method이름을 지을 때 항상 고유번호를 부여한다.
Django는 project나 app을 생성하게 되면 기본적으로 tests.py라는 파일이 생성된다. 이 파일은 unit test 코드를 이 파일에 작성하라는 의도로 보면 된다.
(unit test가 뭔지에 관해서는 ‘unit test’ 혹은 TDD – Test Driven Development – 에 관해서 검색해 보는 편이 좋다. 혹은 XP개발론 – 정확히 eXtreme Programming – 에 대해 알아보는 것도 좋다)
기본적으로 Python의 Unittest와 동일하게 작성하면 된다.
import unittest class TestClass1(unittest.TestCase): def test1(self): self.assertTrue(...) self.assertFalse(...) ...이런 형식이다.
unittest를 구동하기 위해서는 project를 생성하면 함께 생성되는 manage.py를 이용하면 된다.
python manage.py test
이렇게 하면 Django 자체 테스트와 함께 사용자가 구축해놓은 tests.py도 함께 실행시켜서 테스트를 하게 된다. 하지만 자체테스트가 굉장히 크기 때문에 좀 오래 걸릴 수도 있다.
테스트 시에는 Test용 Database를 따로 생성하게 된다. 따라서 해당 사용자는 해당 Test용 Database의 생성/수정/삭제 권한을 가지고 있어야만 한다. 테스트가 끝나면 해당 Test DB는 삭제된다. 만약 기존에 테스트를 중단시켜서 Test DB가 존재하는 상태로 유닛테스트를 실행시키면 기존의 Test DB를 삭제하고 다시 생성시킨다.
테스트 시 오류가 발생하면 self.assertTrue가 Exception을 발생시키기 때문에 실패한 부분을 찾기 쉽다.
만약 project 내에 앱(app)이 하나 이상 존재한다면 특정 app 만을 테스트 할 수 있다. app을 생성하면 각 app 디렉토리 내에도 tests.py가 생성된다는 것을 기억하자.
python manage.py test AppName
이렇게 실행시키면 해당 app의 tests.py만을 unittest하게 된다. 장점으로, Django 자체 테스트를 수행하지 않기 때문에 테스트가 굉장히 빨리 끝난다.
물론 Tests.py 파일을 모듈로 분리해서 파일을 여러개로 모듈화 할 수도 있다.
덤으로 Unit Test 코드를 작성할 때 약간의 팁.
테스트 순서는 기본적으로 클래스(class)나 메서드(method)의 이름에 의존된다. 만약 순차적으로 실행되어야 할 테스트가 있다면 class와 method의 이름에 고유번호를 메기는 식으로 순차적으로 실행될 수 있도록 배려하는게 중요하다. (오름차순 정렬이라는 것을 생각하자)
개인적으로는 class와 method이름을 지을 때 항상 고유번호를 부여한다.
class Test00Basic(unittest.TestCase): def test0000LibraryAAA(self): .... def test0001LibraryBBB(self): ... class Test01OtherLibrary(unittest.TestCase): def test0100ABC(self): ...테스트 파일을 여러개로 분할했을 경우 class이름도 순차적으로 실행되도록 하려고 하는데, 사실 순서 결정은 class이름 보다는 method에 크게 적용받는 다고 생각된다. 뭐 정리만 잘 하면 크게 문제될 것은 없겠지만…
댓글