F # phát triển và thử nghiệm đơn vị?

Tôi mới bắt đầu với F #, là ngôn ngữ chức năng đầu tiên của tôi. Tôi đã làm việc gần như độc quyền với C # và rất thích cách F # dẫn tôi đến việc suy nghĩ lại cách tôi viết mã. Một khía cạnh tôi thấy hơi mất phương hướng là sự thay đổi trong quá trình viết mã. Bây giờ tôi đã sử dụng TDD trong nhiều năm trong C # và thực sự đánh giá cao việc thực hiện các bài kiểm tra đơn vị để biết vị trí của tôi.

Cho đến nay, quá trình của tôi với F # là viết một số chức năng, chơi với chúng bằng bảng điều khiển tương tác cho đến khi tôi "hợp lý" chắc chắn rằng chúng hoạt động, và tinh chỉnh & kết hợp. Điều này hoạt động tốt với các vấn đề quy mô nhỏ như Dự án Euler, nhưng tôi không thể tưởng tượng việc xây dựng một cái gì đó lớn theo cách đó.

Làm cách nào để mọi người tiếp cận kiểm thử đơn vị và xây dựng bộ kiểm thử cho chương trình F #? Có tương đương với TDD không? Mọi ý kiến ​​hoặc suy nghĩ đều được đánh giá cao.

Các nhà phát triển theo hướng kiểm tra sẽ cảm thấy thoải mái như ở nhà bằng các ngôn ngữ chức năng như F #: các hàm nhỏ cung cấp kết quả có thể lặp lại một cách xác định cho phép họ hoàn toàn phù hợp với các bài kiểm tra đơn vị. Ngoài ra còn có các khả năng trong ngôn ngữ F # hỗ trợ các bài kiểm tra viết. Lấy ví dụ, Biểu thức đối tượng . Bạn rất có thể dễ dàng viết giả mạo cho các chức năng lấy đầu vào của chúng như một kiểu giao diện.

Nếu có, F # là ngôn ngữ hướng đối tượng hạng nhất và bạn có thể sử dụng các công cụ và thủ thuật tương tự như bạn sử dụng khi thực hiện TDD trong C #. Ngoài ra còn có một số công cụ kiểm tra được viết bằng hoặc dành riêng cho F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki đã viết một loạt bài tuyệt vời về kiểm thử đơn vị bằng các ngôn ngữ chức năng. Chú Bob cũng đã viết một bài báo kích thích suy nghĩ ở đây .

Tôi sử dụng NUnit và nó không khiến tôi khó đọc hoặc khó viết:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

    [<Test>]
    member self.myTest() =
       //test code

end

Vì mã của tôi là sự kết hợp của F # và các ngôn ngữ .Net khác, nên tôi thích thực tế là tôi viết các bài kiểm tra đơn vị về cơ bản giống nhau và với cú pháp tương tự trong cả F # và C #.

Hãy xem FsCheck , một công cụ kiểm tra tự động cho F #, về cơ bản là một cổng QuickCheck của Haskell. Nó cho phép bạn cung cấp đặc điểm kỹ thuật của chương trình, dưới dạng thuộc tính mà các hàm hoặc phương thức phải đáp ứng, và kiểm tra FsCheck rằng các thuộc tính đó có trong một số lượng lớn các trường hợp được tạo ngẫu nhiên.

FsCheck CodePlex Trang

Trang tác giả FsCheck

Như dglaubman gợi ý bạn có thể sử dụng NUnit. xUnit.net cũng cung cấp hỗ trợ cho việc này và hoạt động tốt với TestDriven.net . Mã trông tương tự như các bài kiểm tra NUnit nhưng không có yêu cầu bao bọc bài kiểm tra trong một loại có chứa.

#light

// Supply a module name here not a combination of module and namespace, otherwise
// F# cannot resolve individual tests nfrom the UI.
module NBody.DomainModel.FSharp.Tests

open System
open Xunit

open Internal

[<Fact>]
let CreateOctantBoundaryReordersMinMax() =
    let Max = VectorFloat(1.0, 1.0, 1.0)
    let Min = VectorFloat(-1.0, -1.0, -1.0)

    let result = OctantBoundary.create Min Max

    Assert.Equal(Min, result.Min)     
    Assert.Equal(Max, result.Max) 

Tôi nghĩ đây là một câu hỏi rất thú vị mà bản thân tôi đã tự hỏi rất nhiều. Suy nghĩ của tôi từ trước đến nay chỉ là suy nghĩ, vì vậy hãy coi chúng là gì.

Tôi nghĩ rằng mạng lưới an toàn của một bộ thử nghiệm tự động là một tài sản quá giá trị để bỏ qua, tuy nhiên, bảng điều khiển tương tác đó có thể hấp dẫn, vì vậy tôi dự định tiếp tục viết các bài kiểm tra đơn vị như tôi đã từng làm.

Một trong những điểm mạnh chính của .NET là khả năng đa ngôn ngữ. Tôi biết mình sẽ sớm viết mã sản xuất F #, nhưng kế hoạch của tôi là viết các bài kiểm tra đơn vị bằng C # để dễ dàng tiếp cận ngôn ngữ mới đối với tôi. Bằng cách này, tôi cũng có thể kiểm tra xem những gì tôi viết bằng F # sẽ tương thích với C # (và các ngôn ngữ .NET khác).

Với cách tiếp cận này, tôi hiểu rằng có một số tính năng nhất định của F # mà tôi chỉ có thể sử dụng nội bộ trong mã F # của mình, nhưng không được tiết lộ như một phần của API công khai của tôi, nhưng tôi sẽ chấp nhận điều đó, cũng như hôm nay tôi chấp nhận rằng có một số điều C # cho phép tôi thể hiện (giống như uint) không tuân thủ CLS, và vì vậy tôi không sử dụng chúng.

Bạn có thể xem qua FSUnit - mặc dù tôi chưa sử dụng nó nhưng nó có thể đáng để thử. Chắc chắn tốt hơn là sử dụng NUnit ví dụ (gốc) trong F #.

Mặc dù đến bữa tiệc hơi muộn, tôi muốn chào mừng Mathias đến với F # (muộn còn hơn không;)) và kêu vang rằng bạn có thể thích thư viện thử nghiệm đơn vị của tôi, Expecto

Expecto có một số tính năng mà bạn có thể thích:

• Cú pháp F # xuyên suốt, kiểm tra dưới dạng giá trị; viết F # thuần túy để tạo các bài kiểm tra
• Sử dụng mô-đun Expect tích hợp sẵn hoặc một lib bên ngoài như Unquote cho các xác nhận
• Kiểm tra song song theo mặc định
• Kiểm tra mã Hopac hoặc mã Async của bạn; Expecto không đồng bộ trong suốt
• Ghi nhật ký và số liệu dễ hiểu thông qua Logary Facade; dễ dàng viết các bộ điều hợp để xây dựng hệ thống hoặc sử dụng cơ chế thời gian để xây dựng trang tổng quan InfluxDB + Grafana về thời gian thực hiện các thử nghiệm của bạn
• Hỗ trợ tích hợp cho BenchmarkDotNet
• Xây dựng hỗ trợ cho FsCheck; giúp dễ dàng tạo các bài kiểm tra với dữ liệu được tạo / ngẫu nhiên hoặc xây dựng các mô hình bất biến của không gian trạng thái của đối tượng / tác nhân của bạn

-

open Expecto

let tests =
  test "A simple test" {
    let subject = "Hello World"
    Expect.equal subject "Hello World" "The strings should equal"
  }

[<EntryPoint>]
let main args =
  runTestsWithArgs defaultConfig args tests

https://github.com/haf/expecto/