단위 테스트의 무작위 데이터?
https://stackoverflow.com/questions/32458
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 임의의 데이터로 필드를 채우는 개체에 대한 단위 테스트를 작성하는 동료가 있습니다. 그의 이유는 다양한 값을 테스트하는 반면 일반 테스트는 하나의 정적 값만 사용하기 때문에 더 넓은 범위의 테스트를 제공하기 때문입니다.
저는 이에 반대하는 여러 가지 이유를 그에게주었습니다. 주요 이유는 다음과 같습니다.
- 무작위 값은 테스트가 실제로 반복 될 수 없음을 의미합니다 (즉, 테스트가 임의로 실패 할 수있는 경우 빌드 서버에서 수행하여 빌드를 중단 할 수 있음을 의미합니다)
- 무작위 값이고 테스트가 실패하면 a) 객체를 수정하고 b) 매번 해당 값을 테스트하도록 강제해야합니다. 따라서 작동한다는 것을 알 수 있지만 무작위이므로 무엇을 알 수 없습니다. 값은
다른 동료 추가 :
- 예외를 테스트하는 경우 임의의 값은 테스트가 예상 상태로 끝나는 것을 보장하지 않습니다.
- 무작위 데이터는 단위 테스트가 아닌 시스템 비우기 및 부하 테스트에 사용됩니다.
다른 사람이이 일을 중단하도록 할 수있는 다른 이유를 추가 할 수 있나요?
(또는 이것은 단위 테스트를 작성하는 데 허용되는 방법이며 나와 다른 동료가 틀렸습니까?)
해결책
타협이 있습니다. 동료가 실제로 뭔가를하고 있지만 그가 잘못하고있는 것 같습니다. 전적으로 무작위 테스트가 매우 유용하다고 확신하지는 않지만 확실히 유효하지 않습니다.
프로그램 (또는 단위) 사양은이를 충족하는 프로그램이 존재한다는 가설입니다. 그러면 프로그램 자체가 그 가설의 증거가됩니다. 단위 테스트는 프로그램이 사양에 따라 작동한다는 것을 반박하기위한 반증을 제공하려는 시도입니다.
이제 단위 테스트를 직접 작성할 수 있지만 실제로는 기계적인 작업입니다. 자동화 할 수 있습니다. 여러분이해야 할 일은 사양을 작성하는 것뿐입니다. 기계는 코드를 손상시키려는 수많은 단위 테스트를 생성 할 수 있습니다.
사용중인 언어를 모르지만 여기를 참조하세요.
Scala (또는 Java) http://github.com/rickynils/scalacheck
하스켈 http://www.cs.chalmers.se/~rjmh/QuickCheck/
.NET : http://blogs.msdn.com/dsyme /archive/2008/08/09/fscheck-0-2.aspx
이 도구는 잘 구성된 사양을 입력으로 사용하고 자동으로 생성 된 데이터를 사용하여 원하는만큼 단위 테스트를 자동으로 생성합니다. 그들은 "축소"전략 (조정 가능)을 사용하여 코드를 손상시킬 수있는 가장 간단한 테스트 케이스를 찾고 엣지 케이스를 잘 다루도록합니다.
감사합니다!
다른 팁
이러한 종류의 테스트를 원숭이 테스트 라고합니다.제대로 수행하면 정말 어두운 구석에서 버그가 사라질 수 있습니다.
재현성에 대한 우려를 해결하려면이 문제에 접근하는 올바른 방법은 실패한 테스트 항목을 기록하고 특정 버그의 전체 제품군 을 조사하는 단위 테스트를 생성하는 것입니다.그리고 초기 실패를 일으킨 하나의 특정 입력 (무작위 데이터에서)을 단위 테스트에 포함합니다.
여기에는 PRNG를 상수로 시드하는 데 사용되는 중간 집이 있습니다.이를 통해 반복 가능한 '무작위'데이터를 생성 할 수 있습니다.
개인적으로 나는 (일정한) 임의의 데이터가 테스트에 유용한 곳이 있다고 생각합니다. 신중하게 생각한 모든 코너를 완료했다고 생각한 후에는 PRNG의 자극을 사용하여 때때로 다른 것을 찾을 수 있습니다.
테스트를 보는 사람에게 한 가지 장점은 임의의 데이터가 분명히 중요하지 않다는 것입니다.수십 개의 데이터가 포함 된 테스트를 너무 많이 봤는데, 무엇이 그런 식으로되어야하는지, 그리고 어떻게되는지를 말하기가 어려울 수 있습니다.예 :주소 유효성 검사 방법이 특정 우편 번호로 테스트되고 다른 모든 데이터가 무작위 인 경우 우편 번호가 유일한 중요한 부분임을 확신 할 수 있습니다.
당신이 TDD를하고 있다면 나는 랜덤 데이터가 훌륭한 접근법이라고 주장 할 것입니다.테스트가 상수로 작성된 경우 코드가 특정 값에 대해서만 작동하도록 보장 할 수 있습니다.테스트가 빌드 서버에서 무작위로 실패하는 경우 테스트 작성 방법에 문제가있을 수 있습니다.
무작위 데이터는 향후 리팩토링이 매직 상수에 의존하지 않도록하는 데 도움이됩니다.결국, 테스트가 문서라면 상수의 존재가 해당 상수에 대해서만 작동해야 함을 의미하지 않습니까?
나는 과장하고 있지만 "이 변수의 값이이 테스트의 결과에 영향을주지 않아야한다"는 신호로 내 테스트에 임의의 데이터를 삽입하는 것을 선호합니다.
무작위 변수를 사용하고 해당 변수를 기반으로 테스트를 포크하면 냄새라고 말할 수 있습니다.
- 무작위 값이고 테스트가 실패하면 a) 객체를 수정하고 b) 매번 해당 값을 테스트하도록 강제해야합니다. 따라서 작동한다는 것을 알 수 있지만 무작위이므로 무엇을 알 수 없습니다.값은
테스트 케이스가 테스트 대상을 정확하게 기록하지 못하는 경우 테스트 케이스를 다시 코딩해야합니다.저는 항상 테스트 케이스에 대해 다시 참조 할 수있는 로그를 갖고 싶어서 정적 데이터를 사용하든 무작위 데이터를 사용하든 실패의 원인을 정확히 알고 싶습니다.
동료는 잘 모르지만 퍼즈 테스트 를하고 있습니다..특히 서버 시스템에서 유용합니다.
나는 무작위 테스트를 선호하며 작성합니다. 그러나 특정 빌드 환경에 적합한 지 여부와 포함해야하는 테스트 스위트는 더 미묘한 문제입니다.
로컬에서 실행 (예 : 개발 상자에서 밤새도록) 무작위 테스트에서 명백하고 모호한 버그가 발견되었습니다. 모호한 것들은 난해하기 때문에 무작위 테스트가 실제로 유일하게 현실적인 테스트라고 생각합니다. 테스트로 무작위 테스트를 통해 발견 된 찾기 힘든 버그 하나를 가져 와서 6 명의 크랙 개발자가 해당 기능 (약 12 줄의 코드)을 검토하도록했습니다. 아무도 감지하지 못했습니다.
무작위 데이터에 대한 귀하의 주장 중 상당수는 "테스트를 재현 할 수 없습니다"라는 풍미입니다. 그러나 잘 작성된 무작위 테스트는 무작위 시드를 시작하는 데 사용되는 시드를 캡처하고 실패시 출력합니다. 수동으로 테스트를 반복 할 수있을뿐만 아니라 해당 테스트의 시드를 하드 코딩하여 특정 문제를 테스트하는 새 테스트를 간단하게 만들 수 있습니다. 물론 해당 사례를 다루는 명시 적 테스트를 직접 코딩하는 것이 더 좋을 수 있지만, 게으름에는 장점이 있으며 이는 기본적으로 실패한 시드에서 새로운 테스트 사례를 자동 생성 할 수 있도록합니다.
하지만 토론 할 수없는 한 가지 요점은 빌드 시스템을 망가 뜨린다는 것입니다. 대부분의 빌드 및 지속적 통합 테스트에서는 테스트가 매번 동일한 작업을 수행 할 것으로 예상합니다. 따라서 무작위로 실패하는 테스트는 혼란을 야기하고 무작위로 실패하고 무해한 변경 사항을 손가락으로 가리 킵니다.
그런 다음 해결책은 빌드 및 CI 테스트의 일부로 무작위 테스트를 계속 실행하지만 고정 된 수의 반복을 위해 고정 된 시드로 실행 하는 것입니다. 따라서 테스트는 항상 동일한 작업을 수행하지만 여전히 많은 입력 공간을 탐색합니다 (여러 반복을 위해 실행하는 경우).
로컬에서, 예를 들어 관련 클래스를 변경할 때 더 많은 반복을 위해 또는 다른 시드와 함께 자유롭게 실행할 수 있습니다. 무작위 테스트가 점점 더 대중화되면 무작위로 알려진 특정 테스트 모음을 상상할 수도 있습니다.이 테스트는 다른 시드로 실행될 수 있으며 (따라서 시간이 지남에 따라 적용 범위가 증가 함) 실패가 동일한 의미가 아닌 경우 결정적 CI 시스템으로 (즉, 실행은 코드 변경과 1 : 1로 연결되지 않으므로 작업이 실패 할 때 특정 변경을 가리 키지 않습니다.)
무작위 테스트, 특히 잘 작성된 테스트에는 할 말이 많으므로 너무 빨리 무시하지 마세요!
무작위 데이터를 한 번 (테스트 실행 당 한 번이 아니라 정확히 한 번) 생성 한 다음 이후 모든 테스트에서 사용할 수 있습니까?
생각하지 못한 사례를 테스트하기 위해 무작위 데이터를 생성하는 것이 가치가 있음을 확실히 알 수 있지만, 맞습니다. 무작위로 통과하거나 실패 할 수있는 단위 테스트를 갖는 것은 나쁜 일입니다.
테스트의 목표가 무엇인지 스스로에게 물어봐야합니다.
단위 테스트 는 논리, 코드 흐름 및 개체 상호 작용을 확인하는 것입니다.임의의 값을 사용하면 다른 목표를 달성하려고 시도하므로 테스트 초점과 단순성이 감소합니다.가독성을 위해 허용됩니다 (UUID, ID, 키 생성 등).
특히 단위 테스트의 경우이 방법이 문제를 찾는 데 성공한 후에도 기억할 수 없습니다.하지만 무작위 값과 주로 무작위 날짜로 영리 해 지려고 노력하는 많은 결정론 문제 (테스트에서)를 보았습니다.
퍼즈 테스트는 통합 테스트 및 종단 간 테스트 에 유효한 접근 방식입니다.
테스트에 임의 입력을 사용하는 경우 값이 무엇인지 확인할 수 있도록 입력을 기록해야합니다.이런 식으로 우연한 상황이 발생하면 테스트를 작성하여 재현 할 수 할 수 있습니다 .무작위 입력을 사용하지 않는 사람들로부터 동일한 이유를 들었지만 특정 테스트 실행에 사용 된 실제 값에 대한 통찰력을 갖게되면 그다지 문제가되지 않습니다.
'임의'데이터라는 개념은 중요하지 않는 무언가를 나타내는 방법으로도 매우 유용합니다.당면한 테스트와 관련이없는 노이즈 데이터가 많이있는 경우 몇 가지 승인 테스트가 있습니다.
객체 / 앱에 따라 임의의 데이터가 부하 테스트에 포함될 수 있습니다.데이터의 경계 조건을 명시 적으로 테스트하는 데이터를 사용하는 것이 더 중요하다고 생각합니다.
오늘이 문제를 만났습니다.나는 의사 랜덤 을 원했습니다 (크기 측면에서 압축 된 오디오 데이터처럼 보입니다).나는 결정적 도 원했다.rand ()는 Linux와 OSX에서 달랐습니다.그리고 내가 다시 시드하지 않으면 언제든지 바뀔 수 있습니다.그래서 우리는 그것을 결정 론적이지만 여전히 가짜 무작위로 변경했습니다. 테스트는 미리 준비된 데이터를 사용하는 것만 큼 반복 가능하지만 더 편리하게 작성되었습니다.
이것은 코드 경로를 통한 무작위 무차별 대입에 의한 테스트가 아닙니다 .그 차이가 있습니다. 여전히 결정적이며 반복 가능하며 실제 입력처럼 보이는 데이터를 사용하여 복잡한 논리의 엣지 케이스에 대한 일련의 흥미로운 검사를 실행합니다.여전히 단위 테스트.
여전히 자격 요건이 무작위인가요?맥주에 대해 이야기합시다.:-)
테스트 데이터 문제에 대한 세 가지 해결책을 구상 할 수 있습니다.
- 고정 데이터로 테스트
- 임의 데이터로 테스트
- 임의 데이터를 한 번 생성 한 다음 고정 데이터로 사용
위의 모든 작업 을 수행하는 것이 좋습니다.즉, 두뇌를 사용하여 해결 된 일부 에지 케이스와 한 번만 생성하는 무작위 데이터로 반복 가능한 단위 테스트를 작성하십시오.그런 다음 또한 실행하는 무작위 테스트 세트를 작성합니다.
무작위 테스트는 반복 가능한 테스트가 놓친 부분을 포착 할 것으로 기 대해서는 안됩니다.반복 가능한 테스트로 모든 것을 다루는 것을 목표로해야하며 무작위 테스트는 보너스로 간주해야합니다.그들이 무언가를 발견한다면 그것은 당신이 합리적으로 예측할 수 없었던 것이어야합니다.진짜 괴짜.
문제가 해결되었는지 확인하지 못한 경우 어떻게 다시 테스트를 실행할 수 있습니까?즉그는 테스트의 반복성을 잃습니다.
다른 답변에서 언급했듯이 테스트에서 임의의 데이터로드를 던지는 데 가치가 있다고 생각하지만 다른 어떤 것보다로드 테스트라는 제목에 더 많이 해당합니다.그것은 거의 "희망에 의한 시험"관행입니다.실제로 당신의 남자는 자신이 테스트하려는 것에 대해 생각하지 않고 무작위성이 결국 신비한 오류를 포착하기를 바라면서 그 생각 부족을 보완한다고 생각합니다.
그래서 제가 그와 함께 사용할 주장은 그가 게으르다는 것입니다.또는 다른 말로 말하자면, 그가 테스트하려는 내용을 이해하는 데 시간을 할애하지 않으면 그가 작성하는 코드를 실제로 이해하지 못하는 것으로 나타날 수 있습니다.
