Разработка F# и поблочное тестирование?
Я просто начал с F#, который является моим первым функциональным языком. Я работал квазиисключительно с C# и наслаждаюсь много, как F# приводит меня заново обдумать, как я пишу код. Одним аспектом я нахожу немного дезориентации, является изменение в процессе написания кода. Я использовал TDD в течение многих лет в C# теперь и действительно ценю, чтобы иметь модульные тесты для знания, где я в.
До сих пор мой процесс с F# должен был записать некоторые функции, игру с ними с интерактивной консолью, пока я не "довольно" уверен, что они работают, и тонкая настройка и объединение. Это работает хорошо над небольшими проблемами как Euler Проект, но я не могу предположить создавать что-то большое тот путь.
Как люди приближаются к поблочному тестированию и созданию набора тестов для программы F#? Существует ли эквивалент TDD? Любые указатели или мысли ценятся.
6 ответов
Тестовые разработчики должны чувствовать себя как дома на таких функциональных языках, как F#: небольшие функции, дающие детерминированно воспроизводимые результаты, идеально подходят для юнит-тестов. Есть также возможности языка F#, которые облегчают написание тестов. Возьмем, к примеру, Object Expressions. Вы можете очень легко написать подделки для функций, которые принимают за входной тип интерфейса.
Если что, то F# является первоклассным объектно-ориентированным языком, и вы можете использовать те же самые инструменты и хитрости, которые вы используете при выполнении TDD в C#. Есть также некоторые инструменты тестирования, написанные на F# или специально для него:
Matthew Podwysocki написал замечательную серию series по юнит-тестированию на функциональных языках. Дядя Боб также написал провокационную статью здесь.
Посмотрите на FsCheck, инструмент автоматического тестирования для F#, по сути, является порт КвикЧек Хаскелла. Он позволяет предоставить спецификацию программа, в виде свойств, которые функции или методы должны удовлетворяют, и FsCheck проверяет, что свойства имеют большое количество случайно сгенерированные случаи.
Как предполагает Дглаубман, вы можете использовать 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#.
Я использую NUnit, и это не кажется мне столь же трудным для чтения или обременительным для написания:
open NUnit.Framework
[<TestFixture>]
type myFixture() = class
[<Test>]
member self.myTest() =
//test code
end
Так как мой код представляет собой смесь F# и других .Net языков, мне нравится то, что я пишу юнит-тесты практически одинаковым способом и со схожим синтаксисом как на F#, так и на C#.