Tôi đã kiểm tra lớp học của mình, bây giờ làm thế nào để tôi bắt đầu với một bài kiểm tra tích hợp?


19

Tôi đã viết một lớp quản lý người nhận trong danh sách MailChimp, được gọi là MailChimpRecipient. Nó sử dụng lớp MCAPI, là trình bao bọc API của bên thứ ba.

http://apidocs.mailchimp.com/api/1.3/ http://apidocs.mailchimp.com/api/doads/

Tôi chuyển đối tượng MCAPI vào hàm tạo của đối tượng MailChimpRecipient, vì vậy tôi đã viết các bài kiểm tra đơn vị bằng PHPUnit để kiểm tra tất cả logic trong lớp của riêng tôi (Tôi không kiểm tra lớp MCAPI). Tôi có bảo hiểm mã 100% và tất cả các bài kiểm tra vượt qua. Điều này được thực hiện bằng cách chế nhạo và khai thác đối tượng MCAPI.

Bước tiếp theo của tôi là viết một bài kiểm tra tích hợp, cũng sử dụng PHPUnit, nơi tôi sẽ xây dựng lịch thi đấu MailChimpRecipient bằng một đối tượng MCAPI thực, được thiết lập để sử dụng danh sách MailChimp thực.

Tôi đã viết những gì tôi nghĩ là một bài kiểm tra tích hợp, về cơ bản chạy các bài kiểm tra lại giao diện công khai của đối tượng, như:

public function testAddedRecipientCanBeFound()
{
    $emailAddress = 'fred@fredsdomain.com';
    $forename = 'Fred';
    $surname = 'Smith';

    // First, delete the email address if it is already on the list
    $oldRecipient = $this->createRecipient();
    if($oldRecipient->find($emailAddress))
    {
        $oldRecipient->delete();
    }
    unset($oldRecipient);

    // Add the recipient using the test data
    $newRecipient = $this->createRecipient();
    $newRecipient->setForename($forename);
    $newRecipient->setSurname($surname);
    $newRecipient->setEmailAddress($emailAddress);
    $newRecipient->add();
    unset($newRecipient);

    // Assert that the recipient can be found using the same email address
    $this->assertTrue($this->_recipient->find($emailAddress));
}

Bài kiểm tra "tích hợp" không kiểm tra bất kỳ phần bên trong nào của lớp - nó chỉ đảm bảo rằng được cung cấp một đối tượng MCAPI thực sự, nó hoạt động như quảng cáo.

Điều này có đúng không? Đây có phải là cách tốt nhất để chạy thử nghiệm xen kẽ? Rốt cuộc, các phần bên trong đã được kiểm tra với một bài kiểm tra đơn vị. Tôi có đúng không khi nghĩ rằng bài kiểm tra tích hợp có để kiểm tra xem nó có thực sự hoạt động không, theo cách quảng cáo của nó?

Để tiến thêm một bước, lớp MailChimpRecipient thực hiện một giao diện, cũng sẽ được các lớp khác triển khai. Ý tưởng là sử dụng một nhà máy để chuyển các loại đối tượng người nhận danh sách gửi thư khác nhau sang mã của tôi, tất cả đều làm điều tương tự, mặc dù sử dụng các nhà cung cấp danh sách gửi thư khác nhau. Vì các kiểm tra tích hợp của tôi kiểm tra giao diện đó, làm thế nào về việc sử dụng nó cho tất cả các lớp thực hiện giao diện? Sau đó, trong tương lai, nếu tôi thiết kế một lớp mới sẽ được sử dụng thay thế cho nhau, tôi có thể chạy thử nghiệm tích hợp tương tự trước khi chèn nó vào một dự án.

Điều này nghe có vẻ hợp lý? Các bài kiểm tra đơn vị kiểm tra các phần bên trong của một đối tượng, các bài kiểm tra tích hợp có đảm bảo rằng nó hoạt động như quảng cáo?


4
Tôi nghĩ rằng bạn có quá nhiều logic trong bài kiểm tra của bạn. Bạn chạy rất nhiều mã cho đến khi bạn xác nhận. Bạn có thể muốn kiểm tra việc xóa một người nhận đầu tiên. Nhưng đó không phải là trả lời câu hỏi của bạn, chỉ là một nhận xét.
hakre

1
Vâng, bạn nên sử dụng setUpchức năng để thiết lập các căn cứ để chạy thử nghiệm của bạn. Nếu đầu vào không được xác định, bạn thực sự không thể kiểm tra. Đầu vào cần phải chính xác, nghiêm ngặt và luôn luôn giống nhau. Nếu điều kiện tiên quyết của một bài kiểm tra không được đáp ứng, thay vào đó hãy bỏ qua bài kiểm tra. Sau đó phân tích lý do tại sao nó bỏ qua và nếu bạn cần thêm các bài kiểm tra bổ sung và / hoặc setUpkhông được thực hiện đúng.
hakre

1
Cũng không nên thử các giá trị kiểm tra mã hóa cứng trong một bài kiểm tra của riêng nó mà hãy tạo các thành viên lớp đó để chúng có thể được chia sẻ qua các bài kiểm tra (và thay đổi ở vị trí trung tâm) hoặc sử dụng DataProvider(đó là một hàm cung cấp đầu vào làm tham số cho bài kiểm tra).
hakre

1
Nhập vào theo nghĩa của tất cả mọi thứ mà chức năng kiểm tra của bạn hoạt động. Khi bạn kiểm tra thêm người nhận và bạn muốn đảm bảo rằng nó chưa tồn tại, ít nhất bạn nên xác nhận việc xóa trong trường hợp nó bắt đầu. Nếu không, điều kiện tiên quyết của bài kiểm tra của bạn không được đảm bảo để có thể kiểm tra được.
hakre

1
+1 cho câu hỏi hay, nhưng cũng được bình chọn để chuyển sang Lập trình viên. Có vẻ như đó là nơi các câu hỏi về chiến lược thử nghiệm thuộc về
GordonM

Câu trả lời:


17

Khi kiểm tra mã của bạn, bạn nên chú ý đến ba lĩnh vực:

  • Thử nghiệm kịch bản
  • Thử nghiệm chức năng
  • Kiểm tra đơn vị

Thông thường, số lượng thử nghiệm bạn có trong mỗi danh mục sẽ có hình dạng của một kim tự tháp, nghĩa là rất nhiều thử nghiệm đơn vị ở phía dưới, một số thử nghiệm chức năng ở giữa và chỉ một vài thử nghiệm kịch bản.

Với một bài kiểm tra đơn vị, bạn mô phỏng mọi thứ mà lớp đang kiểm tra sử dụng và bạn kiểm tra nó trong sự cô lập thuần túy (đây là lý do tại sao điều quan trọng là phải đảm bảo rằng trong lớp bạn lấy được tất cả các lần tiêm phụ thuộc để chúng có thể được thay thế trong bài kiểm tra).

Với kiểm tra đơn vị, bạn kiểm tra tất cả các khả năng, do đó, không chỉ "đường dẫn hạnh phúc" mà còn tất cả các điều kiện lỗi.

Nếu bạn hoàn toàn chắc chắn rằng tất cả các đơn vị của bạn hoạt động độc lập, bạn hãy viết một vài bài kiểm tra (kiểm tra chức năng) để đảm bảo các đơn vị cũng hoạt động khi kết hợp. Sau đó, bạn viết một bài kiểm tra kịch bản, trong đó kiểm tra hệ thống dây điện giữa tất cả các mô-đun chức năng.

Ví dụ: giả sử bạn đang thử xe.

Bạn có thể lắp ráp toàn bộ chiếc xe và như một tài xế kiểm tra mọi điều kiện có thể nhưng điều đó sẽ thực sự khó thực hiện.

Thay vào đó, bạn sẽ kiểm tra một phần nhỏ của động cơ với tất cả các khả năng (kiểm tra đơn vị)

Sau đó, bạn kiểm tra toàn bộ động cơ (tách biệt với xe) sẽ là một bài kiểm tra chức năng.

Như một bài kiểm tra cuối cùng, bạn đặt chìa khóa của bạn vào, khởi động xe và lái nó đến bãi đậu xe. Nếu điều đó hoạt động thì bạn biết rằng tất cả các bộ phận (pin, nhiên liệu, động cơ, ..) đều được kết nối và vì bạn đã kiểm tra chúng cách ly, bạn có thể chắc chắn rằng toàn bộ chiếc xe đang hoạt động chính xác.

Vì vậy, trong trường hợp của bạn, bạn đã kiểm tra tất cả các điều kiện lỗi và đường dẫn hạnh phúc trong kiểm tra đơn vị của mình và biết rằng bạn chỉ phải kiểm tra từ đầu đến cuối với 'các thành phần thực' để kiểm tra xem hệ thống dây có đúng không.

Một vài điểm khác,

  • Tránh logic có điều kiện trong bài kiểm tra đơn vị của bạn. Nếu bạn phải dọn dẹp, việc bạn sử dụng một số loại trạng thái toàn cầu và các bài kiểm tra có thể đột nhiên ảnh hưởng lẫn nhau.
  • Không chỉ định bất kỳ dữ liệu nào không liên quan đến thử nghiệm. Nếu tôi thay đổi tên, hoặc họ, thử nghiệm sẽ thất bại? Có lẽ không phải vì đó là địa chỉ email quan trọng mà vì bạn đề cập rõ ràng đến nó trong bài kiểm tra của bạn, tôi không thể chắc chắn. Hãy thử nhìn vào Mẫu xây dựng để xây dựng dữ liệu thử nghiệm của bạn và làm cho nó rõ ràng những gì thực sự quan trọng.

Cảm ơn, điều đó xác nhận rất nhiều những gì tôi nghĩ. Chỉ cần làm rõ - đây KHÔNG phải là một bài kiểm tra đơn vị. Tôi đã viết một bài kiểm tra đơn vị, trong đó kiểm tra đối tượng hoàn toàn cô lập và có phạm vi bao phủ 100% mã của đối tượng. Đây có nghĩa là một thử nghiệm tích hợp, để đảm bảo nó hoạt động khi tôi tiêm một đối tượng MCAPI thực sự vào nó. Tôi chỉ cần xóa bất kỳ người nhận nào được thêm vào danh sách - đó là tất cả các hoạt động dọn dẹp, và nó được thực hiện để đảm bảo rằng không có thử nghiệm nào ảnh hưởng đến nhau. Bạn sẽ đề nghị gì thay thế?

1
Vâng! Tôi hiểu bạn đã làm các bài kiểm tra đơn vị. Đối tượng MCAPI có theo dõi người nhận không và đó có phải là công việc dọn dẹp mà bạn phải làm không? Nếu đó là vấn đề của bên thứ ba, thì bạn không thể làm gì trong bài kiểm tra tích hợp. Nếu bạn theo dõi danh sách khác, bạn nên đảm bảo rằng bạn đang tránh dữ liệu toàn cầu (và singletons) để đảm bảo các xét nghiệm không ảnh hưởng lẫn nhau. Trong một thế giới hoàn hảo, dọn dẹp mọi thứ khi thử nghiệm bắt đầu / kết thúc, chỉ ra một lỗ hổng thiết kế nhưng trong thế giới thực, bạn không thể luôn luôn tránh nó.
Wouter de Kort

1
Tôi sẽ thêm rằng kiểm tra kịch bản có lẽ không thực sự là một cái gì đó mà PHPUnit phù hợp. Yu có thể muốn xem xét một số công cụ bạn có thể chạy trong trình duyệt như Selenium hoặc công cụ có thể mô phỏng trình duyệt, như jMeter.
GordonM

Cảm ơn các bạn! Chắc chắn có rất nhiều điều để học khi viết mã kiểm tra tốt, không có ở đó. Tôi đã đặt cho mình một bản sao của cuốn sách này: amazon.co.uk/ . Hy vọng rằng, những gì bạn đã nói sẽ có ý nghĩa hơn một chút sau khi tôi đọc nó. @Wouter, tôi chỉ xóa một người nhận vì thử nghiệm sẽ khiến địa chỉ email được thêm vào danh sách. Tôi đang xóa nó để danh sách không bị ảnh hưởng bởi bài kiểm tra đó.

1
@LewisBassett Tôi không phải là nhà phát triển Php nhưng các mẫu Kiểm tra xUnit ( amazon.com/xUnit-Test-Potypes-Refactoring-Code/dp/0131495054 ) chắc chắn là một sản phẩm đáng đọc. Ngoài ra các bài viết tại misko.hevery.com/code-reviewers-guide thực sự thú vị.
Wouter de Kort
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.