Mô hình nguồn thử nghiệm đơn vị

Tôi có một số mô hình trong tiện ích mở rộng tùy chỉnh của mình chỉ phục vụ mục đích điền vào một số lựa chọn và / hoặc đa lựa chọn trong biểu mẫu thêm / chỉnh sửa các thực thể của tôi.
Vì vậy, chúng là những gì magento gọi là "mô hình nguồn".
Các giá trị liên quan luôn giống nhau và các phương thức trả về cùng một thứ.
Làm thế nào tôi nên kiểm tra đơn vị? Hoặc thậm chí tốt hơn, tôi nên viết bài kiểm tra đơn vị cho họ?
Đây là một ví dụ.
Lớp sau đây được sử dụng cho biểu mẫu thêm / chỉnh sửa cho một trường được gọi typevà cho cột lưới của cùng một trường.

<?php
namespace Sample\News\Model\Author\Source;

use Magento\Framework\Option\ArrayInterface;

class Type implements ArrayInterface
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;

    /**
     * Get options
     *
     * @return array
     */
    public function toOptionArray()
    {
        $_options = [
            [
                'value' => '',
                'label' => ''
            ],
            [
                'value' => self::COLLABORATOR,
                'label' => __('Collaborator')
            ],
            [
                'value' => self::EMPLOYEE,
                'label' => __('Employee')
            ],
        ];
        return $_options;
    }

    /**
     * get options as key value pair
     *
     * @return array
     */
    public function getOptions()
    {
        $_tmpOptions = $this->toOptionArray();
        $_options = [];
        foreach ($_tmpOptions as $option) {
            $_options[$option['value']] = $option['label'];
        }
        return $_options;
    }
}

Đây là một chủ đề tuyệt vời và tôi thực sự thích cả Câu trả lời từ @KAndy và @fschmengler.
Tôi muốn thêm một số suy nghĩ bổ sung mà tôi thấy có giá trị khi đặt câu hỏi như "Tôi có nên kiểm tra X không?" hoặc "Tôi nên kiểm tra X như thế nào?".

Điều gì có thể đi sai?

• Tôi có thể tạo ra một lỗi đánh máy ngu ngốc (xảy ra mọi lúc)
  Điều này thường không biện minh cho việc viết một bài kiểm tra.
• Tôi sẽ sao chép mã tôi cần từ lõi hoặc một mô-đun khác, và sau đó điều chỉnh mã theo nhu cầu của tôi?
  Tôi thấy đây thực sự là một điều rất nguy hiểm để làm mà thường để lại những lỗi tinh vi. Trong trường hợp này, tôi thích viết một bài kiểm tra, nếu nó không quá đắt. Việc cấu hình mô hình nguồn dựa trên thực tế sẽ khiến IMO rủi ro hơn.
• Có thể có một cuộc xung đột với một mô-đun khác nhau?
  Điều này hầu như chỉ áp dụng cho mã cấu hình. Trong trường hợp như vậy tôi muốn có một bài kiểm tra tích hợp cho tôi biết khi nào điều đó xảy ra.
• Magento có thể thay đổi API trong phiên bản tương lai không?
  Rất khó xảy ra trong trường hợp này, vì mã của bạn chỉ phụ thuộc vào một giao diện. Nhưng các lớp cụ thể hơn có liên quan hoặc nếu mã của tôi mở rộng một lớp cốt lõi, điều này sẽ trở thành một rủi ro tiềm ẩn.
• Một phiên bản PHP mới có thể phá vỡ mã của tôi. Hoặc có lẽ tôi muốn hỗ trợ PHP 5.6 trong nhiều năm tới.
  Một lần nữa, rất khó xảy ra ở đây, nhưng trong một số trường hợp tôi muốn kiểm tra để cảnh báo tôi, tôi có nên thay đổi mã trong tương lai để sử dụng cú pháp không tương thích.

Làm thế nào đắt tiền để kiểm tra mã?

Điều này có hai khía cạnh:

• Lượng nỗ lực và thời gian cần thiết để viết một bài kiểm tra
• Lượng nỗ lực và thời gian cần thiết để kiểm tra đoạn mã tôi sắp viết thủ công.

Trong quá trình phát triển một số đoạn mã, tôi có xu hướng phải chạy mã tôi đang viết khá thường xuyên cho đến khi tôi xem xét nó. Điều này tất nhiên là dễ dàng hơn nhiều với một bài kiểm tra đơn vị.

Trong trường hợp của bạn viết một bài kiểm tra là chết giá rẻ. Nó không mất nhiều thời gian hoặc nỗ lực. @KAndy đúng rằng tất cả các mã cần phải được duy trì, nhưng sau đó, một lần nữa, không phải tất cả các kiểm tra cần phải được giữ.
Đây có thể là một ví dụ trong đó tôi sẽ viết một bài kiểm tra đơn vị, chỉ để kiểm tra tôi không phạm sai lầm ngớ ngẩn, và sau đó xóa nó sau khi lớp học kết thúc. Nếu một bài kiểm tra không cung cấp giá trị lâu dài, tôi nghĩ việc xóa chúng có ý nghĩa.

Câu hỏi này cũng rất quan trọng trong việc lựa chọn loại bài kiểm tra để viết: đơn vị hoặc tích hợp chẳng hạn.

Đoạn mã tôi đang viết có giá trị như thế nào?

Nếu một đoạn mã tôi đang viết là cần thiết cho dịch vụ mà mô-đun cung cấp, tôi sẽ kiểm tra nó, bất kể nó tầm thường đến mức nào.
Nếu đó chỉ là một phương thức tiện ích nhỏ, ví dụ UI tập trung và không phải là một phần của logic nghiệp vụ, thì có lẽ không.

Mã sẽ cần phải thay đổi?

Theo thời gian, tôi đã quá quen với việc có phạm vi kiểm tra, việc thay đổi mã không được phát hiện cảm thấy rất không an toàn. Điều đó bao gồm những thứ đơn giản như thêm một tùy chọn vào mô hình nguồn, nhưng cũng có những thứ như di chuyển một lớp sang một thư mục / không gian tên khác hoặc đổi tên một phương thức.
Có các bài kiểm tra tại chỗ cho những thay đổi như vậy là vô giá.

Có cần tài liệu không?

Làm thế nào là khó để sử dụng mã? Trong ví dụ của bạn là chuyện nhỏ, nhưng trong một số trường hợp phức tạp hơn, việc kiểm tra là rất tốt cho mục đích tài liệu cho các nhà phát triển khác (hoặc bản thân tôi trong một vài tháng).

Thăm dò và học hỏi

Nếu tôi đang làm việc với một số mã và tôi không chắc chắn làm thế nào để kiểm tra nó, tôi thấy nó rất có giá trị để viết một bài kiểm tra. Quá trình này hầu như luôn cho tôi hiểu sâu hơn về những gì tôi đang giải quyết.
Điều này đặc biệt đúng đối với các nhà phát triển vẫn coi mình đang học thử nghiệm.
Đây cũng là một ví dụ có thể có ý nghĩa để xóa bài kiểm tra sau đó, bởi vì giá trị chính mà nó cung cấp là học tập.

Kỷ luật và căng thẳng

Bám sát vòng lặp tái cấu trúc đỏ-xanh giúp tôi đi nhanh. Điều này đặc biệt đúng dưới áp lực. Vì vậy, ngay cả khi một số đoạn mã không thực sự đáng thử nghiệm, tôi vẫn có thể theo TDD, đặc biệt nếu mã này không quan trọng để kiểm tra.
Điều này giữ cho tôi trong dòng chảy và cảnh báo.

Những gì và làm thế nào để kiểm tra?

Cũng xem xét bạn có thể viết bài kiểm tra trong độ chi tiết rất khác nhau.

• Kiểm tra giá trị trả lại chính xác.
  Đây sẽ là một bài kiểm tra rất cứng nhắc sẽ phải được điều chỉnh theo mọi thay đổi. Bạn có muốn kiểm tra phá vỡ, ví dụ, nếu thứ tự của các mục trong mảng trả về thay đổi?
• Kiểm tra cấu trúc của giá trị trả về.
  Đối với mô hình nguồn, điều này có thể kiểm tra mỗi mảng con là hai bản ghi, một với một labelvà một với một valuekhóa.
• Kiểm tra lớp thực hiện ArrayInterface.
• Kiểm tra lớp cung cấp getOptions()mặc dù phương thức đó không phải là một phần của giao diện được triển khai.

Đối với mỗi điều có thể có thể được kiểm tra, hãy xem xét giá trị, khả năng bảo trì và chi phí.

Tóm lược

Tóm lại: không có câu trả lời đúng cho một câu hỏi nếu một số đoạn mã nên được kiểm tra hay không. Câu trả lời sẽ khác nhau cho mỗi nhà phát triển tùy thuộc vào hoàn cảnh.

Theo tôi, không có câu trả lời chung cho "viết bài kiểm tra đơn vị cho các mô hình nguồn, có hay không"

Tôi đã viết các bài kiểm tra đơn vị cho các mô hình nguồn, nhưng đó là các mô hình nguồn động lấy dữ liệu ngoài và nó hoàn toàn có ý nghĩa.

Đối với các mô hình nguồn không có gì khác ngoài các mảng được tôn vinh (như trong ví dụ của bạn), tôi sẽ không bận tâm đến việc viết các bài kiểm tra đơn vị. Nhưng theo một cách nào đó, bạn cần chắc chắn rằng mình đã không phạm sai lầm. Có một số lựa chọn:

1. kiểm tra đơn vị
2. bài kiểm tra tích hợp
3. tự nhìn vào cấu hình

Bạn đang theo dõi TDD? Sau đó chọn giữa (1) và (2) hoặc cả hai. Nếu không, chọn giữa (2) và (3).

Nếu bạn sử dụng các mô hình nguồn cho các tùy chọn cấu hình hệ thống, một thử nghiệm tích hợp (một thử nghiệm cho tất cả các tùy chọn cấu hình của bạn) có thể hiển thị phần cấu hình và kiểm tra xem các <select>thành phần có mặt và chứa các giá trị dự kiến ​​hay không. Hãy nhớ rằng đây không phải là về việc kiểm tra một lớp cụ thể mà là kiểm tra rằng mọi thứ được gắn với nhau một cách chính xác.

Và như @KAndy đã nói, lý tưởng là bạn sẽ không cần nhiều bản tóm tắt đó, chỉ cần mở rộng một lớp cơ sở đã được kiểm tra đơn vị và ghi đè một thuộc tính hoặc xác định các giá trị trong cấu hình bên ngoài.

Trong kịch bản đó, các thử nghiệm đơn vị cho việc triển khai cụ thể không cung cấp bất kỳ giá trị bổ sung nào. Nếu bạn có nhiều lớp trong số này, có thể bạn nên tự viết một lớp cơ sở ArraySource, miễn là Magento không cung cấp nó.

Với một lớp cơ sở như vậy, mô hình nguồn của bạn có thể trông như thế này:

class Type extends ArraySource
{
    const COLLABORATOR = 1;
    const EMPLOYEE = 2;
    protected $elements = [
        self::COLLABORATOR => 'Collaborator',
        self::EMPLOYEE     => 'Employee',
    ];
    protected $withEmpty = true;
    protected $translate = true;
}

Làm thế nào tôi nên kiểm tra đơn vị?

Tôi nghĩ bạn không nên.

Thêm mã vào hệ thống tăng chi phí hỗ trợ và bảo trì nhưng quá trình thử nghiệm phải là LEAN .

Nhiều hơn mã này không nên tồn tại. Tôi tin rằng trong Magento nên là một cách khai báo chung để xác định các bộ tùy chọn sẽ sử dụng ở những nơi khác nhau. Và sự miễn cưỡng của bạn về bài kiểm tra viết cho lớp này cho tôi thấy mùi mã xấu