Chúng ta có nên viết bài kiểm tra cho getters và setters của chúng tôi hay nó là quá mức cần thiết?

Tôi sẽ nói không.

@Will nói rằng bạn nên nhắm đến phạm vi bảo hiểm 100% mã, nhưng theo tôi đó là một sự phân tâm nguy hiểm. Bạn có thể viết các bài kiểm tra đơn vị có phạm vi bảo hiểm 100%, nhưng kiểm tra hoàn toàn không có gì.

Các bài kiểm tra đơn vị ở đó để kiểm tra hành vi của mã của bạn, theo cách biểu cảm và có ý nghĩa, và getters / setters chỉ là một phương tiện để kết thúc. Nếu bạn kiểm tra sử dụng getters / setters để đạt được mục tiêu kiểm tra chức năng "thực" của họ, thì điều đó đủ tốt.

Mặt khác, nếu các getters và setters của bạn làm nhiều hơn là chỉ lấy và thiết lập (tức là chúng là các phương thức phức tạp đúng cách), thì có, chúng nên được kiểm tra. Nhưng đừng viết một trường hợp thử nghiệm đơn vị chỉ để kiểm tra một getter hoặc setters, đó là một sự lãng phí thời gian.

Roy Osherove trong cuốn sách nổi tiếng 'Nghệ thuật kiểm tra đơn vị' nói:

Các thuộc tính (getters / setters trong Java) là các ví dụ tốt về mã thường không chứa bất kỳ logic nào và không yêu cầu thử nghiệm. Nhưng xem ra: một khi bạn thêm bất kỳ kiểm tra nào bên trong tài sản, bạn sẽ muốn đảm bảo rằng logic đang được kiểm tra.

CÓ TUYỆT VỜI với TDD

Lưu ý : Câu trả lời này tiếp tục nhận được sự ủng hộ, mặc dù có khả năng là một lời khuyên tồi. Để hiểu lý do tại sao, hãy nhìn vào em gái của nó dưới đây.

Tranh cãi không sao, nhưng tôi cho rằng bất cứ ai trả lời 'không' cho câu hỏi này đều thiếu một khái niệm cơ bản về TDD.

Đối với tôi, câu trả lời là có, nếu bạn theo TDD. Nếu bạn không thì không có câu trả lời hợp lý.

DDD trong TDD

TDD thường được trích dẫn là có lợi ích chính.

• Phòng thủ
  • Đảm bảo mã có thể thay đổi nhưng không phải là hành vi của nó .
  • Điều này cho phép thực hành tái cấu trúc rất quan trọng .
  • Bạn có đạt được TDD này hay không.
• Thiết kế
  • Bạn chỉ định những gì nên làm, làm thế nào nó nên hành xử trước khi thực hiện nó.
  • Điều này thường có nghĩa là quyết định thực hiện nhiều thông tin hơn .
• Tài liệu
  • Bộ thử nghiệm phải đóng vai trò là tài liệu đặc tả (yêu cầu).
  • Sử dụng các thử nghiệm cho mục đích như vậy có nghĩa là tài liệu và việc thực hiện luôn ở trạng thái nhất quán - thay đổi cái này có nghĩa là thay đổi cái khác. So sánh với các yêu cầu giữ và thiết kế trên tài liệu từ riêng biệt.

Tách trách nhiệm khỏi việc thực hiện

Là những lập trình viên, sẽ rất hấp dẫn khi nghĩ về các thuộc tính như một thứ gì đó có ý nghĩa và getters và setter như một loại chi phí nào đó.

Nhưng các thuộc tính là một chi tiết triển khai, trong khi setters và getters là giao diện hợp đồng thực sự làm cho các chương trình hoạt động.

Điều quan trọng hơn nhiều là đánh vần rằng một đối tượng nên:

Cho phép khách hàng của mình thay đổi trạng thái

và

Cho phép khách hàng truy vấn trạng thái của nó

sau đó làm thế nào trạng thái này thực sự được lưu trữ (trong đó một thuộc tính là phổ biến nhất, nhưng không phải là cách duy nhất).

Một bài kiểm tra như

(The Painter class) should store the provided colour

rất quan trọng đối với phần tài liệu của TDD.

Thực tế là việc thực hiện cuối cùng là tầm thường (thuộc tính) và không mang lại lợi ích phòng thủ nên bạn không biết khi viết bài kiểm tra.

Thiếu kỹ thuật khứ hồi ...

Một trong những vấn đề chính trong thế giới phát triển hệ thống là thiếu kỹ thuật khứ hồi ¹ - quá trình phát triển của một hệ thống được phân chia thành các quy trình phụ rời rạc, các tạo phẩm trong đó (tài liệu, mã) thường không nhất quán.

_{¹ Brodie, Michael L. "John Mylopoulos: may hạt giống của mô hình khái niệm." Mô hình hóa khái niệm: Nền tảng và ứng dụng. Springer Berlin Heidelberg, 2009. 1-9.}

... và cách TDD giải quyết nó

Đây là tài liệu của TDD đảm bảo rằng các thông số kỹ thuật của hệ thống và mã của nó luôn nhất quán.

Thiết kế trước, thực hiện sau

Trong TDD, chúng tôi viết bài kiểm tra chấp nhận thất bại trước, chỉ sau đó viết mã cho phép chúng vượt qua.

Trong BDD cấp cao hơn, chúng tôi viết các kịch bản trước, sau đó làm cho chúng vượt qua.

Tại sao bạn nên loại trừ setters và getter?

Về lý thuyết, một người hoàn toàn có thể trong TDD để một người viết bài kiểm tra và một người khác thực hiện mã làm cho nó vượt qua.

Vì vậy, hãy tự hỏi:

Người viết bài kiểm tra cho một lớp có đề cập đến getters và setter không.

Vì getters và setters là một giao diện chung cho một lớp, câu trả lời rõ ràng là có , hoặc sẽ không có cách nào để thiết lập hoặc truy vấn trạng thái của một đối tượng. Tuy nhiên , cách để làm điều này không nhất thiết bằng cách thử nghiệm từng phương pháp một cách riêng biệt, hãy xem câu trả lời khác của tôi để biết thêm.

Rõ ràng, nếu bạn viết mã trước, câu trả lời có thể không rõ ràng lắm.

tl; dr: Có, bạn nên và với OpenPojo, điều đó thật tầm thường.

1. Bạn nên thực hiện một số xác nhận trong getters và setters của bạn để bạn nên kiểm tra điều đó. Ví dụ, setMom(Person p)không nên cho phép bất cứ ai trẻ hơn mình là mẹ của họ.

2. Ngay cả khi bạn không làm bất cứ điều gì trong số đó bây giờ, tỷ lệ cược là bạn sẽ có trong tương lai, thì điều này sẽ tốt cho phân tích hồi quy. Nếu bạn muốn cho phép thiết lập các bà mẹ cho nullbạn, bạn nên có một bài kiểm tra để ai đó thay đổi điều đó sau này, điều này sẽ củng cố các giả định của bạn.

3. Một lỗi phổ biến là void setFoo( Object foo ){ foo = foo; }nơi nó nên được void setFoo( Object foo ){ this.foo = foo; }. (Trong trường hợp đầu tiên, foocái được ghi là tham số không phải là footrường trên đối tượng ).

4. Nếu bạn đang trả về một mảng hoặc bộ sưu tập, bạn nên kiểm tra xem getter có thực hiện các bản sao phòng thủ của dữ liệu được truyền vào setter hay không trước khi quay trở lại.

5. Mặt khác, nếu bạn có các setters / getters cơ bản nhất thì việc kiểm tra đơn vị chúng sẽ thêm tối đa khoảng 10 phút cho mỗi đối tượng, vậy mất mát là gì? Nếu bạn thêm hành vi, bạn đã có một bài kiểm tra bộ xương và bạn được kiểm tra hồi quy miễn phí. Nếu bạn đang sử dụng Java, bạn không có lý do gì vì có OpenPojo . Có một bộ quy tắc hiện có mà bạn có thể kích hoạt và sau đó quét toàn bộ dự án của bạn với chúng để đảm bảo chúng được áp dụng nhất quán trong mã của bạn.

Từ ví dụ của họ :

final PojoValidator pojoValidator = new PojoValidator();

//create rules
pojoValidator.addRule( new NoPublicFieldsRule  () );
pojoValidator.addRule( new NoPrimitivesRule    () );
pojoValidator.addRule( new GetterMustExistRule () );
pojoValidator.addRule( new SetterMustExistRule () );

//create testers
pojoValidator.addTester( new DefaultValuesNullTester () );
pojoValidator.addTester( new SetterTester            () );
pojoValidator.addTester( new GetterTester            () );

//test all the classes
for(  PojoClass  pojoClass :  PojoClassFactory.getPojoClasses( "net.initech.app", new FilterPackageInfo() )  )
    pojoValidator.runValidation( pojoClass );

Có, nhưng không phải lúc nào cũng cô lập

Cho phép tôi giải thích:

Một bài kiểm tra đơn vị là gì?

Từ làm việc hiệu quả với mã kế thừa ¹ :

Bài kiểm tra đơn vị có một lịch sử lâu dài trong phát triển phần mềm. Phổ biến đối với hầu hết các khái niệm về kiểm thử đơn vị là ý tưởng rằng chúng là các thử nghiệm tách biệt với các thành phần riêng lẻ của phần mềm. Các thành phần là gì? Định nghĩa khác nhau, nhưng trong thử nghiệm đơn vị, chúng ta thường quan tâm đến các đơn vị hành vi nguyên tử nhất của một hệ thống. Trong mã thủ tục, các đơn vị thường là chức năng. Trong mã hướng đối tượng, các đơn vị là các lớp.

Lưu ý rằng với OOP, nơi bạn tìm thấy getters và setters, đơn vị là lớp , không nhất thiết là các phương thức riêng lẻ .

Một bài kiểm tra tốt là gì?

Tất cả các yêu cầu và kiểm tra tuân theo hình thức logic Hoare :

{P} C {Q}

Ở đâu:

• {P}là điều kiện tiên quyết ( được đưa ra )
• Clà điều kiện kích hoạt ( khi )
• {Q}là hậu họa ( sau đó )

Rồi đến câu châm ngôn:

Kiểm tra hành vi, không thực hiện

Điều này có nghĩa là bạn không nên kiểm tra làm thế nào Cđạt được điều kiện hậu, bạn nên kiểm tra xem đó {Q}là kết quả của C.

Khi nói đến OOP, Clà một lớp học. Vì vậy, bạn không nên kiểm tra hiệu ứng bên trong, chỉ có tác động bên ngoài.

Tại sao không kiểm tra getters đậu và setters trong sự cô lập

Getters và setters có thể liên quan đến một số logic, nhưng rất lâu logic này không có tác dụng bên ngoài - làm cho chúng trở thành các trình truy cập bean ² ) một bài kiểm tra sẽ phải nhìn vào bên trong đối tượng và không chỉ vi phạm đóng gói mà còn kiểm tra việc thực hiện.

Vì vậy, bạn không nên kiểm tra getters đậu và setters trong sự cô lập. Điều này tệ đây:

Describe 'LineItem class'

    Describe 'setVAT()'

        it 'should store the VAT rate'

            lineItem = new LineItem()
            lineItem.setVAT( 0.5 )
            expect( lineItem.vat ).toBe( 0.5 )

Mặc dù nếu setVATném một ngoại lệ, một thử nghiệm tương ứng sẽ phù hợp vì bây giờ có hiệu ứng bên ngoài.

Làm thế nào bạn nên kiểm tra getters và setters?

Hầu như không có điểm nào thay đổi trạng thái bên trong của một đối tượng nếu sự thay đổi đó không có tác dụng ở bên ngoài, ngay cả khi hiệu ứng đó xuất hiện sau đó.

Vì vậy, một thử nghiệm cho setters và getters nên được quan tâm với tác động bên ngoài của các phương thức này, chứ không phải các phương pháp bên trong.

Ví dụ:

Describe 'LineItem class'

    Describe 'getGross()'

        it 'should return the net time the VAT'

            lineItem = new LineItem()
            lineItem.setNet( 100 )
            lineItem.setVAT( 0.5 )
            expect( lineItem.getGross() ).toBe( 150 )

Bạn có thể tự nghĩ:

Đợi một chút, chúng tôi đang thử nghiệm getGross()ở đây không setVAT() .

Nhưng nếu setVAT()trục trặc mà kiểm tra nên thất bại tất cả như nhau.

_{¹ Feathers, M., 2004. Làm việc hiệu quả với mã kế thừa. Hội trường Prentice chuyên nghiệp.}

_{² Martin, RC, 2009. Mã sạch: một cuốn sổ tay về sự khéo léo của phần mềm. Giáo dục Pearson.}

Mặc dù có những lý do chính đáng cho các Thuộc tính, nhưng có một niềm tin Thiết kế hướng đối tượng chung rằng việc phơi bày trạng thái thành viên thông qua Thuộc tính là thiết kế xấu. Bài viết của Robert Martin về Nguyên tắc đóng mở mở mở rộng dựa trên điều này bằng cách nói rằng Thuộc tính khuyến khích khớp nối và do đó hạn chế khả năng đóng một lớp khỏi sửa đổi - nếu bạn sửa đổi thuộc tính, tất cả người tiêu dùng của lớp cũng sẽ cần thay đổi. Anh ta đủ điều kiện để lộ các biến thành viên không nhất thiết là thiết kế xấu, nó có thể chỉ là phong cách kém. Tuy nhiên, nếu các thuộc tính chỉ đọc, sẽ có ít cơ hội lạm dụng và tác dụng phụ hơn.

Cách tiếp cận tốt nhất tôi có thể cung cấp để thử nghiệm đơn vị (và điều này có vẻ kỳ lạ) là tạo ra càng nhiều thuộc tính càng tốt được bảo vệ hoặc nội bộ. Điều này sẽ ngăn khớp nối trong khi không khuyến khích viết các bài kiểm tra ngớ ngẩn cho getters và setters.

Có những lý do rõ ràng trong đó các thuộc tính đọc / ghi nên được sử dụng, chẳng hạn như các thuộc tính ViewModel được liên kết với các trường đầu vào, v.v.

Thực tế hơn, các bài kiểm tra đơn vị nên điều khiển chức năng thông qua các phương thức công khai. Nếu mã bạn đang kiểm tra tình cờ sử dụng các thuộc tính đó, bạn sẽ được bảo hiểm mã miễn phí. Nếu nó chỉ ra rằng các thuộc tính này không bao giờ được làm nổi bật bởi phạm vi bảo hiểm mã thì có khả năng rất lớn là:

1. Bạn đang thiếu các bài kiểm tra gián tiếp sử dụng các thuộc tính
2. Các tài sản không được sử dụng

Nếu bạn viết các bài kiểm tra cho getters và setters, bạn sẽ có cảm giác sai về phạm vi bảo hiểm và sẽ không thể xác định liệu các thuộc tính có thực sự được sử dụng bởi hành vi chức năng hay không.

Nếu độ phức tạp chu kỳ của getter và / hoặc setter là 1 (mà chúng thường là), thì câu trả lời là không, bạn không nên.

Vì vậy, trừ khi bạn có SLA yêu cầu bảo hiểm mã 100%, đừng bận tâm và tập trung vào kiểm tra khía cạnh quan trọng của phần mềm của bạn.

PS Hãy nhớ phân biệt getters và setters, ngay cả trong các ngôn ngữ như C # nơi các thuộc tính có thể giống như điều tương tự. Độ phức tạp setter có thể cao hơn getter và do đó xác nhận một bài kiểm tra đơn vị.

Một cách hài hước, nhưng khôn ngoan: Con đường của Testivus

"Viết bài kiểm tra bạn có thể hôm nay"

Kiểm tra getters / setters có thể là quá mức nếu bạn là một người thử nghiệm có kinh nghiệm và đây là một dự án nhỏ. Tuy nhiên, nếu bạn mới bắt đầu học cách kiểm tra đơn vị hoặc những getters / setters này có thể chứa logic (như setMom()ví dụ của @ ArtB ) thì đó là một ý tưởng tốt để viết bài kiểm tra.

Đây thực sự là một chủ đề gần đây giữa nhóm của tôi và tôi. Chúng tôi chụp cho phạm vi bảo hiểm mã 80%. Nhóm của tôi lập luận rằng getters và setters được tự động thực hiện và trình biên dịch đang tạo ra một số mã cơ bản đằng sau hậu trường. Trong trường hợp này, do mã được tạo là không xâm phạm, việc kiểm tra mã mà trình biên dịch tạo ra cho bạn không thực sự có ý nghĩa. Chúng tôi cũng đã thảo luận về các phương thức async này và trong trường hợp đó, trình biên dịch tạo ra một loạt các mã phía sau hậu trường. Đây là một trường hợp khác nhau và một cái gì đó chúng tôi LÀM thử nghiệm. Câu trả lời dài, hãy đưa nó lên với nhóm của bạn và tự quyết định xem nó có đáng để thử nghiệm không.

Ngoài ra, nếu bạn đang sử dụng báo cáo bảo hiểm mã như chúng tôi, một điều bạn có thể làm là thêm thuộc tính [ExcludeFromCodeCoverage]. Giải pháp của chúng tôi là sử dụng điều này cho các mô hình chỉ có các thuộc tính bằng cách sử dụng getters và setters hoặc trên chính thuộc tính. Bằng cách đó, nó sẽ không ảnh hưởng đến tổng độ bao phủ mã% khi báo cáo bảo hiểm mã được chạy, giả sử đó là những gì bạn đang sử dụng để tính tỷ lệ phần trăm bảo hiểm mã của bạn. Chúc bạn thử nghiệm vui vẻ!

Theo ý kiến ​​của tôi, bảo hiểm mã là một cách tốt để xem nếu bạn bỏ lỡ bất kỳ chức năng nào mà bạn nên bao gồm.

Khi bạn kiểm tra phạm vi bảo hiểm một cách thủ công bằng cách tô màu đẹp thì có thể lập luận rằng các getters và setters đơn giản không cần phải được kiểm tra (mặc dù tôi luôn làm như vậy).

Khi bạn chỉ kiểm tra tỷ lệ phần trăm bảo hiểm mã trong dự án của bạn, thì tỷ lệ phần trăm bao phủ thử nghiệm như 80% là vô nghĩa. Bạn có thể kiểm tra tất cả các phần không logic và quên một số phần quan trọng. Trong trường hợp này, chỉ 100% có nghĩa là bạn đã kiểm tra tất cả các mã quan trọng của bạn (và tất cả các mã không logic). Ngay khi nó là 99,9% bạn biết rằng đã quên một cái gì đó.

Nhân tiện: Bảo hiểm mã là kiểm tra cuối cùng để xem bạn đã kiểm tra đầy đủ (đơn vị) chưa. Nhưng phạm vi bảo hiểm mã 100% không nhất thiết có nghĩa là bạn đã thực sự kiểm tra tất cả các chức năng của lớp. Vì vậy, các bài kiểm tra đơn vị phải luôn luôn được thực hiện theo logic của lớp. Cuối cùng, bạn chạy bảo hiểm để xem nếu bạn quên bất cứ điều gì. Khi bạn làm đúng, bạn đạt 100% lần đầu tiên.

Một điều nữa: Trong khi gần đây làm việc tại một ngân hàng lớn ở Hà Lan, tôi nhận thấy Sonar chỉ ra phạm vi bảo hiểm 100% mã. Tuy nhiên, tôi biết thiếu một cái gì đó. Kiểm tra tỷ lệ bao phủ mã trên mỗi tệp, nó chỉ ra một tệp có tỷ lệ thấp hơn. Toàn bộ tỷ lệ phần trăm cơ sở mã lớn đến mức một tệp không làm cho tỷ lệ phần trăm được hiển thị là 99,9%. Vì vậy, bạn có thể muốn xem ra điều này ...

Tôi đã làm một phân tích nhỏ về phạm vi bảo hiểm đạt được trong chính mã JUnit .

Một loại mã chưa được phát hiện là "quá đơn giản để kiểm tra" . Điều này bao gồm các getters và setters đơn giản, mà các nhà phát triển của JUnit không kiểm tra.

Mặt khác, JUnit không có bất kỳ phương thức (không phản đối) nào dài hơn 3 dòng không nằm trong bất kỳ thử nghiệm nào.

Tôi sẽ nói: CÓ Lỗi trong các phương thức getter / setter có thể âm thầm lẻn vào và gây ra một số lỗi xấu.

Tôi đã viết một lib để làm cho điều này và một số thử nghiệm khác dễ dàng hơn. Điều duy nhất bạn phải viết trong các bài kiểm tra JUnit của mình là:

        assertTrue(executor.execute(Example.class, Arrays.asList( new DefensiveCopyingCheck(),
            new EmptyCollectionCheck(), new GetterIsSetterCheck(),
            new HashcodeAndEqualsCheck(), new PublicVariableCheck())));

-> https://github.com/Mixermachine/base-test

Có, đặc biệt nếu mục cần nhận là một đối tượng của một lớp được phân lớp từ một lớp trừu tượng. IDE của bạn có thể hoặc không thể cảnh báo bạn rằng một thuộc tính nào đó chưa được khởi tạo.

Và sau đó một số thử nghiệm rõ ràng không liên quan đến sự cố với một NullPointerExceptionvà bạn phải mất một thời gian để nhận ra rằng một tài sản có thể thực sự không có ở đó để có được ở vị trí đầu tiên.

Mặc dù điều đó vẫn sẽ không tệ như phát hiện ra vấn đề trong sản xuất.

Nó có thể là một ý tưởng tốt để đảm bảo tất cả các lớp trừu tượng của bạn có các hàm tạo. Nếu không, bài kiểm tra của một getter có thể cảnh báo bạn về một vấn đề ở đó.

Đối với getters và setters của người nguyên thủy, câu hỏi có thể là: Tôi đang thử nghiệm chương trình của mình hay tôi đang thử nghiệm JVM hoặc CLR? Nói chung, JVM không cần phải được kiểm tra.