2010-05-04 30 views
9

Chúng tôi sử dụng các văn bản viết tay trong các bài kiểm tra đơn vị của chúng tôi và tôi đang tìm hiểu nhu cầu về khung Mock như EasyMock hoặc Mockito trong dự án của chúng tôi.Tại sao chúng ta cần khung mocking như Easymock, JMock hoặc Mockito?

Tôi không tìm thấy lý do thuyết phục để chuyển sang Mocking frameworks from hand viết tay.

Bất cứ ai có thể vui lòng trả lời lý do tại sao người ta chọn tham gia khung mocking khi họ đã thực hiện các bài kiểm tra đơn vị bằng cách sử dụng mock/stubs viết tay.

Cảm ơn

+0

Ngoài ra, hãy xem http://stackoverflow.com/questions/1717107/why-do-we-need-mocking-frameworks – Finglas

Trả lời

2

Tôi bắt đầu theo cách tương tự (viết mocks bằng tay) và bây giờ tôi đã gần như hoàn toàn chuyển sang EasyMock.

Tôi thấy rằng việc sử dụng EasyMock thường nhanh hơn và linh hoạt hơn.

Thông thường lần đầu tiên tôi cần một mô hình, tôi có thể có nó trong một vài dòng mã với EasyMock, trong khi bằng tay tôi cần triển khai giao diện cần thiết (đủ công bằng, điều này có thể được tạo ra bởi một IDE như IntelliJ) và sau đó thêm mã cần thiết để tạo ra phản hồi cần thiết và/hoặc để cho phép cảm nhận ảnh hưởng của các cuộc gọi đến nó.

Tốt, có thể nói, đó chỉ là chi phí một lần. Lần sau tôi có thể tái sử dụng tay viết một cách vui vẻ ... Tôi thấy đó không phải là trường hợp. Trong một thử nghiệm khác, tôi có thể cần một mô hình của cùng một lớp với hành vi khác nhau. Ví dụ. các phương thức khác nhau được gọi, và/hoặc kết quả khác nhau được mong đợi. Một trường hợp cụ thể là khi giả định được ném một ngoại lệ trong một trường hợp thử nghiệm, nhưng không phải trong trường hợp khác. Tốt, tôi có thể thêm một số tham số vào nó để điều khiển hành vi động. Sau đó, đối với bài kiểm tra tiếp theo, một số thông số khác để kiểm soát nhiều hành vi hơn ... vì vậy tôi kết thúc với việc thực thi mô hình phức tạp hơn, đó là sự phụ thuộc cho các bài kiểm tra đơn vị nhiều hơn - đặt ra cũng có nguy cơ vô tình làm hỏng các thử nghiệm cũ hơn.

Trái ngược với điều này, với EasyMock tôi có thể định cấu hình mocks của mình một cách độc lập cho mỗi thử nghiệm. Do đó, hành vi được kiểm soát rõ ràng và hiển thị trong chính mã kiểm thử đơn vị, và không có nguy cơ tác dụng phụ.

Chưa kể rằng với EasyMock bạn có thể xác minh rằng các phương thức được yêu cầu được gọi theo thứ tự bắt buộc, nếu bạn cần (và tôi thực hiện, mọi lúc và sau đó). Thực hiện điều này bằng tay (đặc biệt là trong một thời trang chung chung) sẽ là khá đau ở cổ, không có lợi ích bổ sung.

1

Đôi khi có thể dễ dàng tạo các mocks theo cách khai báo và nó có thể giúp bạn viết một số loại hành vi dễ dàng hơn bằng cách sử dụng khung công tác hơn là bằng tay. Một lợi thế nhỏ khác cũng có thể là bằng cách sử dụng khung mocking, bạn đang rõ ràng về chế nhạo.

2

Giống như mọi nhà phát triển khác, tôi thấy mình viết mã thay vì sử dụng giải pháp hiện có - hội chứng "không được phát minh ở đây".

Câu hỏi của bạn cho thấy bạn thích viết các lớp bạn cần giả/giả hai lần thay vì sử dụng khung làm việc đó cho bạn. Sử dụng một khuôn khổ mocking giải phóng bạn khỏi việc cần phải viết, refactor và cập nhật bàn tay của bạn cán mocks bất cứ khi nào bạn thay đổi các đối tượng giả.

Nói cách khác bằng cách sử dụng khung làm giả giống như bất kỳ thư viện nào khác của bên thứ ba, ví dụ: ORM - người khác đã viết mã để bạn không phải làm như vậy.

9

Bạn có thể muốn đọc bài viết Mocks Aren't Stubs của Martin Fowler.Sự khác biệt cơ bản là thế này:

  • công việc của một cuống là để trả về kết quả được biết đến với tất cả các cuộc gọi
  • Một giả thêm hy vọng các cuộc gọi đến theo một thứ tự cụ thể, với các thông số cụ thể, và sẽ ném một ngoại lệ khi những kỳ vọng không được đáp ứng.

Có một số điều kiện lỗi không thể kiểm tra được bằng cuống. Mặt khác, các thử nghiệm sử dụng mocks thường ít ổn định hơn nhiều.

Trong khi khai có thể được viết thủ công với nỗ lực hợp lý, Mocks sẽ yêu cầu công việc nhiều hơn nữa. Và một khuôn khổ mocking tốt có thể làm cho việc viết sơ khai nhanh hơn và dễ dàng hơn.

+0

Điểm nhỏ, bài viết của Martin hiện đang hơi cũ và bỏ lỡ một số điểm quan trọng. Trước tiên, tôi không nghĩ rằng bất kỳ khung công tác hiện tại nào thực thi thứ tự yêu cầu trừ khi bạn yêu cầu nó.Thứ hai, nếu các bài kiểm tra của bạn không ổn định, đó là phản hồi hữu ích sẽ giúp bạn có một cái nhìn khác về thiết kế của bạn. –

13

Câu trả lời đơn giản là chúng tôi không cần đến chúng.

Chúng tôi cũng không cần các khung công tác hiện có khác, nhưng việc sử dụng khung Mocking giúp cuộc sống của chúng tôi dễ dàng hơn. Là nhà phát triển, chúng tôi có thể dành nhiều thời gian hơn cho vấn đề này, thay vì tạo hoặc thực hiện những gì mà các khuôn khổ mocking có thể làm.

"tôi không tìm thấy một lý do thuyết phục cho chuyển sang khung Mocking từ viết tay cuống."

Tôi hoàn toàn giống nhau. Tại sao tôi nên bận tâm học một khuôn khổ mocking? Viết tay bằng văn bản làm tốt.

Một vài điểm cần lưu ý, chủ yếu là thực tế sau một thời gian các bài kiểm tra của bạn trở nên tối nghĩa với các bài kiểm tra. Những gì bạn đang đề cập đến khi sử dụng cuống viết tay được gọi là phần mở rộng thử nghiệm. Bạn mở rộng mã để kích hoạt những gì mocking frameworks làm. Nói cách khác, bạn viết mã để khai báo, hoặc trả về các giá trị tùy thuộc vào những gì xảy ra. Điều này cần có thời gian và công sức. Chưa kể đến không gian. Một khuôn khổ mocking có thể làm tất cả điều này trong một vấn đề của dòng.

Những lợi ích của một khuôn khổ mocking là:

  • dễ dàng hơn (chủ quan, nhưng sau một thời gian bạn sẽ không viết tay bằng văn bản triển khai)
  • Ít Mã (khuôn khổ cho phép bạn tạo ra một mô hình trong một số dòng, chứ không phải là khai báo lớp học đầy đủ)
  • Theo dõi DRY (bạn sẽ không kết thúc lặp lại triển khai mô hình)

Lợi ích lớn nhất đến khi bạn yêu cầu đối tượng giả. Phải viết tay để kiểm tra xem một phương pháp có được gọi hay không, bao nhiêu lần và vân vân là một nhiệm vụ nhỏ trong chính nó. Nếu ai đó đã làm như vậy, và tạo ra một khuôn khổ được kiểm tra kỹ lưỡng, được làm tài liệu tốt, sẽ không có ý nghĩa nếu không sử dụng nó. Cũng giống như bất kỳ khung công tác nào, bạn có thể đi tốt mà không có nó, nhưng đôi khi sử dụng đúng công cụ làm cho công việc trở nên dễ dàng hơn nhiều.

+1

Như đã đề cập, nó đáng để kiểm tra * "Mocks không stubs" * bài viết. Mocking framework cho phép mocking, stubbing và faking. Nói cách khác, chúng rất linh hoạt. – Finglas

Các vấn đề liên quan