개발 관점에서 먼저 특정 이름과 형식에 따라 변수와 함수를 구성하고, 다음으로 업계에서는 테스트 기반 개발을 옹호합니다.
TDD는 Test-Driven Development의 영어 약어로 애자일 개발의 핵심 실천이자 기술이자 설계 방법론입니다. TDD의 원칙은 기능 코드를 개발하기 전에 단위 테스트 케이스 코드를 작성하는 것입니다.
1. TDD의 3가지 법칙
제1법칙 통과할 수 없는 단위 테스트를 작성하기 전에는 프로덕션 코드를 작성하지 마십시오.
법칙 2: 통과하지 못한 단위 테스트만 작성할 수 있습니다. 컴파일 실패는 실패로 간주되지 않습니다.
제3법칙: 현재 실패한 테스트를 통과하기에 충분한 프로덕션 코드만 작성하세요.
테스트는 프로덕션 코드와 함께 작성되며 테스트는 프로덕션 코드보다 몇 초 전에 작성됩니다.
2. 테스트를 깔끔하게 유지하세요
테스트 코드는 프로덕션 코드만큼 중요하며 깔끔하게 유지되어야 합니다.
모든 좋은 것은 테스트와 함께 제공됩니다.
클린 유닛 테스트 코드는 코드에 많은 이점을 가져다줍니다. 테스트가 더러워질수록 코드는 결국 더 더러워지게 됩니다. 테스트가 누락되면 코드가 부패하기 시작합니다.
3. 클린 테스팅
클린 테스팅에는 가독성이라는 매우 중요한 요소가 있습니다.
테스트 코드는 명확하고 깔끔하며 표현력이 풍부해야 합니다. 시험에서는 가능한 한 적은 단어로 많은 것을 말하십시오.
테스트 모드 : 시공-운영-검사,
첫 번째 단계는 테스트 데이터 구축
두 번째 단계는 테스트 데이터 운영
세 번째 단계는 작업이 예상한 결과를 얻었는지 확인하는 것입니다.
3.1 특정 분야에 대한 테스트 언어
테스트 언어 테스트를 사용하여 더 읽기 쉽게 만듭니다.
3.2 이중 표준
테스트 API의 코드는 프로덕션 코드와 엔지니어링 표준이 달라야 하며, 단순하고 간결하며 표현력이 풍부해야 하지만 프로덕션 코드만큼 효과적이어야 합니다. .
4. 테스트당 하나의 어설션
어떤 사람들은 각 테스트 함수에 하나의 어설션 문만 있어야 한다고 생각합니다.
한 컨셉씩 테스트해보세요.
하나의 개념만 테스트하고 각 테스트 기능에서 한 가지 작업을 수행하는 것이 더 나은 규칙일 수 있습니다.
5. F.I.R.S.T 원칙
클린 코드는 다음 규칙을 따라야 합니다.
빠른 테스트는 충분히 빨라야 합니다. 테스트는 빠르게 실행되어야 합니다.
독립적인 테스트는 서로 독립적이어야 합니다. 하나의 테스트가 다음 테스트의 조건을 설정해서는 안 됩니다.
반복 테스트는 어떤 환경에서도 반복적으로 통과해야 합니다.
자가 검증 테스트에는 부울 출력이 있어야 합니다. 실패하든 통과하든 로그를 확인하여 테스트 통과 여부를 확인하기보다는 직접 결론을 도출해야 합니다.
적절한 테스트는 적시에 작성되어야 합니다. 단위 테스트는 테스트를 통과하는 프로덕션 코드 바로 앞에 작성되어야 합니다.
6. 요약
테스트는 코드만큼 중요합니다. 프로덕션 코드의 확장성, 유지 관리성 및 재사용성을 보장하고 향상시킵니다. 테스트를 깨끗하고 표현력이 풍부하며 짧게 유지하세요. 자신만의 테스트를 작성하는 데 도움이 되도록 도메인별 언어에 대한 테스트 API로 개발되었습니다.
실제 개발에서는 다양한 외부 및 내부 요인, 빡빡한 공사 일정, 시간 부족, 과중한 작업 등으로 인해 많은 팀에서 TDD나 단위 테스트를 수행하지 않는 경우가 많습니다. 그럼에도 불구하고 우리는 여전히 이 원칙을 고수하고 단위 테스트의 목표에 천천히 다가가세요...
좋아하실 수도 있습니다: