Thực hành tốt nhất cho các bài kiểm tra đơn vị trong Magento 1.9

Tôi duy trì một trang web Magento 1.9 với một số mô-đun tùy chỉnh. Một số chức năng là kinh doanh quan trọng và rất cần một số bài kiểm tra đơn vị. Ví dụ, một máy tính đơn giá.

Tôi thường phát triển trong Symfony và thực sự muốn sử dụng PHPUnit (w / Composer) bằng cách nào đó nếu có thể.

Một số chức năng dựa trên dữ liệu được nhập vào một số bảng cơ sở dữ liệu tùy chỉnh, vì vậy tôi muốn tải đồ đạc bằng cách nào đó.

Vì vậy, tôi đang tìm cách tiếp cận thực tiễn tốt nhất để viết một số bài kiểm tra đơn vị. Tôi sẽ chấp nhận hướng dẫn hoặc một cái gì đó tương tự. Bất kỳ trợ giúp được đánh giá cao.

Tôi đã đối mặt với cùng một vấn đề một thời gian trở lại.

Tôi đã cân nhắc sử dụng mô-đun Ecomdev PHPUnit nhưng tôi thấy nó khó sử dụng và tài liệu kém (nhưng tôi vẫn thích những gì Ivan làm và đóng góp to lớn của anh ấy cho hệ sinh thái Magento).

Vì vậy, với sự giúp đỡ của Vinai, cuối cùng tôi đã phát triển mô-đun khung thử nghiệm sau: https://github.com/digitalpianism/testframework

Mục đích ban đầu là để kiểm tra tích hợp nhưng tôi cũng đang sử dụng nó cho các bài kiểm tra đơn vị. Bạn có thể thấy nó hoạt động ở đây: https://github.com/digitalpianism/easytoplinks/blob/master/app/code/community/DigitalPianism/PalToplinks/Test/Unit/Block/Page/Template/LinksTest.php

Về đồ đạc, tôi đang sử dụng các giao dịch rollback để tránh tạo dữ liệu mẫu trong cơ sở dữ liệu.

Cài đặt

Vì Magento 1 không sử dụng trình soạn thảo ngoài hộp, tôi không nghĩ nó sẽ tạo ra sự khác biệt lớn nếu bạn cài đặt phpunit bằng trình soạn thảo hoặc chỉ tải xuống phiên bản phar .
Nếu bạn đã sử dụng trình soạn thảo để quản lý các mô-đun hoặc thư viện của bên thứ ba khác trong trang web của mình, thì trình soạn thảo có thể có ý nghĩa nhất. Trừ khi bạn sử dụng PHP7, bạn sẽ bị giới hạn ở phiên bản cũ của phpunit (đó là lý do tại sao tôi liên kết với phiên bản 4.8 ở trên).

Kiểm tra tích hợp so với / và / hoặc Kiểm tra đơn vị

Vì Magento 1 là một ứng dụng nặng như vậy, nên tách bootstrap của phpunit thành một để tích hợp và một cho các bài kiểm tra đơn vị.
Bootstrap thử nghiệm đơn vị chỉ cần khởi tạo trình tải tự động, trong khi bootstrap thử nghiệm tích hợp cần khởi tạo toàn bộ môi trường ứng dụng bao gồm tải cấu hình và kết nối db.
Do đó, các thử nghiệm tích hợp trong Magento có xu hướng chạy chậm hơn rất nhiều so với các thử nghiệm đơn vị (thậm chí nhiều hơn trong các ứng dụng khác).

Bootstrapping Magento vào phpunit

• Trình tải tự động của Magento không tuân thủ PSR-0 vì nó ném ra một ngoại lệ nếu nó không thể tìm thấy tệp mà một lớp được đặt. Điều này phá vỡ một số cách sử dụng class_existstrong phpunit. Có một số cách giải quyết có thể (nếu hacky):

  • Hủy đăng ký trình tải tự động Magento, gói \Varien_Autoload::autoload()trong một trình trang trí bỏ qua các ngoại lệ được ném vào bên trong và đăng ký trình bao bọc như một trình tải tự động mới. Điều này có khả năng xung đột thấp với các thư viện bên thứ ba đăng ký trình tải tự động và phụ thuộc vào một đơn đặt hàng tự động tải cụ thể.
  • Sử dụng trình xử lý lỗi tùy chỉnh gói một trình xử lý được tích hợp vào Magento 1. Trình xử lý lỗi tùy chỉnh nuốt lỗi được kích hoạt bởi trình tải tự động Magento. Đây là giải pháp mà khung thử nghiệm của Raphael sử dụng . Điều này có vẻ tương thích nhất với các tiện ích mở rộng của bên thứ ba khác.
  • Sử dụng hack đường dẫn bao gồm để ghi đè \Varien_Autoload::autoload()để không ném lỗi nếu tệp không tồn tại. Tuy nhiên, điều này mâu thuẫn với một số mô-đun cũng ghi đè cùng một lớp. Tôi không sử dụng phương pháp này bản thân mình.

• Để tránh lỗi từ phiên được bắt đầu trong khi kiểm tra, chỉ cần đặt $_SESSON = []trong bootstrap.

• Đặt một đối tượng phản hồi tùy chỉnh thông qua Mage::app()->setResponse($testResponse)đó mở rộng đối tượng thực nhưng không gửi đầu ra hoặc tiêu đề.

• Để xác định lại Magento giữa các kiểm tra tích hợp thay đổi hoàn toàn trạng thái thời gian chạy, hãy sử dụng Mage::reset(); Mage::app(). Lưu ý rằng sau đó bộ xử lý lỗi sẽ phải được trang trí lại.

Đồ đạc

Đối với đồ đạc DB tôi có xu hướng sử dụng các mô hình thông thường trong các phương pháp cố định để tạo đồ đạc, ví dụ createSimpleProduct($sku). Giống như Raphael đã nói, sử dụng setUp()và tearDown()để bọc thử nghiệm trong một giao dịch được khôi phục sau khi thử nghiệm (ví dụ Mage::getSingleton('core/resource')->getConnection('default_setup')->beginTransaction()).

Đối với đồ đạc cấu hình cửa hàng, tôi có xu hướng thiết lập đồ đạc chỉ trong bộ nhớ bằng cách sử dụng Mage::app()->getStore()->setConfig($path, $value).

Phần EcomDev_PHPUnitmở rộng cũng cung cấp tùy chọn để tạo các đồ đạc DB bằng các tệp yaml, nhưng với bản thân tôi, tôi thấy chúng khó bảo trì hơn so với các đồ đạc được tạo bằng các lớp mô hình. YMMV.

Kiểm tra đôi

Việc đăng ký có thể được sử dụng để tiêm đôi kiểm tra cho các đối tượng được tạo ra thông qua Mage::getSingleton(), Mage::getResourceSingleton()và Mage::helper().
Một số đối tượng trung tâm khác có thể được đặt trên Mage::app()(ví dụ: yêu cầu).
Để thay thế các lớp được tạo thông qua Mage::getModel()hoặc Mage::getResourceModel()bằng các phép thử nhân đôi, một trình bao bọc đối tượng cấu hình tùy chỉnh phải được sử dụng. Xem ví dụ này trong khung thử nghiệm của Raphael làm thế nào điều đó có thể được thực hiện.

Tóm lược

Khi Magento được bootstrapping, khá nhiều thứ có thể được kiểm tra khá độc đáo. Hãy chuẩn bị để tạo ra các bản giả sâu vì số lượng lớn phương thức xâu chuỗi mã lõi sử dụng mặc dù.
Mặc dù thiết lập là hacky, nó hoạt động tốt và tôi thấy các bài kiểm tra mang lại cho tôi rất nhiều sự tự tin và giá trị, khá nhiều so sánh với một bộ thử nghiệm cho ứng dụng Symphony.