Tại sao việc lặp lại chính mình bằng cách viết bài kiểm tra rất được khuyến khích?
Dường như các bài kiểm tra về cơ bản thể hiện điều tương tự như mã, và do đó là một bản sao (về khái niệm, không phải là triển khai) của mã. Mục tiêu cuối cùng của DRY sẽ không bao gồm loại bỏ tất cả các mã kiểm tra?
Câu trả lời:
Tôi tin rằng đây là một quan niệm sai lầm theo bất kỳ cách nào tôi có thể nghĩ ra.
Mã kiểm tra kiểm tra mã sản xuất hoàn toàn không giống nhau. Tôi sẽ chứng minh bằng python:
def multiply(a, b):
"""Multiply ``a`` by ``b``"""
return a*b
Sau đó, một bài kiểm tra đơn giản sẽ là:
def test_multiply():
assert multiply(4, 5) == 20
Cả hai chức năng có một định nghĩa tương tự nhưng cả hai đều làm những việc rất khác nhau. Không có mã trùng lặp ở đây. ;-)
Nó cũng xảy ra rằng mọi người viết các bài kiểm tra trùng lặp về cơ bản có một khẳng định cho mỗi chức năng kiểm tra. Đây là sự điên rồ và tôi đã thấy mọi người làm điều này. Đây là thực hành xấu.
def test_multiply_1_and_3():
"""Assert that a multiplication of 1 and 3 is 3."""
assert multiply(1, 3) == 3
def test_multiply_1_and_7():
"""Assert that a multiplication of 1 and 7 is 7."""
assert multiply(1, 7) == 7
def test_multiply_3_and_4():
"""Assert that a multiplication of 3 and 4 is 12."""
assert multiply(3, 4) == 12
Hãy tưởng tượng làm điều này cho hơn 1000 dòng mã hiệu quả. Thay vào đó, bạn kiểm tra trên cơ sở mỗi 'tính năng':
def test_multiply_positive():
"""Assert that positive numbers can be multiplied."""
assert multiply(1, 3) == 3
assert multiply(1, 7) == 7
assert multiply(3, 4) == 12
def test_multiply_negative():
"""Assert that negative numbers can be multiplied."""
assert multiply(1, -3) == -3
assert multiply(-1, -7) == 7
assert multiply(-3, 4) == -12
Bây giờ khi các tính năng được thêm / xóa, tôi chỉ phải xem xét thêm / xóa một chức năng kiểm tra.
Bạn có thể nhận thấy tôi đã không áp dụng forcác vòng lặp. Điều này là bởi vì lặp đi lặp lại một số điều là tốt. Khi tôi đã áp dụng các vòng lặp, mã sẽ ngắn hơn rất nhiều. Nhưng khi một xác nhận thất bại, nó có thể làm xáo trộn đầu ra hiển thị một thông điệp mơ hồ. Nếu điều này xảy ra thì các bài kiểm tra của bạn sẽ ít hữu ích hơn và bạn sẽ cần một trình gỡ lỗi để kiểm tra xem mọi thứ có vấn đề gì.
assert multiply(1,3)sẽ thất bại nhưng bạn cũng sẽ không nhận được báo cáo thử nghiệm thất bại assert multiply(3,4).
def test_shufflethực hiện hai xác nhận.
assert multiply(*, *) == *vì vậy bạn có thể định nghĩa một assert_multiplyhàm. Trong kịch bản hiện tại, nó không quan trọng bằng số lượng hàng và khả năng đọc, nhưng bằng các thử nghiệm dài hơn, bạn có thể sử dụng lại các xác nhận phức tạp, đồ đạc, mã tạo lịch thi đấu, v.v ... Tôi không biết liệu đây có phải là cách tốt nhất không, nhưng tôi thường làm điều này.
Có vẻ như các bài kiểm tra về cơ bản thể hiện điều tương tự như mã, và do đó là một bản sao
Không, đây không phải là sự thật.
Các thử nghiệm có một mục đích khác với việc thực hiện của bạn:
Mục tiêu cuối cùng của DRY sẽ không bao gồm loại bỏ tất cả các mã kiểm tra?
Không, mục tiêu cuối cùng của DRY thực sự có nghĩa là loại bỏ tất cả các mã sản xuất .
Nếu các thử nghiệm của chúng tôi có thể là thông số kỹ thuật hoàn hảo về những gì chúng tôi muốn hệ thống thực hiện, chúng tôi sẽ phải tự động tạo mã sản xuất (hoặc nhị phân), loại bỏ hiệu quả cơ sở mã sản xuất mỗi se.
Đây thực sự là những gì các phương pháp tiếp cận như kiến trúc hướng mô hình đòi hỏi phải đạt được - một nguồn sự thật do con người thiết kế từ đó mọi thứ bắt nguồn từ tính toán.
Tôi không nghĩ rằng điều ngược lại (loại bỏ tất cả các bài kiểm tra) là mong muốn bởi vì:
Bởi vì đôi khi lặp lại chính mình là được. Không có nguyên tắc nào trong số này có nghĩa là được thực hiện trong mọi tình huống mà không có câu hỏi hoặc bối cảnh. Đôi khi tôi có các bài kiểm tra viết đối với phiên bản ngây thơ (và chậm) của thuật toán, đây là một vi phạm khá rõ ràng về DRY, nhưng chắc chắn có lợi.
Vì kiểm thử đơn vị là về việc làm cho những thay đổi không chủ ý trở nên khó khăn hơn, đôi khi nó cũng có thể làm cho những thay đổi có chủ ý trở nên khó khăn hơn. Thực tế này thực sự liên quan đến nguyên tắc DRY.
Ví dụ: nếu bạn có một hàm MyFunctionđược gọi trong mã sản xuất chỉ ở một nơi và bạn viết 20 bài kiểm tra đơn vị cho nó, bạn có thể dễ dàng có 21 vị trí trong mã của mình nơi hàm đó được gọi. Bây giờ, khi bạn phải thay đổi chữ ký của MyFunction, hoặc ngữ nghĩa hoặc cả hai (vì một số yêu cầu thay đổi), bạn có 21 địa điểm để thay đổi thay vì chỉ một. Và lý do thực sự là vi phạm nguyên tắc DRY: bạn lặp lại (ít nhất) cùng một chức năng gọi đến MyFunction21 lần.
Cách tiếp cận đúng cho trường hợp như vậy là áp dụng nguyên tắc DRY cho mã kiểm tra của bạn: khi viết 20 bài kiểm tra đơn vị, đóng gói các cuộc gọi đến MyFunctiontrong bài kiểm tra đơn vị của bạn chỉ trong một vài chức năng của trình trợ giúp (lý tưởng chỉ là một), được sử dụng bởi 20 bài kiểm tra đơn vị. Lý tưởng nhất, bạn kết thúc chỉ với hai vị trí trong cuộc gọi mã của bạn MyFunction: một từ mã sản xuất của bạn và một từ các bài kiểm tra đơn vị của bạn. Vì vậy, khi bạn phải thay đổi chữ ký MyFunctionsau này, bạn sẽ chỉ có một vài nơi để thay đổi trong các bài kiểm tra của mình.
"Một vài nơi" vẫn còn nhiều hơn "một nơi" (những gì bạn nhận được mà không có bài kiểm tra đơn vị nào ), nhưng lợi thế của việc kiểm tra đơn vị sẽ vượt xa lợi thế của việc thay đổi ít mã hơn (nếu không bạn hoàn thành kiểm tra đơn vị Sai lầm).
Một trong những thách thức lớn nhất để xây dựng phần mềm là nắm bắt các yêu cầu; đó là trả lời câu hỏi "phần mềm này nên làm gì?" Phần mềm cần các yêu cầu chính xác để xác định chính xác những gì hệ thống cần làm, nhưng những người xác định nhu cầu cho các hệ thống và dự án phần mềm thường bao gồm những người không có nền tảng phần mềm hoặc chính thức (toán học). Việc thiếu sự nghiêm ngặt trong định nghĩa yêu cầu buộc phải phát triển phần mềm để tìm cách xác nhận phần mềm theo yêu cầu.
Nhóm phát triển thấy mình dịch các mô tả thông tục cho một dự án thành các yêu cầu khắt khe hơn. Kỷ luật kiểm thử đã kết hợp thành điểm kiểm tra để phát triển phần mềm, để thu hẹp khoảng cách giữa những gì khách hàng nói họ muốn và phần mềm hiểu họ muốn gì. Cả nhà phát triển phần mềm và nhóm kiểm tra chất lượng / hình thức đều hiểu về đặc tả (không chính thức) và từng phần mềm (độc lập) viết phần mềm hoặc kiểm tra để đảm bảo rằng sự hiểu biết của họ phù hợp. Thêm một người khác để hiểu các yêu cầu (không chính xác) đã thêm các câu hỏi và quan điểm khác nhau để tăng thêm độ chính xác của các yêu cầu.
Vì luôn có thử nghiệm chấp nhận, nên việc mở rộng vai trò thử nghiệm để viết thử nghiệm tự động và đơn vị là điều đương nhiên. Vấn đề là điều đó có nghĩa là thuê các lập trình viên thực hiện kiểm thử, và do đó bạn thu hẹp quan điểm từ đảm bảo chất lượng sang lập trình viên thực hiện kiểm thử.
Như đã nói, có lẽ bạn đang kiểm tra sai nếu các bài kiểm tra của bạn khác với các chương trình thực tế. Đề nghị của Msdy sẽ tập trung nhiều hơn vào những gì trong các bài kiểm tra, và ít hơn về cách thức.
Điều trớ trêu là thay vì nắm bắt một đặc tả chính thức của các yêu cầu từ mô tả thông tục, ngành công nghiệp đã chọn thực hiện các bài kiểm tra điểm dưới dạng mã để tự động kiểm tra. Thay vì đưa ra các yêu cầu chính thức mà phần mềm có thể được xây dựng để trả lời, cách tiếp cận được thực hiện là kiểm tra một vài điểm, thay vì tiếp cận phần mềm xây dựng bằng logic chính thức. Đây là một sự thỏa hiệp, nhưng đã khá hiệu quả và tương đối thành công.
Nếu bạn nghĩ rằng mã kiểm tra của bạn quá giống với mã triển khai của bạn, thì đây có thể là một dấu hiệu cho thấy bạn đang sử dụng quá mức một khung mô phỏng. Thử nghiệm dựa trên giả ở mức quá thấp có thể kết thúc với thiết lập thử nghiệm trông rất giống phương pháp đang được thử nghiệm. Cố gắng viết các bài kiểm tra cấp cao hơn mà ít có khả năng phá vỡ hơn nếu bạn thay đổi triển khai của mình (tôi biết điều này có thể khó, nhưng nếu bạn có thể quản lý nó, bạn sẽ có một bộ kiểm tra hữu ích hơn).
Các thử nghiệm đơn vị không nên bao gồm một bản sao của mã được thử nghiệm, như đã được lưu ý.
Tuy nhiên, tôi sẽ thêm rằng các thử nghiệm đơn vị đó thường không phải là mã DRY như mã "sản xuất", bởi vì thiết lập có xu hướng tương tự (nhưng không giống nhau) trong các thử nghiệm ... đặc biệt là nếu bạn có một số lượng phụ thuộc đáng kể mà bạn đang chế giễu / giả mạo.
Tất nhiên có thể cấu trúc lại thứ này thành một phương thức thiết lập chung (hoặc tập hợp các phương thức thiết lập) ... nhưng tôi thấy rằng các phương thức thiết lập đó có xu hướng có danh sách tham số dài và khá dễ vỡ.
Vì vậy, hãy thực dụng. Nếu bạn có thể hợp nhất mã thiết lập mà không ảnh hưởng đến khả năng bảo trì, bằng mọi cách hãy làm điều đó. Nhưng nếu giải pháp thay thế là một tập hợp các phương thức thiết lập phức tạp và dễ vỡ, một chút lặp lại trong các phương thức kiểm tra của bạn là OK.
Một nhà truyền giáo TDD / BDD địa phương nói theo cách này:
"Mã sản xuất của bạn phải là DRY. Nhưng thử nghiệm của bạn là 'ẩm'.
Dường như các bài kiểm tra về cơ bản thể hiện điều tương tự như mã, và do đó là một bản sao (về khái niệm, không phải là triển khai) của mã.
Điều này không đúng, các kiểm tra mô tả các trường hợp sử dụng, trong khi mã mô tả một thuật toán vượt qua các trường hợp sử dụng, vì vậy, tổng quát hơn. Bằng TDD, bạn bắt đầu bằng cách viết các ca sử dụng (có thể dựa trên câu chuyện của người dùng) và sau đó bạn triển khai mã cần thiết để vượt qua các ca sử dụng này. Vì vậy, bạn viết một bài kiểm tra nhỏ, một đoạn mã nhỏ và sau đó bạn cấu trúc lại nếu cần thiết để thoát khỏi sự lặp lại. Đó là cách nó hoạt động.
Bằng các bài kiểm tra có thể có sự lặp lại là tốt. Ví dụ: bạn có thể sử dụng lại đồ đạc, mã tạo lịch thi đấu, xác nhận phức tạp, v.v ... Tôi thường làm điều này, để ngăn ngừa lỗi trong các bài kiểm tra, nhưng tôi thường quên kiểm tra trước xem thử nghiệm có thực sự thất bại không và nó có thực sự phá hỏng ngày không , khi bạn đang tìm kiếm lỗi trong mã trong nửa giờ và thử nghiệm sai ... xD