Nó là.
Ngay cả khi bạn chỉ thực hiện thử nghiệm đơn vị, không có gì bất thường khi có nhiều mã trong các thử nghiệm hơn mã thực tế được thử nghiệm. Không có gì là sai với nó.
Hãy xem xét một mã đơn giản:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
Điều gì sẽ là các bài kiểm tra? Có ít nhất bốn trường hợp đơn giản để kiểm tra ở đây:
Tên người là null. Là ngoại lệ thực sự ném? Đó là ít nhất ba dòng mã kiểm tra để viết.
Tên người là "Jeff". Chúng ta có nhận được "Hello, Jeff!"phản hồi không? Đó là bốn dòng mã kiểm tra.
Tên người là một chuỗi rỗng. Sản lượng nào chúng ta mong đợi? Sản lượng thực tế là gì? Câu hỏi phụ: nó có phù hợp với các yêu cầu chức năng không? Điều đó có nghĩa là bốn dòng mã khác cho bài kiểm tra đơn vị.
Tên người đủ ngắn cho một chuỗi, nhưng quá dài để kết hợp với "Hello, "và dấu chấm than. Chuyện gì xảy ra vậy?
Điều này đòi hỏi rất nhiều mã thử nghiệm. Hơn nữa, các đoạn mã cơ bản nhất thường yêu cầu mã thiết lập để khởi tạo các đối tượng cần thiết cho mã đang được thử nghiệm, điều này cũng thường dẫn đến việc viết sơ khai và giả, v.v.
Nếu tỷ lệ này rất lớn, trong trường hợp đó bạn có thể kiểm tra một số điều:
Có sao chép mã qua các bài kiểm tra? Thực tế là mã kiểm tra không có nghĩa là mã phải được sao chép (dán sao chép) giữa các thử nghiệm tương tự: việc sao chép như vậy sẽ khiến việc duy trì các thử nghiệm đó trở nên khó khăn.
Có các bài kiểm tra dư thừa? Theo nguyên tắc thông thường, nếu bạn loại bỏ một bài kiểm tra đơn vị, phạm vi bảo hiểm của chi nhánh sẽ giảm. Nếu không, nó có thể chỉ ra rằng thử nghiệm là không cần thiết, vì các đường dẫn đã được bao phủ bởi các thử nghiệm khác.
Bạn đang kiểm tra chỉ mã bạn nên kiểm tra? Bạn không cần phải kiểm tra khung cơ bản của các thư viện bên thứ ba, mà chỉ riêng mã của dự án.
Với các thử nghiệm khói, thử nghiệm hệ thống và tích hợp, thử nghiệm chức năng và chấp nhận và thử nghiệm căng thẳng và tải trọng, bạn thêm nhiều mã thử nghiệm hơn, do đó, có bốn hoặc năm LỘC thử nghiệm cho mỗi LỘC của mã thực tế không phải là điều bạn nên lo lắng.
Một lưu ý về TDD
Nếu bạn lo lắng về thời gian cần thiết để kiểm tra mã của mình, có thể bạn đang làm sai, đó là mã trước, kiểm tra sau. Trong trường hợp này, TDD có thể giúp đỡ bằng cách khuyến khích bạn làm việc trong các lần lặp 15-45 giây, chuyển đổi giữa mã và kiểm tra. Theo những người đề xuất TDD, nó tăng tốc quá trình phát triển bằng cách giảm cả số lượng thử nghiệm bạn cần làm và quan trọng hơn là số lượng mã doanh nghiệp để viết và đặc biệt là viết lại để thử nghiệm.
Gọi n là độ dài tối đa của một chuỗi . Chúng ta có thể gọi SayHellovà chuyển qua tham chiếu một chuỗi có độ dài n - 1 sẽ hoạt động tốt. Bây giờ, tại Console.WriteLinebước, định dạng sẽ kết thúc bằng một chuỗi có độ dài n + 8, điều này sẽ dẫn đến một ngoại lệ. Có thể, do giới hạn bộ nhớ, ngay cả một chuỗi chứa n / 2 ký tự sẽ dẫn đến một ngoại lệ. Câu hỏi người ta nên đặt ra là liệu thử nghiệm thứ tư này có phải là thử nghiệm đơn vị không (trông giống như thử nghiệm này, nhưng có thể có tác động cao hơn nhiều về mặt tài nguyên so với thử nghiệm đơn vị trung bình) và nếu thử nghiệm mã thực tế hoặc khung cơ bản.