Các câu trả lời khác giải thích mocking là gì. Hãy để tôi hướng dẫn bạn qua nó với các ví dụ khác nhau . Và tin tôi đi, nó thực sự đơn giản hơn nhiều so với bạn nghĩ.
tl; dr Đó là một thể hiện của lớp gốc. Nó có dữ liệu khác tiêm vào, do đó bạn tránh thử nghiệm những phần tiêm và chỉ tập trung vào kiểm tra chi tiết thực hiện các lớp học của bạn / chức năng.
Một ví dụ đơn giản:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Như bạn có thể thấy, tôi không kiểm tra LineA tức là tôi không xác thực các tham số đầu vào. Tôi không xác thực để xem nếu num1, num2 là một số nguyên. Tôi không có khẳng định chống lại điều đó.
Tôi chỉ đang thử nghiệm để xem LineB ( triển khai của tôi ) có đưa ra các giá trị bị chế giễu 1hay không và 5đang làm như tôi mong đợi.
Rõ ràng trong từ thực sự điều này có thể trở nên phức tạp hơn nhiều. Các tham số có thể là một đối tượng tùy chỉnh như Người, Địa chỉ hoặc chi tiết triển khai có thể nhiều hơn một +. Nhưng logic của thử nghiệm sẽ giống nhau.
Ví dụ không mã hóa:
Giả sử bạn đang xây dựng một máy xác định loại và tên thương hiệu của các thiết bị điện tử để bảo mật sân bay. Máy thực hiện điều này bằng cách xử lý những gì nó nhìn thấy bằng camera của nó.
Bây giờ người quản lý của bạn bước vào cửa và yêu cầu bạn kiểm tra đơn vị.
Sau đó, với tư cách là nhà phát triển, bạn có thể mang 1000 đối tượng thực, như MacBook pro, Google Nexus, chuối, iPad, v.v. ra trước nó và kiểm tra xem tất cả có hoạt động không.
Nhưng bạn cũng có thể sử dụng các đối tượng bị chế giễu , như một chiếc MacBook pro trông giống hệt (không có bộ phận bên trong thực sự) hoặc một quả chuối nhựa phía trước nó. Bạn có thể tiết kiệm cho mình từ việc đầu tư vào năm 1000 máy tính xách tay thực tế và mục nát chuối.
Vấn đề là bạn không cố gắng để kiểm tra nếu chuối là giả hay không. Cũng không kiểm tra xem laptop có giả hay không. Tất cả những gì bạn đang làm là kiểm tra xem máy của bạn một khi nó nhìn thấy một quả chuối thì nó sẽ nói not an electronic devicevà đối với MacBook Pro thì nó sẽ nói : Laptop, Apple. Đối với máy, kết quả phát hiện của nó phải giống với điện tử giả / giả và điện tử thật
Logic được đề cập ở trên cũng áp dụng cho kiểm thử đơn vị mã thực tế. Đó là một hàm nên hoạt động tương tự với các giá trị thực bạn nhận được từ đầu vào thực (và tương tác) hoặc bị chế giễugiá trị bạn tiêm trong đơn vị thử nghiệm. Và cũng giống như cách bạn tự cứu mình khỏi việc sử dụng chuối hoặc MacBook thực sự, với các bài kiểm tra đơn vị (và chế giễu), bạn tự cứu mình khỏi phải làm điều gì đó khiến máy chủ của bạn trả lại mã trạng thái 500, 403, 200, v.v. Máy chủ của bạn để kích hoạt 500 chỉ khi máy chủ ngừng hoạt động, trong khi 200 là khi máy chủ hoạt động. Thật khó để chạy 100 bài kiểm tra tập trung vào mạng nếu bạn phải liên tục chờ 10 giây giữa chuyển đổi lên và xuống máy chủ). Vì vậy, thay vào đó bạn tiêm / giả một phản hồi với mã trạng thái 500, 200, 403, v.v. và kiểm tra đơn vị / chức năng của bạn với giá trị được tiêm / giả.
Mã hóa Ví dụ:
Giả sử bạn đang viết một ứng dụng iOS và có các cuộc gọi mạng. Công việc của bạn là kiểm tra ứng dụng của bạn . Để kiểm tra / xác định xem các cuộc gọi mạng có hoạt động như mong đợi KHÔNG PHẢI LÀ TRÁCH NHIỆM CỦA BẠN. Trách nhiệm của một bên khác (nhóm máy chủ) là kiểm tra nó. Bạn phải loại bỏ sự phụ thuộc (mạng) này và tiếp tục kiểm tra tất cả mã của bạn hoạt động xung quanh nó.
Một cuộc gọi mạng có thể trả về các mã trạng thái khác nhau 404, 500, 200, 303, v.v với phản hồi JSON.
Ứng dụng của bạn được cho là hoạt động cho tất cả chúng (trong trường hợp có lỗi, ứng dụng của bạn sẽ ném lỗi dự kiến). Những gì bạn làm với chế độ chế giễu là bạn tạo ra 'tưởng tượng' tương tự như các phản hồi mạng thực '(như mã 200 với tệp JSON) và kiểm tra mã của bạn mà không ' thực hiện cuộc gọi mạng thực và chờ phản hồi mạng của bạn '. Bạn mã hóa thủ công / trả lại phản hồi mạng cho TẤT CẢ các loại phản hồi mạng và xem ứng dụng của bạn có hoạt động như bạn mong đợi không. (bạn không bao giờ giả định / kiểm tra 200 với dữ liệu không chính xác, vì đó không phải là trách nhiệm của bạn, trách nhiệm của bạn là kiểm tra ứng dụng của bạn với 200 chính xác hoặc trong trường hợp 400, 500, bạn kiểm tra xem ứng dụng của bạn có đưa ra lỗi đúng không)
Điều này tạo ra trí tưởng tượng tương tự như thực tế được gọi là chế nhạo.
Để thực hiện việc này, bạn không thể sử dụng mã gốc của mình (mã gốc của bạn không có phản hồi được chèn sẵn, phải không?). Bạn phải thêm một cái gì đó vào nó, tiêm / chèn dữ liệu giả đó thường không cần thiết (hoặc một phần của lớp học của bạn).
Vì vậy, bạn tạo một thể hiện của lớp gốc và thêm bất cứ thứ gì (ở đây là HTTPResponse mạng, dữ liệu HOẶC trong trường hợp không thành công, bạn chuyển đúng errorString, HTTPResponse) bạn cần đến nó và sau đó kiểm tra lớp bị giả .
Câu chuyện dài, chế giễu là để đơn giản hóa và giới hạn những gì bạn đang kiểm tra và cũng khiến bạn nuôi những gì một lớp học phụ thuộc vào. Trong ví dụ này, bạn tránh kiểm tra các cuộc gọi mạng mình , và thay vào đó kiểm tra hay không ứng dụng của bạn hoạt động như bạn mong đợi với những kết quả tiêm / phản ứng - do chế giễu lớp
Không cần phải nói, bạn kiểm tra từng phản ứng mạng riêng biệt.
Bây giờ một câu hỏi mà tôi luôn có trong đầu là: Các hợp đồng / điểm kết thúc và về cơ bản là phản hồi JSON của các API của tôi được cập nhật liên tục. Làm thế nào tôi có thể viết bài kiểm tra đơn vị mà xem xét điều này?
Để giải thích rõ hơn về điều này: giả sử mô hình yêu cầu khóa / trường có tên username. Bạn kiểm tra điều này và bài kiểm tra của bạn vượt qua. 2 tuần sau, phụ trợ thay đổi tên của khóa thành id. Bài kiểm tra của bạn vẫn vượt qua. đúng? hay không?
Có phải là trách nhiệm của nhà phát triển phụ trợ để cập nhật các bản giả. Có nên là một phần trong thỏa thuận của chúng tôi rằng họ cung cấp các bản giả được cập nhật?
Câu trả lời cho vấn đề trên là: kiểm tra đơn vị + quy trình phát triển của bạn với tư cách là nhà phát triển phía khách hàng sẽ / sẽ bắt được phản hồi giả định lỗi thời. Nếu bạn hỏi tôi như thế nào? câu trả lời là:
Ứng dụng thực tế của chúng tôi sẽ thất bại (hoặc không thất bại nhưng không có hành vi mong muốn) nếu không sử dụng API cập nhật ... do đó nếu thất bại ... chúng tôi sẽ thay đổi mã phát triển của mình. Điều này một lần nữa dẫn đến các thử nghiệm của chúng tôi thất bại .... mà chúng tôi sẽ phải sửa nó. (Trên thực tế nếu chúng ta thực hiện đúng quy trình TDD, chúng ta sẽ không viết bất kỳ mã nào về trường trừ khi chúng ta viết thử nghiệm cho nó ... và thấy nó thất bại và sau đó đi và viết mã phát triển thực tế cho nó.)
Tất cả điều này có nghĩa là phụ trợ không cần phải nói: đó là chúng tôi đã cập nhật các bản nháp ... cuối cùng nó cũng xảy ra thông qua việc phát triển / gỡ lỗi mã của bạn. Bởi vì đó là một phần của quá trình phát triển! Mặc dù nếu phụ trợ cung cấp phản hồi giả cho bạn thì điều đó dễ dàng hơn.
Toàn bộ quan điểm của tôi về vấn đề này là (nếu bạn không thể tự động nhận được cập nhật phản ứng API chế giễu rồi) một số tương tác của con người là cần thiết tức là tay bản cập nhật của JSONs và có cuộc họp ngắn để đảm bảo giá trị của họ được cập nhật sẽ trở thành một phần của quá trình của bạn
Phần này được viết nhờ vào một cuộc thảo luận chậm chạp trong nhóm gặp gỡ của chúng tôi
Chỉ dành cho nhà phát triển iOS:
Một ví dụ rất hay về chế giễu là bài nói chuyện theo định hướng Giao thức thực tế này của Natasha Muraschev . Chỉ cần bỏ qua đến phút 18:30, mặc dù các slide có thể không đồng bộ với video thực tế
Tôi thực sự thích phần này từ bảng điểm:
Bởi vì đây là thử nghiệm ... chúng tôi muốn đảm bảo rằng getchức năng từ Gettableđược gọi, bởi vì nó có thể trở lại và về mặt lý thuyết chức năng có thể gán một mảng các mặt hàng thực phẩm từ bất cứ đâu . Chúng ta cần đảm bảo rằng nó được gọi;