F # розробка та тестування одиниць?

Я щойно розпочав роботу з F #, що є моєю першою функціональною мовою. Я працюю квазі-ексклюзивно з C #, і мені дуже подобається, як F # приводить мене до переосмислення, як я пишу код. Один з аспектів, який мені здається дезорієнтуючим, - це зміна процесу написання коду. Я використовую TDD протягом багатьох років у C # і дуже ціную, що я маю тести, щоб знати, де я перебуваю.

Поки мій процес з F # полягав у написанні деяких функцій, відтворенні з ними за допомогою інтерактивної консолі, поки я не буду "впевнено" впевнений, що вони працюють, і налаштувати та комбінувати. Це добре працює в масштабних проблемах, таких як проект Ейлера, але я не можу уявити, щоб створити щось таке велике.

Як люди підходять до тестування одиниць і створення тестового набору для програми F #? Чи є еквівалент TDD? Будь-які вказівки чи думки цінуються.

Тестові розробники повинні відчувати себе вдома у функціональних мовах, таких як F #: невеликі функції, що дають детерміновано повторювані результати, прекрасно піддаються одиничним тестам. Існують також можливості на мові F #, які полегшують письмові тести. Візьмемо, наприклад, Об'єктні вирази . Ви можете дуже легко писати підробки для функцій, які приймають за свій вхід тип інтерфейсу.

Якщо що-небудь, F # - це першокласна об'єктно-орієнтована мова, і ви можете використовувати ті самі інструменти та хитрощі, які ви використовуєте під час виконання TDD в C #. Існують також деякі інструменти тестування, написані або спеціально для F #:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Метью Подвісоцький написав чудову серію про тестування одиниць на функціональних мовах. Дядько Боб також написав тут статтю, що провокує думку .

Я використовую NUnit, і мені це не здається важким для читання або обтяжливим для написання:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

Оскільки мій код є сумішшю F # та інших мов .Net, мені подобається те, що я пишу одиничні тести в основному однаково і з подібним синтаксисом як у F #, так і в C #.

Погляньте на FsCheck , автоматичний інструмент тестування для F #, в основному це порт QuickCheck Haskell. Це дозволяє надати специфікацію програми у вигляді властивостей, яким повинні задовольняти функції чи методи, та тестів FsCheck, які властивості містять у великій кількості випадково генерованих випадків.

Сторінка FsCheck CodePlex

Сторінка автора FsCheck

Як пропонує dglaubman, ви можете використовувати NUnit. xUnit.net також надає підтримку для цього і добре працює з TestDriven.net . Код схожий на тести NUnit, але без вимоги переносити тест у тип, що містить.

#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) 

Я думаю, що це дуже цікаве запитання, про яке я багато чого задався питанням. Наразі мої думки - це лише думки, тому сприймайте їх такими, якими вони є.

Я думаю, що безпечна сітка автоматизованого тестового набору є надто цінним надбанням, щоб її відпустити, однак заманливо ця інтерактивна консоль може бути, тому я планую продовжувати писати одиничні тести, як це робив завжди.

Однією з головних сильних сторін .NET є можливості міжмовної мови. Я знаю, що незабаром буду писати виробничий код F #, але мій план - написати одиничні тести на C #, щоб полегшити мені шлях до нової мови. Таким чином я також перевіряю, що те, що я пишу у F #, буде сумісним із C # (та іншими мовами .NET).

При такому підході я розумію, що є певні особливості F #, які я можу використовувати лише внутрішньо у своєму коді F #, але не виставляти її як частину свого публічного API, але я прийму це, як і сьогодні приймаю, що є певні речі C # дозволяє мені висловити (як uint), які не відповідають сумісності CLS, і тому я утримуюсь від їх використання.

Ви можете поглянути на FSUnit - хоча я ще цього не використовував, варто спробувати. Звичайно, краще, ніж використовувати наприклад (рідний) NUnit у F #.

Незважаючи на те, що трохи запізнився на вечірку, я хотів би привітати Матіаса до F # (краще пізніше, ніж ніколи)) і задзвонити, що, можливо, вам сподобається моя тестова бібліотека, Expecto

Expecto має деякі функції, які вам можуть сподобатися:

• F # синтаксис протягом, тестує як значення; написати звичайний F # для генерації тестів
• Використовуйте вбудований модуль Expect або зовнішню вкладку, як Unquote для тверджень
• Паралельні тести за замовчуванням
• Перевірте свій код Hopac або код Async; Expecto асинхронізується протягом усього часу
• Підключення до журналу та метрики через Logary Facade; легко записуйте адаптери для систем побудови або використовуйте механізм синхронізації для побудови інформаційної панелі InfluxDB + Grafana строків виконання ваших тестів
• Вбудована підтримка BenchmarkDotNet
• Створіть підтримку FsCheck; дозволяє легко будувати тести з генерованими / випадковими даними або будувати інваріантні моделі простору стану вашого об'єкта / актора

-

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/