| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
- 한빛미디어
- 쇠막대기
- 프로그래머스
- 놀이동산의슈퍼컴퓨터를작동시켜라
- tacotron
- 개발자회고
- 2019회고
- 신영준
- machinelearning
- 개발자를위한파이썬
- CrossAngle
- 서버로그
- intell
- graphicdriver
- 봉사활동
- 타코트론
- jaypark.dating
- 서구동구예비군훈련장
- 인천남중
- 인하대학교
- Xangle
- 우분투비트확인
- 결과를얻는법
- 노트북덮개
- 심플소프트웨어
- 로그남기기
- 나는리뷰어다
- 인하멘토링
- 프로그라피
- texttospeech
- Today
- Total
jc.jang
TDD with Python 1, 2, 3장 본문
후기
아직 3장까지 읽지 않았지만 책을 읽는 내내 지루하지는 않을 것 같다는 생각이 들었다. 책의 저자가 독자에게 말하는 듯한 느낌을 주려고 한 것 같다. 짝 프로그래밍을 하다 보니 혼자 책 쓰는 게 심심해서 그랬던 것으로 추측된다. 나는 TDD를 그저 개발 방법론 중 하나, 컨퍼런스에서 발표하기 좋은 주제 정도로만 알고 있었고 실제로 그렇게 (시도는 했지만) 개발하고 있지는 않다. 이 책이 2015년에 나온 책이다보니 틀린 내용이 있을 수도 있다. 저자는 일종의 버그를 찾고 해결하는 것에 희열을 느끼라고 말했는데 그래야겠다. 다음은 내가 기억하기 위해 혹은 잘못된 내용을 고치기 위해 기록한 내용이다.
단위 테스트는 무엇이고, 기능 테스트와 어떤 차이가 있을까?
테스트면 테스트지 테스트에도 종류가 있을지 몰랐다. 이 책에서는 다양한 용어를 다루다 보니, 용어를 정리하고 가야 할게 좀 있다. 기본적인 차이는, 기능 테스트는 사용자 관점에서 애플리케이션 외부를 테스트하는 것이고, 단위 테스트는 프로그래머 관점에서 그 내부를 테스트하는 것이다.
이 책에서 다루는 TDD 접근법은 양쪽 테스트를 모두 적용한다. 이후 작업 순서는 다음과 같다.
1. 기능 테스트를 작성해서 사용자 관점의 새로운 기능성을 정의하는 것부터 시작한다.
2. 기능 테스트가 실패하고 나면 어떻게 코드를 작성해야 테스트를 통과할지를 생각해보도록 한다. 이 시점에서 하나 또는 그 이상의 단위 테스트를 이용해서 어떻게 코드가 동작해야 하는지 정의한다.
3. 단위 테스트가 실패하고 나면 단위 테스트를 통과할 수 있을 정도의 최소한의 코드만 작성한다. 기능 테스트가 완전해질 때까지 과정2와 3을 반복해야 할 수도 있다.
4. 기능 테스트를 재실행해서 통과하는지 또는 제대로 동작하는지 확인한다. 이 과정에서 새로운 단위 테스트를 작성해야 할 수도 있다.
이 과정을 잘 보면, 기능 테스트는 상위 레벨의 개발을 주도하고 단위 테스트는 하위 레벨을 주도한다는 것을 알 수 있다.
Django의 MVC, URL, 뷰 함수
3장에서 Django는 대체로 모델-뷰-컨트롤러라는 고전적인 패턴을 따른다. '대체로'라는 표현에 주목하자.
Django는 MTV라는 패턴을 따르는데, 이에 대해 문서에 잘 나와있다.
FAQ: General | Django documentation | Django
Django The web framework for perfectionists with deadlines. Overview Download Documentation News Community Code Issues About ♥ Donate
docs.djangoproject.com
장고는 MVC 프레임워크인 것처럼 보이지만 컨트롤러를 뷰, 뷰를 템플릿이라고 합니다. MVC라는 표준 이름을 따르기에는 논란의 여지가 있습니다.
뷰는 사용자에게 보일 데이터를 서술합니다. 이것은 어떻게 데이터를 볼 건지가 아니라 어떻게 보여질건지를 뜻합니다. 뷰는 당신이 어떻게 데이터를 볼건지가 아니라 어떤 데이터를 볼건지 서술합니다. 이것은 미묘한 차이가 있습니다.
따라서 장고의 경우 뷰는 특정 URL에 대한 Python 콜백 함수입니다. 콜백 함수는 어떤 데이터가 보여질 지를 서술하기 때문입니다.
또한 템플릿과 함께 제공되는 프레젠테이션과 컨텐츠를 분리하는 것이 합리적입니다. Django에서 뷰는 어떤 데이터가 보이는가에 대해 서술하지만 일반적으로 뷰는 데이터가 보여지는 방법을 설명하는 템플릿에 위임됩니다.
그렇다면 컨트롤러는 어디에 적합합니까? Django의 경우 프레임워크 자체일 것입니다. Django URL 구성에 따라 요청을 적절한 보기로 보내는 장치입니다.
FAQ를 해석해봤는데 뭔가 잘 와 닿지 않는다. 하고 싶은 말은 뷰는 어떻게 보여질 건지, 어떤 데이터를 볼 건지 서술한다는 말 같다.
-m 옵션은 커밋 메시지를 커맨드 라인상에서 바로 추가할 수 있게 해 준다.
맞는 말이다. 하지만 커밋 메시지를 작성할 때, 터미널보다는 에디터를 사용하는 것이 좋다고 `git-style-guide`에 나와있다. 터미널을 통한 커밋은 한 줄에 모든 것을 써야 할 것처럼 느껴지고, 이렇게 작성하면 정보가 없고 모호한 커밋을 작성하기 쉽다. 자세한 깃 스타일 가이드는 아래 링크를 참고하자.
https://github.com/ikaruce/git-style-guide#messages-%EB%A9%94%EC%8B%9C%EC%A7%80
트레이스백 읽기
잠시 시간을 내서 트레이스백(Traceback)을 어떻게 읽어야 할지 얘기해보자. 트레이스백은 TDD에 있어 중요한 역할을 하는 것으로 자주 접하게 된다. 트레이스백을 빠르게 읽어서 필요한 단서를 찾는 방법을 금방 배울 수 있다.
3, 4 가장 먼저 확인해야 할 것이 '에러'다. 이 코드에서는 AttributeError다. 이 에러 부분이 핵심인데, 어떤 때는 이 부분만 읽고 바로 문제를 파악할 수 있다. NoneType 객체는 content라는 속성이 없다는 것으로 보아 response에 내가 원하는 결과가 저장되지 않고 NoneType 객체가 저장되었다는 것을 알 수 있다. 혹시나 이 에러만으로 충분한 문제 파악이 어렵다면 맨 위로 올라간다.
1. 다음으로 확인할 것은 "어떤 테스트가 실패하고 있는가?"다. 이 실패가 예측된 실패인지를 확인해야 한다. test_home_page_returns_correct_html을 수행하던 중 에러가 발생했다.
2. 마지막으로 실패를 발생시키는 "테스트 코드"를 찾는다. 트레이스백 상단부터 아래로 내려가면서 테스트 파일명을 찾는다. 그래서 어떤 테스트 함수의 몇 번째 코드 라인에서 실패가 발생했는지 확인한다. 이 예에선 response의 content가 <html>로 시작하는지 확인하는 부분이다.
문제 있는 코드를 확인할 때 일반적으로 사용하는 4단계 과정이 있다. 이후로 계속 이 4단계 과정을 통해 Django 코드를 확인하는 것을 보게 될 것이다.
'개발 > Test-Driven Development with Python' 카테고리의 다른 글
| TDD with Python 7장 (0) | 2020.01.21 |
|---|---|
| TDD with Python 6장 (0) | 2020.01.09 |
| TDD with Python 5장 (0) | 2019.12.19 |
| TDD with Python 4장 (0) | 2019.12.18 |
