Разработка 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 или асинхронный код; 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/