테스트 코드는 어떻게 테스트해야합니까?


22

대부분의 소프트웨어 개발자가 동의하는 몇 가지 사항 중 하나는 테스트하지 않는 한 코드에 의존하여 올바르게 작동하지 않아야한다는 것입니다. 테스트하지 않으면 숨겨진 버그로 인해 더 많은 작업을 할 수 있습니다.

일반 코드를 테스트하는 방법을 이해하지만 오류가있을 때 오류를 효과적으로 찾고보고 할 수 있도록 테스트 코드를 어떻게 테스트해야합니까? 나는 개인적으로는 어쩔 수 없었을 때 통과 할 수있는 잘못된 테스트 사례를 작성하기에 충분히 어리 석 았기 때문에 처음으로 내 필기 테스트의 목적을 어겼습니다. 다행히도 오류를 제 시간에 찾아서 수정했지만 테스트 만트라에 따르면 테스트 스위트가 제대로 작동하지 않으면 테스트 세트가 완료되지 않은 것처럼 보입니다.

이 작업을 수행하는 가장 좋은 방법은 버그가있는 코드에 대해 테스트가 실패하는지 확인하는 것입니다. * 코드에 버그를 번갈아 추가하고 실패하는지 확인하는 데 2 ​​분을 소비하면 테스트 '작업'. 이로 인해 두 번째 질문 이 나옵니다. 테스트 케이스에 버그가 있는지 확인하기 위해 버그를 도입하는 좋은 방법은 무엇입니까? 문장을 무작위로 주석 처리 if-else하고 조건을 무시 하여 가져 오기 의 잘못된 분기를 확인하고 부작용이있는 코드의 실행 순서를 변경하는 등 테스트가 가장 많이 충족 될 때까지일반적인 버그? 전문 개발자는 테스트가 실제로해야 할 일을 실제로 수행하는지 어떻게 확인합니까? 그들은 단지 시험이 작동한다고 가정합니까, 아니면 시험을하기 위해 시간이 걸리나요? 그렇다면 어떻게 테스트를 테스트합니까?

나는 사람들이 테스트를 테스트하는 데 너무 많은 시간을 보낸 다음 테스트를 위해 테스트를 테스트하여 실제로 실제 코드를 작성하지는 않겠다고 제안하지는 않지만 약간의 이점을 얻을 수 있다고 생각되는 바보 같은 일을했습니다. '메타 테스트'에 대해 알아보고 가장 좋은 방법에 대해 궁금했습니다. :디

* '버그가없는'코드를 테스트 할 때 테스트가 통과했는지 확인할 수는 있지만 코드를 테스트 사양으로 사용하는 것은 상당히 역전 된 것처럼 보입니다 ...


단위 테스트에 대한 확신이없는 것 같습니다. 테스트 작성 경험이 부족하기 때문일 가능성이 큽니까? 이 경우 더 많은 테스트 를 작성 하고 다른 결과를 기대하는 것은 비합리적 입니다. 당신이하고있는 일을 계속하고, 가능한 한 철저하게 (실패와 성공을위한 테스트), 곧 단위 테스트가 스스로 비용을 지불하기 시작하고 이에 대한 자신감이 커질 것입니다.
MattDavey


더 많은 도구를 사용하기 전에 실제 도구를 더 잘 사용하십시오 . 적은 수의 테스트를 작성하지만보다 효율적이고 더 나은 필기 테스트를 작성하십시오. 이해하지 못하는 것을 신뢰할 수 없습니다.
Steve Chamaillard

답변:


16

TDD의 표준 흐름은 다음과 같습니다.

  1. 실패한 테스트를 작성하십시오. (빨간)
  2. 통과하는 가장 작은 코드 변경 (녹색)
  3. 리 팩터 (녹색으로 유지)

이 경우 테스트 테스트는 1 단계입니다. 코드를 변경하기 전에 테스트가 실패했는지 확인하십시오.

내가 좋아하는 또 다른 테스트는 일부 코드를 삭제하고 다른 방식으로 다시 구현할 수 있는지 여부입니다. 삭제 후 테스트는 실패하지만 다른 알고리즘으로 작동합니다.

모든 것과 마찬가지로 마법의 총알도 없습니다. 필요한 테스트 작성을 잊어 버리는 것은 개발자가 코드 작성을 잊어 버리는 것만 큼 쉽습니다. 적어도 두 가지를 모두하고 있다면 누락을 발견 할 수있는 기회가 두 배나됩니다.


4
이중 부기 : 단위 테스트는 생산 코드를 테스트하고 그 반대도 마찬가지입니다. 동일한 문제를 나타내는 두 가지 방법이 있습니다. 이중 부기에서와 같이 두 가지 다른 방식으로 거래를 기록하고 둘 다 동일한 합계를 가져와야합니다.
EricSchaefer

문제는 코드가 여전히 버그가 있지만 2 단계에서 테스트를 녹색으로 만들 때 발생하는 문제에 관한 것입니다. 간단한 예 : 비어 있지 않은 목록 객체에 대한 포인터를 반환 해야하는 함수가 있습니다. 테스트는 포인터가 null1 단계에서 포인터가 실패 하는지 테스트합니다 . 빈 목록을 반환 하여 포인터를 가장 작은 코드로 변경합니다. 두 개의 버그가 있기 때문에 테스트는 이제 "녹색"입니다.
Christian Hackl

그 개발 단계에서 @ChristianHackl은 완벽한 구현입니다! 예상되는 동작을 추가로 지정하기 위해 처음에는 실패한 하나 이상의 테스트를 추가해야합니다. 결과적으로 구현하여 이러한 테스트를 친환경으로 만듭니다.
앤디

@Andy : 코드와 테스트 모두에 버그가 있고 다른 하나는 알아 채지 못하게 할 때 이것이 어떻게 완벽하게 구현되는지 자세히 설명하십시오. (코드의 버그는 빈 목록이 반환되고 테스트의 버그는 내가 확인 null하지 않은 것입니다.)
Christian Hackl

@ChristianHackl 당신은 빈 수표에 따라 맞습니다. 실제로 테스트에서도 수행해야합니다. 단계별로 요구 사항을 테스트로 변환 할 때 버그가 발생할 여지가 거의 없습니다. 사양을 고수하지 않은 경우 (예 : 비어 있지 않은 검사를 간과하는 경우).
Andy

9

Jester 와 같은 도구를 사용하는 한 가지 방법은 Mutation Testing입니다 .

Jester는 코드를 변경하고 테스트를 실행하며 테스트에 통과하면 변경 내용을 알려주는 메시지가 표시됩니다.


4

테스트 테스트? 그 길을 가지 마십시오. 그렇다면 테스트 테스트를위한 테스트가 필요할 것이고 테스트 테스트 테스트를위한 테스트가 필요할 것입니다 ... 어디에서 멈출까요?

일반적인 테스트 흐름은 다음과 같이 진행되며 개발자는 대부분 1-3 시간 동안 시간을 ​​소비하게됩니다.

  1. 암호
  2. 단위 테스트
  3. 통합 테스트
  4. 시스템 / 기타 자동화
  5. 품질 관리 / 인간 테스터

코드에 버그를 번갈아 가면서 2 분을 소비하면 (...)

코드는 결국 자체 버그를 "성장"시키며, 직접 버그를 소개하는 데 시간을 낭비하지 마십시오. 말할 것도없고, 선결제에 대해 알고있는 것이 실제로 버그입니까? 버그가 올 것입니다, 나는 그것에 대해 걱정하지 않을 것입니다.

문을 무작위로 주석 처리 해야하는 경우 if-else의 잘못된 분기가 조건을 무시하여 실행되는지 확인하십시오 (...)

이것은 실제로 자신이 생각하는 것을 실제로 테스트하는지 여부를 확인하는 실용적인 방법입니다. 나는 항상 생각하지 않습니다 좋은 당신이 코드를 알고 변질 코드를 중지 할 때 100 % 작동을 테스트하고 있습니다 : 그것은 일이 ... "시험 시험 시험"과 같은 문제를 앓고?

또한 고전적인 실용적인 프로그래머 조언을 항상 기억하는 것이 좋습니다. 당신은 그것을 필요로하지 않을 것 입니다. 실제 버그에 대한 애자일, 테스트 및 코드 작성, 나타날 수도 있고 나타나지 않을 수도있는 가상의 버그.


3
코드에서 자체 버그가 커지는 것에 대해 걱정하지 않고 테스트가 발생할 때 테스트를 잡는 것이 걱정됩니다. 내 테스트에 결함이 있으면 작업을 수행하지 않으며 실제로 존재할 때 특정 클래스의 버그를 제거했다고 생각합니다. 부정확 한 테스트 결과를보고 있기 때문에 작업이 더 어려워집니다. (실패하면 통과).
고든 구스타프손

@CrazyJugglerDrummer : 테스트에서 확실하게 모든 버그가 발견되지는 않습니다. 그들은 그 목적을 달성하지 못합니다. 이것은 QA가 들어오는 곳입니다. 그렇게한다면, 내가 본 적이없는 소스 코드가 변경되지 않는 한 소프트웨어에 버그가없는 것입니다.
km

3

구성에 따라 기능 코드와 테스트 코드가 서로 테스트됩니다. 기능 코드의 버그가 테스트 코드의 버그에 의해 숨겨 질 때 공통 모드 버그의 경우 한 가지 문제가 남아 있습니다. TDD는이 효과에 영향을받지 않습니다. 이것이 바로이 확률을 줄이기 위해 다른 사람들이 여러 수준에서 테스트를 수행하는 이유입니다.


0

디버거에서 작성할 때 단위 테스트를 한 번 테스트합니다. 그런 다음 혼자두고 잊어 버리십시오. 여기에는 문제가 없습니다.

이걸 고려하세요. 단위 테스트의 목적은 무엇입니까? 주 프로그램에서 수많은 변경 사항 중 하나라도 실수로 해당 프로그램의 논리를 변경하면 알려줍니다. 어떤 변화라도 잠재적으로 무언가를 깨뜨릴 수 있기 때문에 그것을 원합니다. 테스트를 테스트하지 않으면 문제가없는 이유가 바로 여기에 있습니다. 프로그램의 논리를 의도적으로 변경할 때까지 테스트를 망치지 마십시오 (테스트를 다시 방문하여 한 번 더 테스트해야 함). 테스트는 실수로 중단되지 않습니다.


-2

테스트 돌연변이 가 평가하고 측정 시험의 적합성 및 품질.

이것을 사용하여 "테스트"자체를 평가할 수 있습니다.

간단히 말해 테스트와 함께 테스트 (예 : TestA)를 평가할 수 있습니다. TestA는 코드와 돌연변이 코드 (원래 코드와 매우 유사하지만 약간 다른 코드)의 차이를 찾을 수 있습니다.

TestA가 코드와 해당 돌연변이 코드의 차이를 찾을 수없는 경우, TestA가 원래 코드를 테스트하기에 너무 거친 규정을 가지고 있음을 의미합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.