Là hoàn toàn phụ thuộc vào các chức năng thuần túy xấu (đặc biệt, để thử nghiệm)?

Để mở rộng một chút về tiêu đề, tôi đang cố gắng đưa ra một kết luận nào đó về việc có cần thiết hay không tuyên bố rõ ràng (tức là tiêm) các hàm thuần mà phụ thuộc vào một số chức năng hoặc lớp khác.

Đây có phải là một đoạn mã đã cho ít kiểm tra hơn hoặc được thiết kế tệ hơn nếu nó sử dụng các hàm thuần túy mà không yêu cầu chúng không? Tôi muốn để có được một kết luận về vấn đề này, cho bất kỳ loại chức năng tinh khiết từ đơn giản, chức năng có nguồn gốc (ví dụ max(), min()- bất kể ngôn ngữ) những phong tục, nhiều phức tạp mà lần lượt có thể ngầm phụ thuộc vào chức năng thuần túy khác.

Mối quan tâm thông thường là nếu một số mã chỉ sử dụng trực tiếp một phụ thuộc, bạn sẽ không thể kiểm tra nó một cách riêng lẻ, cụ thể là bạn sẽ kiểm tra cùng lúc tất cả những thứ mà bạn âm thầm mang theo bên mình. Nhưng điều này bổ sung khá nhiều nồi hơi nếu bạn phải thực hiện nó cho mọi chức năng nhỏ, vì vậy tôi tự hỏi liệu điều này có còn giữ cho các chức năng thuần túy không, và tại sao hoặc tại sao không.

Không, nó không tệ

Các bài kiểm tra bạn viết không nên quan tâm đến cách một lớp hoặc chức năng nhất định được thực hiện. Thay vào đó, cần đảm bảo rằng họ tạo ra kết quả mà bạn muốn bất kể chính xác chúng được thực hiện như thế nào.

Ví dụ, xem xét các lớp sau:

Coord2d{
    float x, y;

    ///Will round to the nearest whole number
    Coord2d Round();
}

Bạn sẽ muốn kiểm tra chức năng 'Round' để đảm bảo rằng nó trả về những gì bạn mong đợi, bất kể chức năng đó được thực hiện như thế nào. Bạn có thể sẽ viết một bài kiểm tra tương tự như sau;

Coord2d testValue(0.6, 0.1)
testValueRounded = testValue.Round()
CHECK( testValueRounded.x == 1.0 )
CHECK( testValueRounded.y == 0.0 )

Từ quan điểm thử nghiệm, miễn là hàm Tọa độ 2: Vòng () của bạn trả về những gì bạn mong đợi, bạn không quan tâm đến cách thức triển khai.

Trong một số trường hợp, tiêm một hàm thuần túy có thể là một cách thực sự xuất sắc để làm cho một lớp có thể kiểm tra hoặc mở rộng hơn.

Tuy nhiên, trong hầu hết các trường hợp, chẳng hạn như hàm Tọa độ 2: Vòng () ở trên, không có nhu cầu thực sự để tiêm hàm min / max / floor / ceil / trunc. Hàm được thiết kế để làm tròn các giá trị của nó thành số nguyên gần nhất. Các bài kiểm tra mà bạn viết nên kiểm tra xem hàm có thực hiện việc này không.

Cuối cùng, nếu bạn muốn kiểm tra mã mà việc triển khai lớp / hàm phụ thuộc vào, bạn có thể làm như vậy bằng cách viết các bài kiểm tra cho sự phụ thuộc.

Ví dụ: nếu hàm Tọa độ 2: Vòng () được triển khai như vậy ...

Coord2d Round(){
    return Coord2d( floor(x + 0.5f),  floor(y + 0.5f))
}

Nếu bạn muốn kiểm tra chức năng 'sàn', bạn có thể làm như vậy trong một thử nghiệm đơn vị riêng biệt.

CHECK( floor (1.436543) == 1.0)
CHECK( floor (134.936) == 134.0)

Được ngầm tùy thuộc vào chức năng thuần túy xấu

Từ quan điểm kiểm tra - Không, nhưng chỉ trong trường hợp các hàm thuần túy , khi hàm trả về luôn cùng một đầu ra cho cùng một đầu vào.

Làm thế nào bạn kiểm tra đơn vị sử dụng chức năng tiêm rõ ràng?
Bạn sẽ tiêm hàm giả (giả) và kiểm tra hàm đó đã được gọi với các đối số chính xác chưa.

Nhưng bởi vì chúng ta có hàm thuần túy , luôn trả về cùng một kết quả cho cùng một đối số - kiểm tra các đối số đầu vào là bằng nhau để kiểm tra kết quả đầu ra.

Với các hàm thuần túy, bạn không cần phải định cấu hình phụ thuộc / trạng thái.

Là lợi ích bổ sung, bạn sẽ nhận được đóng gói tốt hơn, bạn sẽ kiểm tra hành vi thực tế của đơn vị.
Và rất quan trọng từ quan điểm kiểm tra - bạn sẽ được tự do cấu trúc lại mã nội bộ của đơn vị mà không thay đổi các kiểm tra - ví dụ: bạn quyết định thêm một đối số cho hàm thuần túy - với hàm được chèn rõ ràng (giả định trong các bài kiểm tra) bạn sẽ cần thay đổi cấu hình kiểm tra, trong đó với chức năng được sử dụng ngầm, bạn không làm gì cả.

Tôi có thể tưởng tượng tình huống khi bạn cần tiêm chức năng thuần túy - là khi bạn muốn cung cấp cho người tiêu dùng để thay đổi hành vi của đơn vị.

public decimal CalculateTotalPrice(Order order, Func<Customer, decimal> calculateDiscount)
{
    // Do some calculation based on order data
    var totalPrice = order.Lines.Sum(line => line.Price);

    // Then
    var discountAmount = calculateDiscount(order.Customer);

    return totalPrice - discountAmount;
}

Đối với phương pháp trên, bạn hy vọng rằng tính toán chiết khấu có thể được thay đổi bởi người tiêu dùng, vì vậy bạn phải loại trừ kiểm tra logic của nó khỏi các thử nghiệm đơn vị cho CalcualteTotalPricephương pháp.

Trong một thế giới lý tưởng của lập trình OID RẮN, bạn sẽ thực hiện mọi hành vi bên ngoài. Trong thực tế, bạn sẽ luôn luôn sử dụng một số hàm đơn giản (hoặc không đơn giản) trực tiếp.

Nếu bạn đang tính toán tối đa một tập hợp số, có thể sẽ quá mức cần thiết để tiêm một maxhàm và giả định nó trong các bài kiểm tra đơn vị. Thông thường, bạn không quan tâm đến việc tách mã của bạn khỏi việc triển khai cụ thể maxvà kiểm tra mã riêng lẻ.

Nếu bạn đang làm một việc gì đó phức tạp như tìm đường dẫn chi phí tối thiểu trong biểu đồ thì tốt hơn bạn nên thực hiện cụ thể để linh hoạt và thử nghiệm nó trong các bài kiểm tra đơn vị để có hiệu suất tốt hơn. Trong trường hợp này, nó có thể có giá trị công việc tách rời thuật toán tìm đường dẫn từ mã sử dụng nó.

Không thể có câu trả lời cho "bất kỳ loại hàm thuần túy" nào, bạn phải quyết định nơi vẽ đường thẳng. Có quá nhiều yếu tố liên quan đến quyết định này. Cuối cùng, bạn phải cân nhắc lợi ích chống lại những rắc rối mà việc tách rời mang lại cho bạn, và điều đó phụ thuộc vào bạn và bối cảnh của bạn.

Tôi thấy trong các ý kiến ​​mà bạn hỏi về sự khác biệt giữa các lớp tiêm (thực ra bạn tiêm đối tượng) và các hàm. Không có sự khác biệt, chỉ có các tính năng ngôn ngữ làm cho nó trông khác nhau. Từ quan điểm trừu tượng, việc gọi hàm không khác gì gọi phương thức của đối tượng và bạn tiêm (hoặc không) hàm vì những lý do tương tự bạn tiêm (hoặc không) đối tượng: tách rời hành vi đó khỏi mã gọi và có khả năng sử dụng các cách thực hiện khác nhau của hành vi và quyết định nơi nào khác thực hiện để sử dụng.

Vì vậy, về cơ bản bất kỳ tiêu chí nào bạn thấy hợp lệ cho việc tiêm phụ thuộc, bạn có thể sử dụng nó bất kể phụ thuộc là một đối tượng hay hàm. Có thể có một số sắc thái tùy thuộc vào ngôn ngữ (nghĩa là nếu bạn đang sử dụng java thì đây không phải là vấn đề).

Các hàm thuần túy không ảnh hưởng đến khả năng kiểm tra lớp vì các thuộc tính của chúng:

• đầu ra của họ (hoặc lỗi / ngoại lệ) chỉ phụ thuộc vào đầu vào của họ;
• sản lượng của họ không phụ thuộc vào nhà nước thế giới;
• hoạt động của họ không sửa đổi nhà nước thế giới.

Điều này có nghĩa là chúng gần như ở cùng một lĩnh vực với các phương thức riêng tư, hoàn toàn nằm dưới sự kiểm soát của lớp, với phần thưởng được thêm vào thậm chí không phụ thuộc vào trạng thái hiện tại của ví dụ (ví dụ "này"). Lớp người dùng "điều khiển" đầu ra vì nó kiểm soát hoàn toàn các đầu vào.

Các ví dụ bạn đã đưa ra, max () và min (), là xác định. Tuy nhiên, ví dụ ngẫu nhiên () và currentTime () là các thủ tục, không phải là các hàm thuần túy (chúng phụ thuộc vào / sửa đổi trạng thái ra khỏi băng tần), chẳng hạn. Hai cái cuối cùng sẽ phải được tiêm để có thể thử nghiệm.