2010-12-15 44 views
6

Tôi chỉ cần kiểm tra đơn vị một số phương pháp như thế này:Chủ đề thử nghiệm đơn vị?

public void start() 
{ 
    myThread.Start(); 
} 

public void stop() 
{ 
    myThread.Abort(); 
} 

Làm thế nào tôi có thể làm điều đó? Tôi có thể gọi phương thức start và kiểm tra IsAlive == true nhưng sau đó thread tiếp tục làm việc ở chế độ nền và gọi phương thức riêng của nó. Một cách khác là tôi gọi bắt đầu và sau đó dừng lại ngay lập tức nhưng nó không gọn gàng vì nó sẽ giống như tôi đang thử nghiệm hai thứ. Nó thật đơn giản nhưng thật đáng kinh ngạc!

Trả lời

0

Tại sao bạn cần đơn vị kiểm tra các phương pháp đó? Bạn đang cố gắng xác minh điều gì? Các thử nghiệm khác có phá vỡ nếu điều bạn đang cố gắng xác minh không đúng không? (IE có được kiểm tra bởi các thử nghiệm khác không?)

Nếu không, bạn có thể tham gia vào semaphores và kiểm tra đơn vị của bạn đảm bảo rằng chuỗi đã khởi động trước một thời gian chờ nhất định, nhưng tôi không nghĩ nó cực kỳ có giá trị kiểm tra cuối cùng. Nó sẽ không làm tăng sự tự tin của tôi nhiều.

2

Một ý tưởng hay là làm cho những thứ phụ thuộc vào thời gian sẽ đồng bộ với mục đích thử nghiệm. (Thật vậy, tốt hơn là nên địa phương hóa các tương tác theo thời gian ngay cả khi không sử dụng thử nghiệm.)

Nếu bạn thực sự muốn kiểm tra xem các phương pháp này có bắt đầu và dừng chuỗi không, tôi sẽ chèn một đối tượng giả myThread những phương pháp đó nhưng không thực sự bắt đầu một chuỗi, hoặc một chuỗi có mã sẽ chỉ ngồi và đợi mà không làm bất cứ điều gì. Sau đó, bạn có thể ghi lại rằng nó bắt đầu, và dừng lại, mà không lo lắng về sự phức tạp của những gì thread thực sự của bạn sẽ làm gì.

Có lẽ tình huống của bạn phức tạp hơn là chỉ kiểm tra chuỗi được bắt đầu? Nó có thể hữu ích nếu bạn đăng một ví dụ lớn hơn một chút về loại điều bạn muốn thử nghiệm.

1

Tôi đồng ý với BnWasteland rằng đối với ví dụ mã đã cho, điều duy nhất người ta có thể kiểm tra là System.Threading.Thread.Start và System.Threading.Thread.Abort hoạt động đúng cách. Vì vậy, nó sẽ là hợp lý để giả định rằng họ đang có và tập trung vào mã riêng của ứng dụng. Sau đó, bạn có hai tên miền:

1) Mã của tác vụ thực tế thực thi bên trong chuỗi. Điều này có thể được kiểm tra trong một thử nghiệm đơn vị bình thường.

2) Đảm bảo cơ sở hạ tầng đa luồng hoạt động như mong đợi.

(2) có xu hướng nhiều hơn đối với danh mục Thử nghiệm tích hợp nhưng không ai cấm sử dụng khung Đơn vị tesitng cho việc này. Và trong trường hợp này, bạn nên bắt đầu/dừng và thậm chí làm điều này nhiều lần với một số khối lượng công việc ngẫu nhiên chỉ để đảm bảo hệ thống hoạt động và hoàn thành công việc. Điều này rõ ràng là đi vào bộ thử nghiệm "chạy dài hơn" mà bạn không cần thiết phải thực hiện tại mọi lần đăng ký.

6

Bí quyết là tách riêng hành vi không đồng bộ khỏi logic của bạn. Quan sát rằng logic thực sự của bạn là đồng bộ, và rằng phần không đồng bộ chỉ đơn giản là một số "thời gian chờ đợi" ở giữa.

Sách xUnit Test Patterns mô tả tốt. Nó thậm chí là một mẫu - Humble Object. Nó được giải thích có cách tốt hơn tôi có thể.