2010-12-14 28 views
8

Khi sử dụng ứng dụng của mình, tôi đã tình cờ gặp một điều kiện chủng tộc trong một số mã sử dụng một NSOperationQueue để chạy tác vụ không đồng bộ sau các sự kiện do người dùng kích hoạt. Tôi biết cách sửa chữa điều kiện chủng tộc, vì đó là lỗi thiết kế ngu ngốc mà tôi sẽ không nghiên cứu, nhưng tôi muốn chứng minh lỗi với một trường hợp thử nghiệm (để nó không trở lại trong khi tối ưu hóa/tái cấu trúc thêm xuống dòng). Điều này khiến tôi bối rối. Làm thế nào để đi về thử nghiệm một cái gì đó là đa luồng, đặc biệt là khi mục đích của thử nghiệm là tạo ra một điều kiện chủng tộc?Kiểm tra đơn vị mã dựa trên chuỗi? Bắt buộc một điều kiện chủng tộc

Có ai có bất kỳ liên kết nào để tham chiếu tài liệu mà tôi có thể tham khảo khi nói đến xử lý các chủ đề và thử nghiệm đơn vị không? Tôi đặc biệt quan tâm đến việc tạo ra tình trạng cuộc đua.

+0

Tôi cho rằng bạn sẽ giả lập bất kỳ cấu trúc dữ liệu được chia sẻ nào, và bên trong các đối tượng giả của bạn, bạn có thể thực hiện bất kỳ đồng bộ nào mà bạn cần để thực hiện các chủ đề khác nhau theo thứ tự "sai". –

Trả lời

4

Bạn phải đảm bảo rằng chuỗi sự kiện gây ra tình trạng cuộc đua thực sự phát sinh trong quá trình thử nghiệm. Đối với điều đó, bạn cần phải ảnh hưởng đến các sợi xen kẽ bên trong các trường hợp thử nghiệm.

Bạn có thể đạt được điều đó với đồng bộ hóa bổ sung (có điều kiện) hoặc bộ tính giờ bổ sung (đơn giản hơn và ít đáng tin cậy hơn). Đặt một số giấc ngủ() gọi vào các phần quan trọng để đảm bảo rằng chúng chạy đủ lâu để các luồng khác đến trạng thái không mong muốn. Khi bạn làm việc đó, hãy thay thế các cuộc gọi ngủ bằng đồng bộ hóa rõ ràng (nghĩa là chặn một luồng cho đến khi một chuỗi khác thực sự thừa nhận đã đến).

Sau đó, hãy thực hiện tất cả điều kiện này trên cờ toàn cầu được đặt bởi trường hợp kiểm tra.

+3

Tôi thành thật không nghĩ rằng khớp nối chặt chẽ mã sản xuất thực tế với thử nghiệm đặc biệt này là một ý tưởng tốt. Nó có nghĩa là bạn cần phải cẩn thận không làm khó chịu sự ghép nối đó bất cứ khi nào bạn cấu trúc lại mã, điều này đánh bại điểm của việc kiểm tra này ngay từ đầu. –

+0

Không, mảnh vỡ mong manh. để tái cấu trúc thực sự hỗ trợ phương pháp thử nghiệm này. Khi bạn refactor, bạn sẽ phải suy nghĩ lại các điều kiện chủng tộc. Sau đó, bạn có thể thấy rằng việc tái cấu trúc thực sự giới thiệu những cái mới, hoặc những cái mà trước đây nó dễ bị tổn thương không thể xảy ra nữa. –

+0

Tôi chỉ không thấy làm thế nào "lực lượng" bất cứ ai refactoring để suy nghĩ lại điều kiện chủng tộc tiềm năng, hoặc làm như vậy là thực sự hữu ích. Rõ ràng, suy nghĩ về điều kiện chủng tộc không hoạt động lần đầu tiên. Bất kỳ ai tái cấu trúc mã ở bất kỳ mức độ quan trọng nào đều phải ném mã kiểm tra hiện tại ra hoàn toàn và viết mã mới, hoặc làm cho mã kiểm tra vô dụng. Dù bằng cách nào, nó sẽ đánh bại mục đích của việc thử nghiệm mã. Tốt hơn là nên có mã kiểm tra không gây ô nhiễm cho codebase chính mà thay vào đó hãy gắn cờ xây dựng nếu bị hỏng. –

Các vấn đề liên quan