Điều gì cần kiểm tra khi viết Bài kiểm tra Đơn vị?

Question

Tôi muốn bắt đầu đơn vị thử nghiệm ứng dụng của chúng tôi, bởi vì tôi tin rằng đây là bước đầu tiên để phát triển mối quan hệ tốt với thử nghiệm và sẽ cho phép tôi phân nhánh thành các dạng thử nghiệm khác, BDD thú vị nhất với Cucumber.

Chúng tôi hiện đang tạo tất cả các lớp Cơ sở của chúng tôi bằng cách sử dụng Codesmith dựa hoàn toàn vào các bảng trong cơ sở dữ liệu. Tôi tò mò vì lợi ích của việc tạo ra các trường hợp thử nghiệm với các lớp cơ sở này? Đây có phải là thực hành thử nghiệm kém không?

Điều này dẫn tôi đến câu hỏi cuối cùng về bài đăng của tôi. Chúng ta thử nghiệm gì khi sử dụng các xét nghiệm đơn vị?

Chúng tôi có kiểm tra các ví dụ mà chúng tôi biết chúng tôi muốn không? hoặc chúng ta kiểm tra các ví dụ mà chúng ta không muốn?

Phương thức của họ có nhiều cách không thành công và nhiều cách thành công, làm sao chúng ta biết khi nào nên dừng?

Lấy chức năng Summing chẳng hạn. Cung cấp cho nó 1,2 và mong đợi 3 trong các bài kiểm tra đơn vị duy nhất .. làm thế nào để chúng ta biết rằng 5,6 không trở lại 35?

Câu hỏi Tóm tắt kiểm tra

• đơn vị Tạo (Tốt/Xấu)
• gì/bao nhiêu chúng tôi kiểm tra?

Answer 1

Điểm kiểm tra đơn vị là cung cấp cho bạn sự tự tin (nhưng chỉ trong trường hợp đặc biệt nó cho bạn chắc chắn) rằng hành vi thực tế của phương pháp công cộng của bạn phù hợp với hành vi mong đợi. Vì vậy, nếu bạn có một lớp Adder

class Adder { public int Add(int x, int y) { return x + y; } } 

và một đơn vị thử nghiệm tương ứng

[Test] 
public void Add_returns_that_one_plus_two_is_three() { 
    Adder a = new Adder(); 
    int result = a.Add(1, 2); 
    Assert.AreEqual(3, result); 
} 

thì đây cung cấp cho bạn một số (nhưng không phải 100%) tin tưởng rằng phương pháp thử được hành xử một cách thích hợp. Nó cũng mang lại cho bạn một số biện pháp phòng chống vi phạm mã khi tái cấu trúc.

Chúng tôi kiểm tra điều gì khi sử dụng Kiểm tra đơn vị?

Hành vi thực tế của các phương pháp công khai của bạn chống lại hành vi mong muốn (hoặc được chỉ định).

Chúng tôi có kiểm tra các ví dụ mà chúng tôi biết chúng tôi muốn không?

Có, một cách để có được sự tự tin về tính chính xác của phương pháp là lấy một số đầu vào với đầu ra được mong đợi, thực hiện phương pháp công khai trên đầu vào và so sánh đầu ra acutal với đầu ra mong đợi.

Answer 2

Bắt đầu với yêu cầu của bạn và viết các bài kiểm tra kiểm tra hành vi mong muốn. Từ thời điểm đó, có bao nhiêu kịch bản khác mà bạn thử nghiệm có thể được thúc đẩy bởi lịch biểu của bạn, hoặc có thể do bạn nhận ra các kịch bản phi thành công đặc biệt có nguy cơ cao. Bạn có thể xem xét việc viết các bài kiểm tra không thành công chỉ để trả lời các lỗi mà bạn (hoặc người dùng của bạn) phát hiện (ý tưởng là bạn viết một bài kiểm tra để kiểm tra lỗi sửa trước khi bạn thực sự sửa lỗi, để bài kiểm tra của bạn sẽ thất bại nếu lỗi đó được giới thiệu lại vào mã của bạn trong quá trình phát triển trong tương lai).

Answer 3

1) Để bắt đầu, tôi khuyên bạn nên kiểm tra logic cốt lõi của ứng dụng.

2) Sau đó, sử dụng công cụ bao phủ mã trong vs để xem liệu tất cả mã của bạn có được sử dụng trong các thử nghiệm hay không (tất cả các nhánh nếu có, điều kiện trường hợp được gọi). Đây là một số câu trả lời cho câu hỏi của bạn về thử nghiệm 1 + 2 = 3, 5 + 6 = 35: khi mã được bao phủ, bạn có thể cảm thấy an toàn với các thử nghiệm khác.

3) Đó là một thực hành tốt để trang trải 80-90% mã: phần còn lại của công việc thường unefficient: thu khí-setters, xử lý ngoại lệ trong 1 dòng vv

4) Tìm hiểu về tách mối quan tâm .

5) Thử nghiệm đơn vị thế hệ - hãy thử nó, bạn sẽ thấy, bạn có thể lưu một đoạn mã đẹp bằng văn bản theo cách thủ công. Tôi thích tạo ra các tập tin với vs, sau đó viết phần còn lại TestMethods của bản thân mình.

Answer 4

Điều gì cần kiểm tra: Mọi thứ đã từng sai.

Khi bạn tìm thấy lỗi, hãy viết kiểm tra cho hành vi lỗi trước bạn sửa mã. Sau đó, khi mã hoạt động chính xác, kiểm tra sẽ vượt qua và bạn sẽ có một thử nghiệm khác trong kho vũ khí của mình.

Answer 5

Bạn điều unittest nơi bạn

• muốn chắc chắn thuật toán của bạn hoạt động
• muốn bảo vệ chống lại những thay đổi bất ngờ trong tương lai

Vì vậy, trong ví dụ của bạn nó sẽ không có ý nghĩa nhiều để kiểm tra các lớp đã tạo. Kiểm tra máy phát điện để thay thế.

Thực hành tốt để kiểm tra các trường hợp sử dụng chính (trước tiên là chức năng được thử nghiệm được thiết kế cho). Sau đó, bạn kiểm tra các trường hợp lỗi chính. Sau đó, bạn viết các bài kiểm tra cho các trường hợp góc (nghĩa là giới hạn dưới và trên). Các trường hợp lỗi bất thường thường rất khó để tạo ra rằng nó không có ý nghĩa để kiểm tra đơn vị chúng.

Nếu bạn cần xác minh một phạm vi lớn các tập hợp thông số, hãy sử dụng kiểm tra theo hướng dữ liệu.

Có bao nhiêu điều bạn thử là nỗ lực so với trả lại, vì vậy nó thực sự phụ thuộc vào dự án riêng lẻ. Thông thường, bạn cố gắng tuân theo quy tắc 80/20, nhưng có thể có các ứng dụng mà bạn cần thêm phạm vi kiểm tra vì một sự cố sẽ có hậu quả rất nghiêm trọng.

Bạn có thể giảm đáng kể thời gian bạn cần để viết các bài kiểm tra nếu bạn sử dụng phương pháp thử nghiệm hướng (TDD). Đó là bởi vì mã không được viết với testability trong tâm trí là khó khăn hơn nhiều, đôi khi gần như không thể kiểm tra. Nhưng vì không có gì trong cuộc sống là miễn phí, mã được phát triển với TDD có xu hướng phức tạp hơn.

Answer 6

Tôi cũng bắt đầu quá trình sử dụng kiểm tra đơn vị một cách nhất quán hơn và những gì tôi thấy là nhiệm vụ lớn nhất trong thử nghiệm đơn vị là cấu trúc mã của tôi để hỗ trợ kiểm tra.Khi tôi bắt đầu suy nghĩ về cách viết các bài kiểm tra, nó trở nên rõ ràng nơi các lớp đã trở nên quá kết hợp, đến mức độ phức tạp của 'đơn vị' làm cho việc xác định các bài kiểm tra trở nên khó khăn. Tôi dành nhiều hoặc nhiều thời gian để tái cấu trúc mã của mình khi tôi viết bài kiểm tra. Khi ranh giới giữa các đơn vị có thể thử nghiệm trở nên rõ ràng hơn, câu hỏi về nơi bắt đầu kiểm tra sẽ tự giải quyết; bắt đầu với những phụ thuộc bị cô lập nhỏ nhất của bạn (hoặc ít nhất là những người bạn đang lo lắng) và làm việc theo cách của bạn.

Answer 7

Có ba sự kiện cơ bản tôi thử nghiệm cho: phút, tối đa và một nơi nào đó giữa min và max.

Và khi hai cực đại thích hợp: dưới min và cao hơn ở trên

Có ngoại lệ rõ ràng (một số mã có thể không có phút hoặc tối đa) nhưng tôi thấy rằng thử nghiệm đơn vị cho các sự kiện này là khởi đầu tốt và nắm bắt phần lớn các vấn đề "phổ biến" với mã.