CHAPTER 3 구조적 테스트와 코드 커버리지 77 #4
Comments
|
to @meteora09 @gurioh @AntBean94 @banggeunho @parkcoldroad @Lightieey @D0ri123 @70825 @banggeunho @parkmuhyeun 여러분..! 벌써 금요일이네요..! 우리함께 모두모두 챕터 3를 읽고 내용정리를 공유해봐요~!! 이번주 일요일(09/17 T 23:59) 까지 한번 같이 읽어보시죠...!!!! |
구조적 테스트와 코드 커버리지앞 챕터의 명세 기반 테스트가 완료되면 다음 단계는 소스 코드를 활용해서 테스트 스위트를 확장하는 것으로 그렇게 해야되는 이유는 다음과 같다.
구조적 테스트: 소스 코드의 구조를 사용하여 테스트를 도출하는 것 코드 커버리지, 올바른 방법요즘에는 테스트가 코드의 어느 부분을 수행하는지 찾아내는 일이 간단하다. 모든 프로그래밍 언어 및 환경에 관한 코드 커버리지 도구가 출시되어 있기 때문(ex. jacoco) 수행하지 않은 부분을 찾아서 왜 수행되지 않았는지 이해하고 그 코드 조각을 수행하는 테스트를 작성하자. 구조적 테스트 간략히 살펴보기
*여기서 가장 중요한 점은 구조적 테스트는 이전의 명세 기반 테스트로 고안한 테스트 스위트를 보강한다는 것 코드 커버리지 기준수행되지 않은 코드 줄을 찾을 때마다 해당 줄을 얼마나 철저하게 테스트할지 결정해야 한다. 예를 들어 if 문이 있으면 true만 할지 true, false 모두 할지 코드 줄 커버리지코드 줄 커버리지는 해당하는 줄을 수행하는 테스트가 적어도 하나가 존재 분기 커버리지분기 커버리지는 분기 지시문이 어떻게 평가되는지에 따라 프로그램을 다르게 동작하는 점을 고려 조건 + 분기 커버리지조건 + 분기 커버리지는 분기뿐만 아니라 분기문의 각 조건도 고려한다. 조건을 true 또는 false로 만족하는 테스트를 적어도 하나 만들어야 된다. 그리고 전체 분기문을 또는 true 또는 false로 만족하도록 하는 테스트를 적어도 하나 만들어야 된다. 경로 커버리지경로 커버리지는 프로그램이 수행할 수 있는 모든 실행 경로를 수행한다. 이상적으로 이것이 가장 강력한 기준이지만, 너무 비용이 많이 든다. 복잡한 조건과 MC/DC 커버리지 기준어떻게 테스트 스위트를 구축하기 위한 노력과 비용을 최소화하면서 찾아 낼 수 있는 버그 수를 최대화할까? 바로 수정된 조건/의사 결정 커버리지(modified condition/decision coverage, MC/DC) 를 적용하는 것이다. MC/DC의 기준은 경로 커버리지와 마찬가지로 조건의 조합을 살펴본다. 그러나 가능한 모든 조합을 테스트하는 대신 테스트가 필요한 중요한 조합을 찾아낸다. 각 매개변수의 가능한 모든 조건은 적어도 한 번은 결과에 영향을 주어야 한다. 반복문과 유사 구조 처리하기완벽한 테스트는 불가능하기 때문에 테스터는 종종 반복 경계 적합 기준을 적용해서 언제 반복 테스트를 중지할지 결정
여러 번의 경우에 대해서 테스트를 두 개 이상 만드는 것을 두려하지 말자 기준 포함과 선택일부 전략은 다른 전략을 포함한다. 코드 줄 커버리지 < 분기 커버리지, 조건 커버리지 < 분기 + 조건 커버리지 < MC/DC < 경로 커버리지 취약한 기준은 비용이 적고 빠르게 수행할 수 있지만 코드가 수행하지 않는 부분을 많이 남기게 된다. 반면에 탄탄한 기준은 비용을 많이 들여서 더 엄격하게 코드를 수행할 수 있다. 어떤 기준을 선택할지는 개발자인 우리의 몫이다. 구조적 테스트만 적용하는 것은 충분하지 않다.코드에서 모든 진릿값을 찾을 수 있다면, 왜 구조적 테스트만 수행하면 안 되는 걸까? 분기 커버리지 100%를 달성하더라도 흥미로운 테스트 케이스를 많이 빼먹을 수 있다. 그리고 특이 케이스는 순수한 구조적 테스트로는 얻을 수 없다. 현업에서의 구조적 테스트왜 사람들은 코드 커버리지를 싫어할까?사람들은 암암리에 커버리지 숫자를 무작정 보면 안된다고 주장한다. 동감하는 바이지만 여기서 잘못된 점은 사람들이 코드 커버리지를 바라보는 방식에 있따. 커버리지를 높게 달성했디는 것이 단순히 수행 결과를 뜻할 수 도 있지만, 다른 목적으로 해석할 수 있다. 코드 줄을 수행하지 않고 내버려두었다면 이는 해당 줄의 테스트를 수행할지 고민한 후 수행하지 않기로 결정했다는 뜻이다. 구조적 커버리지가 도움이 되는지, 높은 커버리지 수치가 소프트웨어를 더 잘 테스트하도록 하는지에 관해 이해하는 것은 많은 실증 소프트웨어 연구자들의 목표다. 아직 우리가 목표로 해야 하는 어떤 마법 같은 커버리지 수치를 찾지는 못했지만, 구조적 테스트의 장점을 보여주는 몇몇 사례가 있다.
-> 100%의 커버리지가 시스템을 제대로 테스트했다는 것을 의미하지는 않지만, 커버리지가 매우 낮다는 것은 시스템이 제대로 테스트되지 않았다는 것을 의미한다. 어떤 커비리지 기준을 사용할 것인가어떤 기준을 사용할지는 상황에 따라 달라진다. 그 순간에 무엇을 테스트하는지, 그리고 얼마나 엄격한 테스트를 원하는지에 따라 달라진다. 표현식이 너무 복잡해서 단순화할 수 없다면 MC/DC를 고려하자MC/DC는 표현식이 복잡해짐에 따라 더 가치가 있다. A등급 비행 시뮬레이션 프로그램에서 발견한 조건식의 경로 커버리지 경우의 수는 2^76인데 이런 복잡한 식에서 달성하기는 불가능하므로 MC/DC와 같이 현명한 접근법이 유용하다. 무엇을 수행하지 말아야 할까?커버리지를 100% 달성하기는 불가능하거나 바람일 뿐일 수 있다. 예를 들어 try catch 문이 있을 때 코드 줄 커버리지를 100% 달성하려면 catch 블록을 수행해야 한다. 하지만 그렇게 던질 때 보다 시스템의 나머지 부분에서 일어나는 일이 무엇인지 테스트하는 것이 더 중요할 수도 있다. 저자는 자바에서 equals, hascode, getter, setter는 테스트를 작성하지 않는다. 저자는 커버리지를 100%를 달성해야 한다는 생각으로 시작한다. 그러고 나서 어떤 코드를 수행할 필요가 없다는 것을 발견하면 예외를 둔다. 돌연변이 테스트커버리지만으로는 테스트 스위트의 품질을 알 수 없다. 테스트 스위트의 오류 감지 능력을 생각해보자 얼마나 많은 버그를 드러낼 수 있을까? 라는게 돌연변이 테스트에 깔려 있는 개념이다. 간단히 말해서 존재하는 코드에 일부러 버그를 주입해서 테스트 스위트가 깨지는지 검사한다. 돌연변이 테스트는 비싼 비용에도 불구하고 매우 유익하다. 구글과 같은 대기업도 돌연변이 테스트에 투자하고 있다고 한다.시스템에서 좀 더 민감한 부분에 대해 적용해보면 좋을 것 같다. |
|
https://70825.notion.site/Ch-3-8ecce7a4f08b4616b83b4f90b6846be9?pvs=4 이번 내용엔 커버리지에 대한 내용이 은근히 많더라구요. |
|
@70825 |
3.1 코드 커버리지, 올바른 방법 78
3.2 구조적 테스트 간략히 살펴보기 82
3.3 코드 커버리지 기준 83
__3.3.1 코드 줄 커버리지 83
__3.3.2 분기 커버리지 84
__3.3.3 조건 + 분기 커버리지 85
__3.3.4 경로 커버리지 86
3.4 복잡한 조건과 MC/DC 커버리지 기준 86
__3.4.1 추상적인 예제 86
__3.4.2 MC/DC를 달성하는 테스트 스위트 작성하기 87
3.5 반복문과 유사 구조 처리하기 90
3.6 기준 포함과 선택 91
3.7 명세 기반 테스트와 구조적 테스트: 실제 사례 92
3.8 경계 테스트와 구조적 테스트 98
3.9 구조적 테스트만 적용하는 것은 충분하지 않다 99
3.10 현업에서의 구조적 테스트 101
__3.10.1 왜 사람들은 코드 커버리지를 싫어할까? 101
__3.10.2 커버리지 100%가 의미하는 바는 무엇인가? 103
__3.10.3 어떤 커버리지 기준을 사용할 것인가 105
__3.10.4 표현식이 너무 복잡해서 단순화할 수 없다면 MC/DC를 고려하자 105
__3.10.5 그 외 커버리지 기준 107
__3.10.6 무엇을 수행하지 말아야 할까? 107
3.11 돌연변이 테스트 108
3.12 연습문제 111
3.13 요약 115
The text was updated successfully, but these errors were encountered: