key successful unit testing how developers test their own code
블랙 박스 테스터 단위 테스트는 신경 쓰지 마세요. 주요 목표는 구현 세부 사항으로 이동하지 않고 요구 사항에 대해 응용 프로그램을 검증하는 것입니다.
하지만 호기심이나 상자 밖으로 생각 , 개발자가 코드를 테스트하는 방법에 대해 궁금한 적이 있습니까? 테스트를 위해 코드를 출시하기 전에 테스트에 어떤 방법을 사용합니까? 애자일 프로세스에서 개발 테스트는 어떻게 중요합니까? 이 모든 것에 대한 답은 단위 테스트입니다. 개발 및 테스트 팀이 우수한 애플리케이션을 설계, 테스트 및 출시하기 위해보다 협력 적으로 작업 할 수 있도록 단위 테스트의 중요성에 대해 알려 드리고자합니다.
미래에 여러분 중 일부는 화이트 박스 테스트로 전환하여 이러한 코드 유효성 검사 및 개선 기술을 사용할 수도 있다는 것을 누가 알겠습니까!
학습 내용 :
단위 테스트 란?
단위 테스트는 새로운 개념이 아닙니다. 프로그래밍 초기부터 존재했습니다. 일반적으로 개발자 및 때로는 화이트 박스 테스터 기능 요구 사항을 구현하는 데 사용되는 코드의 모든 단위를 확인하여 코드 품질을 향상시키기 위해 단위 테스트를 작성합니다 (테스트 주도 개발 TDD 또는 테스트 우선 개발).
우리 대부분은 고전적인 정의를 알고있을 것입니다.
'단위 테스트는 목적에 따라 테스트 가능한 코드의 가장 작은 부분을 확인하는 방법입니다.' 목적이나 요구 사항이 실패하면 단위 테스트가 실패한 것입니다.
간단히 말해서, 요구 사항 구현을 위해 작성된 코드 (단위)를 확인하기 위해 코드 (단위 테스트)를 작성하는 것입니다.
SDLC의 단위 테스트
단위 테스트에서 개발자는 수동 또는 자동 테스트를 사용하여 소프트웨어의 각 단위가 고객의 요구 사항을 충족하는지 확인합니다. 이 단위는 테스트중인 소프트웨어의 개별 기능, 개체, 방법, 절차 또는 모듈 일 수 있습니다.
개별 단위를 테스트하기 위해 단위 테스트를 작성하면 모든 단위가 통합되므로 포괄적 인 테스트를 쉽게 작성할 수 있습니다. 소프트웨어 개발 중에 첫 번째 테스트 수준으로 수행됩니다.
단위 테스트 작성의 중요성
단위 테스트는 코드를 유지 관리하고 코드 단위의 문제를 제거하는 데 도움이되는 강력한 소프트웨어 구성 요소를 설계하는 데 사용됩니다. 우리 모두는 소프트웨어 개발주기의 초기 단계에서 결함을 찾고 수정하는 것의 중요성을 알고 있습니다. 이 테스트는 동일한 목적으로 사용됩니다.
이는 민첩한 소프트웨어 개발 프로세스의 필수적인 부분입니다. 야간 빌드 실행 단위 테스트 스위트가 실행되고 보고서가 생성되어야하는시기입니다. 단위 테스트 중 하나라도 실패한 경우 QA 팀은 확인을 위해 해당 빌드를 수락해서는 안됩니다.
이를 표준 프로세스로 설정하면 초기 개발주기에 많은 결함이 포착되어 테스트 시간이 많이 절약됩니다.
많은 개발자들이 단위 테스트 작성을 싫어한다는 것을 알고 있습니다. 그들은 빡빡한 일정이나 심각성 부족으로 인해 잘못된 단위 테스트 케이스를 무시하거나 작성합니다 (예 : 빈 단위 테스트를 작성하므로 100 %가 성공적으로 통과합니다 ;-)). 좋은 단위 테스트를 작성하거나 전혀 작성하지 않는 것이 중요합니다. 제공하는 것이 훨씬 더 중요합니다. 충분한 시간 그리고 실질적인 이익을위한 지원 환경.
단위 테스트 방법
두 가지 방법으로 수행 할 수 있습니다.
- 수동 테스트
- 자동화 된 테스트
에 수동 테스트 , 테스터는 자동화 도구를 사용하지 않고 수동으로 테스트 케이스를 실행합니다. 여기에서 테스트의 각 단계는 수동으로 실행됩니다. 수동 테스트는 특히 반복적이고 테스트 케이스를 만들고 실행하는 데 더 많은 노력이 필요한 테스트의 경우 지루합니다. 수동 테스트에는 테스트 도구에 대한 지식이 필요하지 않습니다.
100 % 자동화가 불가능하므로 항상 일정 수준의 수동 테스트가 수행됩니다.
에 자동화 된 테스트, 소프트웨어 테스트 자동화 도구는 테스트 / 테스트 사례를 자동화하는 데 사용됩니다. 자동화 도구는 테스트를 기록하고 저장할 수 있으며 추가 사람의 개입없이 필요한만큼 여러 번 재생할 수 있습니다.
이러한 도구는 테스트중인 시스템에 테스트 데이터를 입력 할 수있을뿐만 아니라 예상 결과를 실제 결과와 비교하고 자동으로 보고서를 생성 할 수 있습니다. 그러나 테스트 자동화 도구를 설정하는 초기 비용은 높습니다.
단위 테스트 내의 기술
# 1) 화이트 박스 테스트 :
3 년 경력의 수동 테스트 재개
화이트 박스 테스트에서 테스터는 코드를 포함한 소프트웨어의 내부 구조를 알고 있으며 설계 및 요구 사항에 대해 테스트 할 수 있습니다. 따라서 화이트 박스 테스트는 투명한 테스트 .
# 2) 블랙 박스 테스트 :
블랙 박스 테스트에서 테스터는 소프트웨어의 코드도 내부 구조를 알지 못합니다.
# 3) 회색 상자 테스트 :
이것은 또한 반투명 기술 테스트 즉, 테스터는 부분적으로 만 요구 사항과 함께 내부 구조, 기능 및 디자인의. 디버깅은 백엔드에서 정확한 데이터를 얻기 위해 프런트 엔드의 실제 입력에 의해 수행됩니다. 따라서 회색 상자는 블랙 박스와 화이트 박스 테스트 기술의 조합으로 간주됩니다.
그레이 박스 테스트에는 다음 유형의 테스트가 포함됩니다.
- 매트릭스 테스트.
- 패턴 테스트.
- 직교 패턴 테스트.
- 회귀 테스트.
단위 테스트의 이점
- 프로세스가 민첩 해집니다. 기존 소프트웨어에 새로운 기능이나 기능을 추가하려면 이전 코드를 변경해야합니다. 그러나 이미 테스트 된 코드로 변경하는 것은 위험 할뿐만 아니라 비용도 많이들 수 있습니다.
- 코드 품질이 향상됩니다. 단위 테스트가 완료되면 코드의 품질이 자동으로 향상됩니다. 이 테스트 중에 확인 된 버그는 통합 테스트 단계로 전송되기 전에 수정됩니다. 개발자가 사양을 먼저 이해하여 테스트 케이스를 작성하므로 견고한 설계 및 개발이 가능합니다.
- 버그를 조기에 감지합니다. 개발자가 단위 테스트를 실행하면 소프트웨어 개발 수명주기 초기에 버그를 감지하고 해결합니다. 여기에는 사양의 결함 또는 누락 된 부분은 물론 프로그래머 구현의 버그가 포함됩니다.
- 더 쉬운 변경 및 단순화 된 통합 : 단위 테스트를 수행하면 개발자가 코드를 쉽게 재구성하고 변경하고 유지 관리 할 수 있습니다. 또한 통합 후 코드를 훨씬 쉽게 테스트 할 수 있습니다. 단위 테스트에서 문제를 해결하면 이후 개발 및 테스트 단계에서 발생하는 다른 많은 문제를 해결할 수 있습니다.
- 문서 가용성 : 이후 단계에서 기능을 살펴 보는 개발자는 단위 테스트 문서를 참조 할 수 있으며 단위 테스트 인터페이스를 쉽게 찾고 수정하거나 빠르고 쉽게 작업 할 수 있습니다.
- 쉬운 디버깅 프로세스 : 디버깅 프로세스를 단순화하는 데 도움이됩니다. 테스트가 어느 단계에서든 실패하면 코드를 디버깅해야합니다. 그렇지 않으면 장애물없이 프로세스를 계속할 수 있습니다.
- 저렴한 비용 : 단위 테스트 중에 버그가 감지되고 해결되면 비용과 개발 시간이 줄어 듭니다. 이 테스트가 없으면 코드 통합 후 이후 단계에서 동일한 버그가 감지되면 추적 및 해결이 더 어려워 져 비용이 많이 들고 개발 시간이 늘어납니다.
- 단위 테스트를 사용하여 코드 완성도를 입증 할 수 있습니다. 이는 애자일 프로세스에서 더 유용합니다. 테스터는 통합이 완료 될 때까지 테스트 할 기능 빌드를 얻지 못합니다. 코드를 작성하고 확인했음을 보여 주어 코드 완성을 정당화 할 수 없습니다. 그러나 단위 테스트를 실행하면 코드 완전성을 입증 할 수 있습니다.
- 개발 시간 절약 : 코드 완성에 더 많은 시간이 소요될 수 있지만 시스템 및 승인 테스트의 버그가 적기 때문에 전체 개발 시간을 절약 할 수 있습니다.
- 코드 커버리지 측정 가능
단위 테스트주기
(영상 출처 )
좋은 단위 테스트는 무엇입니까?
글쎄, 나는 무엇이 좋은 단위 테스트를 만드는지 말할 수있는 사람은 아니지만, 다양한 프로젝트에 대한 나의 관찰을 바탕으로 좋은 단위 테스트의 특징을 말할 수 있습니다. 잘못된 단위 테스트는 프로젝트에 가치를 추가하지 않습니다. 대신 프로젝트 비용이 잘못된 단위 테스트를 작성하고 관리하는 데 크게 증가합니다.
좋은 단위 테스트를 작성하는 방법?
- 통합이 아닌 단일 코드 단위를 확인하기 위해 단위 테스트를 작성해야합니다.
- 명확한 이름을 가진 작고 분리 된 단위 테스트를 사용하면 작성 및 유지 관리가 매우 쉽습니다.
- 소프트웨어의 다른 부분을 변경하면 특정 코드 단위에 대해 분리되고 작성된 경우 단위 테스트에 영향을주지 않습니다.
- 빨리 실행되어야합니다
- 단위 테스트는 재사용 가능해야합니다.
단위 테스트 프레임 워크
단위 테스트 프레임 워크는 주로 단위 테스트를 빠르고 쉽게 작성하는 데 사용됩니다. 대부분의 프로그래밍 언어는 내장 컴파일러를 사용한 단위 테스트를 지원하지 않습니다. 타사 오픈 소스 및 상용 도구를 사용하여 단위 테스트를 더욱 재미있게 만들 수 있습니다.
인기 목록 단위 테스트 도구 다른 프로그래밍 언어 :
- 자바 프레임 워크 – JUnit
- PHP 프레임 워크 – PHPUnit
- C ++ 프레임 워크 – UnitTest ++ 과 Google C ++
- .넷 프레임 워크 - NUnit
- Python 프레임 워크 – py.test
오해와 진실
- 단위 테스트 케이스를 사용하여 코드를 작성하는 데 더 많은 시간이 걸리며 그럴 시간이 없습니다. 실제로 장기적으로는 개발 시간을 절약 할 수 있습니다.
- 단위 테스트는 모든 버그를 찾습니다. 단위 테스트의 목적은 버그를 찾는 것이 아니라 SDLC의 후반 단계에서 결함이 적은 강력한 소프트웨어 구성 요소를 개발하는 것이므로 그렇지 않습니다.
- 100 % 코드 커버리지는 100 % 테스트 커버리지를 의미합니다. 이것은 코드에 오류가 없음을 보장하지 않습니다.
단위 테스트를 받아들이는 방법?
좋은 단위 테스트는 세 가지 기본 부분으로 수행 할 수 있습니다.
- 단위 테스트 코드 작성
- 단위 테스트 코드를 실행하여 시스템 요구 사항을 충족하는지 확인하십시오.
- 소프트웨어 코드를 실행하여 결함과 코드가 시스템 요구 사항을 충족하는지 테스트합니다.
위의 3 단계를 수행 한 후 코드가 올 바르면 단위 테스트를 통과 한 것입니다. 시스템 요구 사항을 충족하지 않으면 테스트가 실패합니다. 이 경우 개발자는 코드를 다시 확인하고 수정해야합니다.
어떤 경우에는이 테스트를보다 정확하게 수행하기 위해 코드를 분리해야합니다.
모범 사례
이 테스트 중에 최상의 코드를 생성하려면 다음 사항을 고려하십시오.
- 코드는 강력해야합니다. 테스트가 실패하거나 최악의 경우 코드가 손상 되어도 전혀 실행되지 않는 경우가 있습니다.
- 이해 가능하고 합리적 : 코드는 이해하기 쉬워야합니다. 이를 통해 개발자는 코드를 쉽게 작성할 수 있으며 이후에 코드 작업을 수행 할 다른 개발자도 쉽게 디버깅 할 수 있습니다.
- 단일 케이스 여야합니다. 여러 케이스를 하나로 정의하는 테스트는 작업하기가 복잡합니다. 따라서 단일 케이스 코드를 작성하는 것이 가장 좋은 방법이므로 코드를 더 쉽게 이해하고 디버깅 할 수 있습니다.
- 자동 테스트 허용 : 개발자는 테스트가 자동화 된 형식으로 실행되는지 확인해야합니다. 지속적 배포 프로세스 또는 통합 프로세스에 있어야합니다.
명심해야 할 기타 사항은 다음과 같습니다.
- 모든 조건에 대한 테스트 케이스를 만드는 대신 시스템 동작에 영향을 미치는 테스트에 집중하십시오.
- 브라우저의 캐시로 인해 버그가 재발 할 가능성이 있습니다.
- 테스트 케이스는 상호 의존적이어서는 안됩니다.
- 루프 상태에도주의하십시오.
- 테스트 케이스를 더 자주 계획하십시오.
결론
모든 기능을 개별적으로 테스트해야 할 때 단위 테스트가 필요합니다. 소프트웨어 개발의 후반 단계에서 찾는 것보다이 테스트 중에 버그를 감지하고 수정하고 시간과 비용을 절약하는 것이 훨씬 합리적입니다.
많은 이점을 제공하지만 사용과 관련된 제한 사항도 있습니다. 소프트웨어 개발 프로세스 전반에 걸쳐 엄격한 규율과 일관성이 필요합니다. 한계를 극복하고 의도 한 이점을 얻을 수 있습니다.
귀하의 의견은 가장 환영받습니다!
블랙 박스 테스터로서 팀의 단위 테스트에 대해 어떻게 관찰합니까? 성공적인 단위 테스트를위한 더 나은 아이디어가있는 사람이 있습니까?