내 응용 프로그램을 사용할 때 사용자가 트리거 한 이벤트 다음에 비동기로 작업을 실행하는 NSOperationQueue 코드를 사용하여 경쟁 조건을 발견했습니다. 나는 그것을 조사하지 않을 바보 같은 설계 오류이기 때문에 경쟁 조건을 해결하는 방법을 안다.하지만 테스트 케이스로 버그를 증명하고 싶다. (그래서 최적화/리팩토링 중에 다시 돌아 오지 않는다. 선 아래로). 이것은 나를 곤란하게 만든다. 테스트 목적이 경쟁 조건을 생성 할 때 멀티 스레드 스레드를 테스트하는 방법은 무엇입니까?단위 테스트 스레드 기반 코드? 경쟁 조건 강제
스레드 및 단위 테스트를 다루는 데 참조 할 수있는 참조 자료가있는 사람이 있습니까? 저는 특히 경쟁 조건 생성에 관심이 있습니다.
경쟁 조건을 유발하는 이벤트의 순서가 실제로 테스트 중에 발생하는지 확인해야합니다. 이를 위해서는 테스트 케이스 내부의 스레드 인터리빙에 영향을 주어야합니다.
추가적인 (조건부) 동기화 또는 (더 간단하고 신뢰할 수없는) 추가 타이머를 사용하여이를 달성 할 수 있습니다. 임계 섹션에 sleep() 호출을 몇 개 넣어 다른 스레드가 바람직하지 않은 상태에 도달 할만큼 오래 실행되도록하십시오. 이 작업을 수행 할 때 명시 적 동기화 (예 : 다른 스레드가 실제로 도착할 때까지 스레드를 차단)로 절전 호출을 바꿉니다.
그런 다음이 모든 조건을 테스트 사례에서 설정 한 전역 플래그로 만듭니다.
솔직히 실제 생산 코드를이 특정 테스트에 연결하는 것이 좋은 생각이라고 생각하지 않습니다. 이는 코드를 리팩터링 할 때마다 그 커플 링을 화나게하지 않도록 조심할 필요가 있다는 것을 의미합니다.이 테스트는 처음에는이 테스트를 수행하는 데 어려움을 겪습니다. –
아니, 취약성 wrt. 리팩토링은 실제로이 테스트 방법을 지원합니다. 리팩터링 할 때 경쟁 조건을 재고해야합니다. 그런 다음 리팩터링이 실제로 새 기능을 도입했거나 이전에 취약했던 기능이 더 이상 발생할 수 없다는 것을 알 수 있습니다. –
저는 이것이 잠재적 인 경쟁 조건을 재고하기 위해 리팩토링하는 사람을 어떻게 "강제로"강제로 생성하는지, 그렇게하는 것이 실제로 유용하다는 것을 알지 못합니다. 분명히 경쟁 조건에 대한 생각이 처음에는 효과가 없었습니다. 코드를 중요한 범위까지 리팩토링하는 사람은 기존 테스트 코드를 완전히 버리고 새로운 코드를 작성하거나 테스트 코드를 쓸모 없게 만들 수 있습니다. 어느 쪽이든, 그것은 테스트 코드를 갖는 목적에 어긋난다. 주 코드베이스를 오염시키지 않으면 서 빌드를 깨진 것으로 플래그하는 대신에 테스트 코드를 갖는 것이 더 낫습니다. –
나는 모든 공유 데이터 구조를 조롱하고 모의 객체 안에서 다른 스레드를 "잘못된"순서로 실행하는 데 필요한 모든 동기화를 수행 할 수 있다고 가정합니다. –