①
자동화 테스트(Automated Testing) 소개
・테스트 자동화
소개 : 자동화 테스트란?
테스트는 작성한 코드를
확인하는 과정을 말한다.
테스트는 다양한 수준(level)에서 시행 된다.
한 개의 모듈을 테스트하는
단위 테스트(Unit
Test) 부터
시스템의 인터페이스와
모듈들을 테스트 하는 통합 또는
단체 테스트(Integration Test) 등
다양한 관점에서 테스트를
시행 한다.
예전에 튜토리얼②에서 Python의 Shell을 사용해서
메소드나 애플리케이션을 실행해보고
어떻게 동작하는지
확인하기 위해
데이터를 입력해서
테스트했던 것과 비슷하다.
자동화 테스트(Automated
Testing)의 장점은
테스트
작업이 구현한 시스템에서 수행된다는 점이다.
한 번 테스트 셋(set)
즉, 테스트 코드를 작성한
이후에는 App을 변경할 때
print와 같이 수동으로
테스트를 하지 않아도 테스트가 가능하다.
Java에서 Junit이 여기에 속한다.
・테스트 자동화
소개 : 자동화 테스트를
해야만 하는 이유
물론 사람에 따라서 Python/Django를 배우는 것만으로도
충분하며,
자신의 목표는 단순이 App을 만드는게 목표라면
이 자동화 테스트가 필요없다고 생각할 지도 모른다.
하지만 테스트 자동화
코드를
만들어 놓으면 여러가지 이점이 있다.
첫번째, 자동화 테스트를 통해
시간을 절약할 수 있다.
시스템이 작다면 단순히
“제대로 동작하는지
확인”하는 것만으로도 충분할
수도 있다.
하지만 보통 시스템은
굉장히 복잡하며,
시스템 안에서는
수많은
모듈이 상호작용을 하고 있을 것이다.
이러한 시스템에서
한 개의 모듈안의 코드를 수정하는 것은
치명적인 오류를 야기할 수 있다.
따라서 수정한 모듈이
정상적으로 작동하는지 확인하려면
수십개의 테스트 코드를 만들어야
오류가 없음을 확인할
수 있을 것이다.
하지만 이를 자동화
테스트를 사용한다면,
무언가 잘못되어도
이 테스트를 통해
오류를 야기할 수
있는 코드를 식별하는데 도움이 된다.
이런 테스트가 개발에
무슨 도움이 되냐고 하는 사람들도 있겠지만,
수동으로 테스트 코드를
작성하거나, 테스트를 하지 않아
치명적인 오류를 발생시킬 수 있는 리스크를 줄이기 위해
단 한번의 자동화
테스트 코드를 작성하는 것이 훨씬 시간적으로 이득이다.
두 번째, 자동화 테스트를 통해
버그를 식별할 수 있고 치명적인 버그를 예방할 수 있다.
자동화 테스트 뿐만
아니라
테스트를 한다면 얻을 수 있는 이득이다.
아무리 자신이 그
모듈이 작성했다고 해도,
예상한대로 결과 값을
출력하라는 보장은 없다.
따라서 테스트를 하지
않으면,
예상과 다른 결과가
시스템을 망치는
치명적인 버그를 발생시킬 수 있다.
세 번째, 자동화 테스트를 통해
코드를 더 신뢰성 있는 코드로 만들어 준다.
(Tests
make your code more attractive)
자기 자신 스스로가
훌륭한 소프트웨어 혹은
모듈을 만들었다고 생각할지는 모르겠지만
다른 개발자들은 실제
그게 어떻게 출력되어지는지
알 수 없기 때문에 신뢰하지 않을 것이다.
따라서 테스트한 결과는
훌륭한 소프트웨어 혹은
모듈을 만들었다는 주장의 증거가 될 것 이다.
네 번째, 자동화 테스트를 통해
다른 팀원들과 커뮤니케이션을 원할하게 할 수 있다.
이전까지 예제는 애플리케이션을
유지 관리하는 단일 개발자 관점에서 작성되었다.
하지만, 실제 프로젝트에서는
팀으로서 일을 하기 때문에
자동화 테스트는 동료가
코드를 손상시키지 않았음을 보증해 줄 것이다.
② 첫 번째 테스트 작성하기
・첫 번째 테스트
작성하기 : 버그를 노출하는
자동화 테스트 만들기
사실 def
was_published_recently(self)라는 메소드에는 버그가 있는데,
pub_date의 필드가 미래로
설정되어 있을 때
즉, 미래의 시간임에도
최근이냐고 묻는 메소드에서 true가 나온다는 버그이다.
그럼 아래와 같은
자동화 테스트 코드를 작성해 실제로 그런지 확인해보자.
테스트 결과는 아래의
사진과 같다.
이 자동화 테스트를
수행하는 동안 아래와 같은 프로세스를 거쳤다.
1. Manage.py test pollssms polls 애플리케이션에서 테스트(test.py파일)를 찾는다
2. djnago.test.TestCase클래스의 서브 클래스를 찾는다.
3. 테스트 목적으로 특별한 데이터베이스를 만든다.
4. 테스트 메소드 – 이름이 test로 시작하는 것들을
찾는다.
5. test_was_published_recently_with_future_question에서 pub_date필드가
30일 미래인 Qusetion
인스턴스를 생성한다.
6. assertIs() 메소드를 사용하여, 우리가 False가 반환되기를 원함에도
Was_published_recently()가 True를 반환한다는 것을
발견했다.
테스트 결과 역시
미래의 값을 넣어 줬음에도
False가 아닌 True값이 나온 것을 확인
할 수 있다.
이제 버그가 있다는
것을 확인 했으니 버그 수정을 해보자.
메소드를 위와 같이
수정 한 후, 다시 테스트를 해보자.
테스트 결과 OK가 나온 것을 확인
할 수 있고,
해당 메소드에는 문제가
없음을 확인 했다.
앞으로 다른 많은
App(polls와 같은)이 잘못 될 수도
있다.
하지만 다시는 동일한
버그가 나타나지 않을 것이라 확신할 수 있다.
왜냐하면 테스트를
실행하면 즉시 경고가 표시될 것이기 때문이다.
따라서 App안의 이 작은 부분(모듈)은 자동화 테스트를
작성함으로써
영원히 안전하게 고정된
것으로 간주 할 수 있다.
・첫 번째 테스트
작성하기 : 보다 포괄적인
테스트
was_published_recently() 메소드를 고정하는
것 이상을 할 수도 있다.
만약 하나의 버그를
고치면서
다른 새로운 버그를 만들어 낸다면
버그를 고친 의미가 없을 것이다.
따라서 이 메소드의
동작을 보다
포괄적으로 테스트하기 위해
동일한 클래스에 두 가지 테스트 메소드를
추가해보자.
위의 recent,
futrue의
자동화 테스트
코드를 추가로 작성함으로써
old,
recent, futrue라는 미래에 대한
테스트코드 뿐만 아니라
현재, 미래에 대해서도
올바른
값을 반환하는지를 확인 시켜주는
자동화 테스트 할
수 있게 되었다.
실행 결과는 아래의
사진과 같다.
물론 아까와 다르게
코드 안에 버그가 없기 때문에
어떠한 표시 없이
default라고 나오지만,
작성한 3가지의 test들이 정상적으로 작동하고
있는지는 확인해 볼 수 있다.
③ 뷰 테스트
예제 설문 조사 앱인
polls는 매우 어설프게
만들어져 있다.
현재까지의 설문 조사
예제 앱의 pub_date필드는
미래의 있는
질문 까지도 포함하게 하지만,
이것을 개선해 pub_date
필드가 미래일 경우
그 날이 오기 전까지는
보이지 않게 해야 한다.
・뷰에 대한
테스트
위에서 버그를 수정했을
때
먼저 테스트를 작성하고, 버그를 수정했었다.
사실 그러한 방식은
테스트 중심의 개발 방법이며,
어떤 순서로 하는지는
그리 중요하지 않다.
첫 번째 테스트에서는
코드의 내부 동작에 대해 초점을 맞추었지만,
이번 테스트에서는
웹 브라우저를 통해
실제 사용자가 경험하게
되는 동작을 확인하려고 한다.
・장고 테스트
클라이언트
Django는 뷰 레벨에서의
코드와
상호 작용하는 사용자를
시뮬레이트 하기 위한
테스트 클라이언트
클래스 Clinet를 제공한다.
이 테스트 클라이언트를
tests.py 또는 shell에서 사용할 수 있다.
따라서 또 다시 shell에서 작업을 하게
될것이며,
Tests.py 에서 필요하지 않았던
두 가지 일을 해야만 한다.
첫번째는 shell에서 테스트 환경을
구축하는 것이다.
먼저 명령 컴포넌트에서
빨간색 박스와 같이shell을 실행해준다.
Shell이 실행됐다면,
초록색 박스와 같이
setup_test_environment라는 이름의 템플릿 렌더러를 설치하도록
하자.
이 메소드는 따로
테스트용 데이터베이스를 만들지 않으며,
현재 사용중인 데이터베이스에
저장되어져 있는 데이터를 이용 한다.
또한 settings.py의 TIME_ZONE이 올바르지 않다면
에러가 발생할 수
있기 때문에
초기에 어떻게 설정해놨는지
기억나지 않는다면
앞을 진행하기 전에
먼저 확인하는 것이 좋다.
다음으로 테스트 클라이언트
클래스를 import해야 한다.
위의 갈색 박스와
같이 입력했다면
이제 준비는 완료되었다.
