테스트 코드의 디자인에 대해 생각하다

개시하다

현대 개발에서 자동 테스트 코드는 필수적이다.하지만 그 테스트 코드의 디자인을 전달하기는 어려울 것 같습니다.이 글에서 나는 테스트 코드를 어떻게 쓰는지, 어떤 테스트 코드를 쓰는지, 어떤 테스트 코드를 쓰지 않는지 기록할 것이다.

전제 조건

이 글은 자신의 경험을 바탕으로 한 것으로 다음과 같은 몇 가지에 의존하는 글이다.

코드 검사 가능한 팀 개발

파이톤+Django 개발

정적 유형 언어 등은 적용되지 않을 수 있습니다.

기능 테스트만

반대로 E2E 테스트와 비기능 테스트 등을 제외하면

이 문장은 기본적으로 아래의 내용을 쓰지 않는다.

테스트 코드의 실제 쓰기

시험에 통과하는 것을 목적으로 하지 않다

너무 당연하다고 말할 필요는 없지만 시험에 통과하는 것을 목적으로 해서는 안 된다.만약 시험에 통과하지 못한다면 테스트 코드나 실제 코드는 모두 잘못된 것이다.모르면 솔직하게 물어봐.만약 누군가가 숨긴다면, 모두 파괴될 것이다.
실제로 그런 일을 해본 사람은 만나보지 못했지만 신뢰의 전제이기 때문에 일부러 썼다.
또'통상 발생하지 않는 예외'등은 무리하게 시험에 통과할 필요가 없다.통과할 필요가 없는 곳은 아래 기사에 구체적으로 기재되어 있다.
https://zenn.dev/ikemo/articles/test-coverage-100-percent#표준 100% 무시

학습 테스트 디자인

코드로 테스트를 쓰는 시대가 와도 기본적인 테스트 디자인은 변하지 않는다.나는 이 책에서'당직 시험','경계치 시험'등 기본적인 생각을 배웠는데, 지금도 반드시 갖추어야 한다.
https://amzn.to/3HFyPDS
원리적으로 측정 코드 커버는 정음 테스트를 하면 테스트 부족을 감지할 수 있지만 정음 테스트가 너무 느려서 실제 개발에서 사용한 적이 없다.

모든 서류는 한 상자를 통과한다

파이톤의 고유한 문제일 수 있다고 생각합니다. 과거에 Django 3.0이 3.1로 높아졌을 때 움직일 수 없는 기능이 있었습니다.그것의 기능은 Django의 명령이지만 가져오는 형식이 부적절하고 Django의 내부 구현에 의존한다.
예를 들어 django.http.response.HttpResponseRedirect를 사용할 때도 다음과 같다.그러나 이는 항상 Django의 설치에 의존하기 때문에 버전 업그레이드 후에는 사용할 수 없을 수도 있습니다.이런 작법은 문제가 있다.

from django.views.generic.edit import HttpResponseRedirect

전체 파일 테스트가 없기 때문입니다.그러나 시험을 치러 갈 시간이 충분하지 않다.이에 따라 최소한 import 테스트는 가능하다고 추가됐다.

'논리'와'애매모호'중 어느 것을 의식하다

나는 시험에는 주로 두 가지 목적이 있다고 생각한다.하나는 논리 테스트야.예를 들어 윤년의 판단 논리에 대해'4를 나눌 수 있을까','100을 나눌 수 있을까','400을 나눌 수 있을까'라는 테스트를 추가한다.나는 이것이 매우 이해하기 쉽다고 생각한다.
또 하나는'회복제'다.오류 방지 장치는 부주의를 방지하는 장치다.
https://ja.wikipedia.org/wiki/이끼
예를 들어 방금 기재된 Django3.1에서 움직이지 않는 기능은'포카'다. 이런 상황을 방지하기 위해'적어도 import에서 할 수 있는 테스트'는'포카요크'다.이외에도 팩스 조작을 더욱 쉽게 하기 위한 테스트도 가장 좋은 테스트 중 하나라고 할 수 있다.
물론 이 두 개는 자주 겹친다.그러나 이 두 가지를 따로 쓰는 이유는 어디에 쓰는 것이 좋을지, 어느 수준이 좋을지 다르기 때문이다.

논리가 같은 층에 테스트를 쓰다

우선 논리는 모델에 최대한 가깝게 써서 의존성을 줄여야 한다.구체적으로 다음 기사에서 설명하겠습니다.
https://zenn.dev/ikemo/articles/django-keep-away-from-fat-model
그리고 예를 들어 모델에 논리를 쓸 때 모델 수준에서 논리 테스트를 하는 것이 중요하다.다시 말하면 모형을 테스트하기 위해서는 보기를 부르지 않는 것이 중요하다.도면층이 위로 올라갈수록 검증하기 어렵다.
실제 작성할 때models.py의 테스트는 test_models.py에 기재하고, forms.py의 테스트는 test_forms.py에 기재하면 된다.

"회복" 중요 커버

다른 한편,'시카쿠'를 위해 망라논리의 테스트, 예를 들어'경계치 테스트'의 필요성은 매우 낮다.거꾸로 말하면, 광범위하고 얕게 망라하는 것이 매우 중요하다.그것을 위해서는 덮어쓰는 것이 중요하다.반대로 번역할 때 검사하는 언어는 우리에게 중요하지 않다.
이 두 가지 의식이 있으면 저층 테스트는 섬세해지고 고위층 테스트는 대략적으로 쓸 수 있으며 유지하기 쉬운 테스트도 쓸 수 있다.

프레임워크와 라이브러리를 쓰지 않는 테스트

그리고 중요한 관점으로서 전제적인 프레임워크와 프로그램 라이브러리'자체'의 테스트는 쓰지 않는다.예를 들어, Django는 포함할 때 CSRF 검사를 지원하지만 "CSRF 토큰을 가상 값으로 설정할 때 403 Forbidden으로 변경"같은 테스트는 필요하지 않습니다.그건 Django의 책임이야.
또 예를 들어@require_http_methods(["POST"])가 있는 경우 GET로 접근하면 오류가 발생하고 그런 코드를 보면 알 수 있는 것도 필요 없다.그런 것에 대해 코드 리뷰로 진행하죠.코드를 보지 않는 사람의 인정을 위해 필요하다면 그 과정은 해롭고 무익하기 때문에 먼저 잃어버리세요[1].
그러나 Django의 내부 설치는 코드와 프로그램 라이브러리의 환승에 의존해야 할 때 호환성을 확보하기 위해 테스트를 작성하기도 한다.

코드급 사고

이 글은 기본적으로 테스트 디자인에 관한 것이지만, 아래의 몇 가지는 매우 중요하기 때문에 먼저 쓴다.

실제 코드와 테스트 코드는 완전히 상반된다고 생각한다

예를 들어 코드 중복과 마술 번호는 좋지 않은 코드이지만 테스트 코드를 사용하는 것을 권장합니다.또 테스트 코드에서는 조건의 불일치를 피하는 것이 좋다.

한 상자에 많은 물건을 담지 마라

한 테스트에서 다양한 것을 검증하기 위해 가끔 포장된 상자를 볼 수 있다.그런 테스트는 유지하기 어려우니 피하세요.하지만 용례대로 대본을 검증하면 될 것 같다.

끝말

처음에'TDD를 쓰지 않는다'고 썼는데, 역시 TDD를 배우는 것이 좋다.나는 책을 베끼지 않는 유형에 속하지만, 나는 이 책을 베끼는 것을 강력히 추천한다.
https://amzn.to/3t43tTg
각주
말투가 강경하지만 과거에는 참혹한 일을 당했기 때문이다.↩︎