연습으로 저는 생산자 - 소비자 문제에 대한 해결책을 구현하고 싶습니다. 배열 int [] 버퍼와 프로듀서와 고객을 각각 시뮬레이트하는 두 개의 메소드 Produce()와 Consume()과 두 개의 메소드를 모두 비동기 적으로 호출하는 하나의 "Execute"메소드가 있다고 가정 해 보겠습니다.생산자 - 소비자 문제 해결을위한 테스트 작성 방법 _?
구현이 교착 상태를 일으키지 않을지 테스트하고, 많은 시간 (예 : 1 백만) 동안 반복 생성 및 소비를 실행하고 Execute가이 두 메소드가 완료 될 때까지 기다린 다음 (내 단위 테스트) 그냥 특정 시간 (아마도 1 분) 후에 전화가 반환되는지 확인하십시오. 그러나 구현에 경쟁 조건이나 데이터 손상이 없는지 테스트하는 방법은 무엇입니까?
확인해야 할 유일한 것은 교착 상태가 아닙니다. 교착 상태는 항상 신속하게 감지되어 앱이 중지됩니다. 손실 된 메시지 나 중복 된 메시지는 더욱 위험하고 교활합니다. 이중 메시지는 dup이 발생했을 때보 다 훨씬 늦은 시간에 앱 충돌을 일으킬 수 있습니다. 이중 dup이 발생한 곳과는 다른 모듈/스레드/블록에있을 수 있습니다. 이러한 버그는 절대적인 악몽입니다.
큐 클래스를 테스트 할 때 내부 무작위 배열 [256] 구성원과 체크섬이있는 'Message'클래스를 만듭니다. 처음에는 10000 개의 메시지를 생성하고 'totalChecksum'은 개별 체크섬을 생성하고 포인터를 '풀'대기열에 푸시합니다. 여러 제작자 (보통 32 명 사용)는 풀 대기열의 Message 인스턴스를 pop하고 다른 'comms'대기열로 밀어 넣습니다. 여러 소비자 (보통 16 개 사용)는 comms 대기열의 메시지 인스턴스를 pop하고 풀 대기열로 다시 밀어 넣습니다.
룸 워밍업 후 간단한 GUI 폼 타이머는 생산자에게 manualResetEvent를 기다리라는 휘발성 부울 값을 설정하여 생산자를 중단시킵니다. Sleep (500) 후에 10000 개의 모든 메시지가 풀 대기열에 다시 있어야하며 GUI는 풀 대기열 수가 10000인지 확인하고 루프에서 10000 개의 메시지를 팝하며 totalChecksumming하고 다시 밀어 넣고 마지막으로 totalChecksum과 비교합니다. 이것이 통과되면 부울이 재설정되고 MRE가 신호를 보내 프로듀서를 다시 실행하게합니다.
이 테스트를 밤새 반복해서 실행합니다. 오류가있는 경우 대기열은 목적에 맞지 않습니다.