Tôi chắc rằng hầu hết các bạn đang viết rất nhiều bài kiểm tra tự động và bạn cũng đã gặp phải một số cạm bẫy phổ biến khi kiểm thử đơn vị.
Câu hỏi của tôi là bạn có tuân theo bất kỳ quy tắc ứng xử nào cho các bài kiểm tra viết để tránh những rắc rối trong tương lai không? Cụ thể hơn: Các tính chất của bài kiểm tra đơn vị tốt là gì hoặc bạn viết bài kiểm tra của mình như thế nào?
Đề xuất ngôn ngữ bất khả tri được khuyến khích.
Câu trả lời:
Hãy để tôi bắt đầu bằng cách cắm các nguồn - Kiểm tra Đơn vị Thực dụng trong Java với JUnit (Có một phiên bản với C # -Nunit nữa .. nhưng tôi có cái này .. nó không khả thi cho hầu hết các phần. Được khuyến nghị.)
Bài kiểm tra tốt phải là MỘT CHUYẾN ĐI (Từ viết tắt không đủ dính - Tôi có một bản in của bảng gian lận trong cuốn sách mà tôi phải kéo ra để đảm bảo rằng tôi làm đúng ..)
Chuyên nghiệp : Về lâu dài, bạn sẽ có nhiều mã thử nghiệm như sản xuất (nếu không nhiều hơn), do đó hãy tuân theo cùng một tiêu chuẩn thiết kế tốt cho mã thử nghiệm của bạn. Các lớp phương thức được kiểm chứng tốt với các tên tiết lộ có chủ đích, Không trùng lặp, các bài kiểm tra có tên tốt, v.v.
Các bài kiểm tra tốt cũng chạy Nhanh . bất kỳ bài kiểm tra nào mất hơn nửa giây để chạy .. cần được thực hiện. Bộ thử nghiệm càng mất nhiều thời gian để chạy .. nó sẽ được chạy ít thường xuyên hơn. Càng có nhiều thay đổi, nhà phát triển sẽ cố gắng lén lút giữa các lần chạy .. nếu bất cứ điều gì bị hỏng .. sẽ mất nhiều thời gian hơn để tìm ra thay đổi nào là thủ phạm.
Cập nhật 2010-08:
Ngoài những điều này, hầu hết các hướng dẫn khác là các nguyên tắc cắt giảm công việc mang lại lợi ích thấp: ví dụ: 'Không kiểm tra mã mà bạn không sở hữu' (ví dụ: DLL của bên thứ ba). Đừng đi thử nghiệm getters và setters. Theo dõi tỷ lệ chi phí trên lợi ích hoặc xác suất sai sót.
Hầu hết các câu trả lời ở đây dường như đề cập đến các phương pháp hay nhất về kiểm thử đơn vị nói chung (khi nào, ở đâu, tại sao và cái gì), thay vì thực sự tự viết các bài kiểm tra (như thế nào). Vì câu hỏi có vẻ khá cụ thể về phần "làm thế nào", tôi nghĩ tôi sẽ đăng bài này, trích từ một bài thuyết trình về "chiếc túi nâu" mà tôi đã thực hiện tại công ty của mình.
1. Sử dụng tên phương pháp kiểm tra mô tả, dài.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Viết các bài kiểm tra của bạn theo kiểu Sắp xếp / Hành động / Khẳng định .
3. Luôn cung cấp thông báo lỗi với các Cảnh báo của bạn.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Nhận xét lý do thử nghiệm - giả định kinh doanh là gì?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
5. Mọi thử nghiệm phải luôn hoàn nguyên trạng thái của bất kỳ tài nguyên nào mà nó chạm vào
Hãy ghi nhớ những mục tiêu này (phỏng theo cuốn sách Các mẫu thử nghiệm xUnit của Meszaros)
Một số điều để làm cho việc này dễ dàng hơn:
Đừng quên rằng bạn cũng có thể thực hiện kiểm tra tích hợp với khuôn khổ xUnit của mình nhưng hãy giữ các kiểm tra tích hợp và kiểm tra đơn vị riêng biệt
Các thử nghiệm nên được cách ly. Một bài kiểm tra không nên phụ thuộc vào bài kiểm tra khác. Hơn nữa, một bài kiểm tra không nên dựa vào các hệ thống bên ngoài. Nói cách khác, hãy kiểm tra mã của bạn , không phải mã mà mã của bạn phụ thuộc vào. Bạn có thể kiểm tra những tương tác đó như một phần của quá trình tích hợp hoặc kiểm tra chức năng.
Một số thuộc tính của các bài kiểm tra đơn vị lớn:
Khi một bài kiểm tra không thành công, cần phải thấy ngay vấn đề nằm ở đâu. Nếu bạn phải sử dụng trình gỡ lỗi để theo dõi vấn đề, thì các thử nghiệm của bạn không đủ chi tiết. Có chính xác một khẳng định cho mỗi bài kiểm tra sẽ giúp ích ở đây.
Khi bạn cấu trúc lại, không có thử nghiệm nào bị lỗi.
Các bài kiểm tra sẽ chạy nhanh đến mức bạn không bao giờ ngần ngại khi chạy chúng.
Tất cả các bài kiểm tra phải luôn vượt qua; không có kết quả không xác định.
Các bài kiểm tra đơn vị phải được kiểm tra kỹ lưỡng, giống như mã sản xuất của bạn.
@Alotor: Nếu bạn đang gợi ý rằng một thư viện chỉ nên có các bài kiểm tra đơn vị tại API bên ngoài của nó, tôi không đồng ý. Tôi muốn các bài kiểm tra đơn vị cho từng lớp, bao gồm các lớp mà tôi không tiếp xúc với người gọi bên ngoài. (Tuy nhiên, nếu tôi cảm thấy cần phải viết các bài kiểm tra cho các phương thức riêng tư, thì tôi cần phải cấu trúc lại. )
CHỈNH SỬA: Có một nhận xét về sự trùng lặp do "một khẳng định cho mỗi thử nghiệm". Cụ thể, nếu bạn có một số mã để thiết lập một kịch bản và sau đó muốn thực hiện nhiều xác nhận về nó, nhưng chỉ có một xác nhận cho mỗi thử nghiệm, bạn có thể sao chép thiết lập qua nhiều thử nghiệm.
Tôi không áp dụng cách tiếp cận đó. Thay vào đó, tôi sử dụng đồ đạc thử nghiệm cho mỗi tình huống . Đây là một ví dụ sơ bộ:
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
Những gì bạn đang theo đuổi là mô tả các hành vi của lớp được kiểm tra.
Mục đích cơ bản là tăng cường sự tự tin của bạn trong hành vi của lớp.
Điều này đặc biệt hữu ích khi xem xét cấu trúc lại mã của bạn. Martin Fowler có một bài viết thú vị về việc thử nghiệm trên trang web của anh ấy.
HTH.
cổ vũ,
Rob
Kiểm tra ban đầu sẽ thất bại. Sau đó, bạn nên viết mã khiến chúng vượt qua, nếu không, bạn có nguy cơ viết một bài kiểm tra bị nghe trộm và luôn vượt qua.
Tôi thích từ viết tắt Right BICEP từ cuốn sách Kiểm tra Đơn vị Thực dụng đã nói ở trên :
Cá nhân tôi cảm thấy rằng bạn có thể tiến khá xa bằng cách kiểm tra xem bạn có nhận được kết quả phù hợp hay không (1 + 1 sẽ trả về 2 trong một hàm cộng), thử tất cả các điều kiện biên mà bạn có thể nghĩ đến (chẳng hạn như sử dụng hai số trong đó tổng lớn hơn giá trị tối đa số nguyên trong hàm thêm) và buộc các điều kiện lỗi như lỗi mạng.
Các bài kiểm tra tốt cần phải được duy trì.
Tôi chưa tìm ra cách thực hiện điều này cho các môi trường phức tạp.
Tất cả các sách giáo khoa bắt đầu không được dán khi cơ sở mã của bạn bắt đầu đạt đến hàng trăm 1000 hoặc hàng triệu dòng mã.
Kiến trúc tốt có thể kiểm soát một số sự bùng nổ tương tác, nhưng chắc chắn khi các hệ thống trở nên phức tạp hơn, hệ thống kiểm tra tự động sẽ phát triển cùng với nó.
Đây là nơi bạn bắt đầu phải đối mặt với sự đánh đổi:
Bạn cũng cần quyết định:
bạn lưu trữ các trường hợp thử nghiệm ở đâu trong cơ sở mã của bạn?
Tôi có thể đi mãi mãi, nhưng quan điểm của tôi là:
Các thử nghiệm cần phải được duy trì.
Tôi đã đề cập đến những nguyên tắc này một thời gian trong bài viết Tạp chí MSDN này mà tôi nghĩ là quan trọng đối với bất kỳ nhà phát triển nào nên đọc.
Cách tôi xác định các bài kiểm tra đơn vị "tốt" là nếu chúng có ba thuộc tính sau:
Jay Fields có rất nhiều lời khuyên tốt về cách viết các bài kiểm tra đơn vị và có một bài đăng mà anh ấy tóm tắt những lời khuyên quan trọng nhất . Ở đó, bạn sẽ đọc rằng bạn nên suy nghĩ chín chắn về bối cảnh của mình và đánh giá xem lời khuyên có đáng với bạn không. Bạn nhận được rất nhiều câu trả lời tuyệt vời ở đây, nhưng tùy thuộc vào bạn quyết định câu trả lời nào phù hợp nhất với ngữ cảnh của bạn. Hãy thử chúng và chỉ cần cấu trúc lại nếu nó có mùi khó chịu với bạn.
Trân trọng
Đừng bao giờ cho rằng phương thức 2 dòng tầm thường sẽ hoạt động. Viết một bài kiểm tra đơn vị nhanh là cách duy nhất để ngăn chặn bài kiểm tra rỗng bị thiếu, dấu trừ đặt sai vị trí và / hoặc lỗi xác định phạm vi tinh vi khiến bạn không thể tránh khỏi, khi bạn thậm chí còn ít thời gian để giải quyết nó hơn bây giờ.
Tôi thứ hai câu trả lời "MỘT CHUYẾN ĐI", ngoại trừ các bài kiểm tra NÊN dựa vào nhau !!!
Tại sao?
KHÔ - Không lặp lại chính mình - cũng áp dụng cho thử nghiệm! Kiểm tra phụ thuộc có thể giúp 1) tiết kiệm thời gian thiết lập, 2) tiết kiệm tài nguyên cố định và 3) xác định lỗi. Tất nhiên, chỉ khi khung thử nghiệm của bạn hỗ trợ các phụ thuộc hạng nhất. Nếu không, tôi thừa nhận, họ rất tệ.
Thông thường các bài kiểm tra đơn vị dựa trên đối tượng giả hoặc dữ liệu giả. Tôi muốn viết ba loại bài kiểm tra đơn vị:
Vấn đề là tránh phát lại mọi thứ để có thể kiểm tra mọi chức năng.
Tôi sử dụng quy ước đặt tên thử nghiệm nhất quán được mô tả bởi tiêu chuẩn Đặt tên đơn vị thử nghiệm của Roy Osherove Mỗi phương thức trong một lớp trường hợp thử nghiệm nhất định có kiểu đặt tên như sau MethodUnderTest_Scenario_EosystemResult.
Mỗi phần sử dụng Upper Camel Case và được phân định bằng điểm dưới.
Tôi đã thấy điều này hữu ích khi tôi chạy thử nghiệm, thử nghiệm được nhóm theo tên của phương pháp đang thử nghiệm. Và có một quy ước cho phép các nhà phát triển khác hiểu ý định thử nghiệm.
Tôi cũng nối các tham số vào tên Phương thức nếu phương thức đang kiểm tra đã bị quá tải.