F # geliştirme ve birim testi?

İlk işlevsel dilim olan F # ile yeni başladım. Yarı-sadece C # ile çalışıyorum ve F # 'ın beni nasıl kod yazacağımı yeniden düşünmeye yönlendirdiği çok hoşuma gidiyor. Biraz kafa karıştırıcı bulduğum bir yön, kod yazma sürecindeki değişiklik. TDD'yi yıllardır C # ile kullanıyorum ve nerede olduğumu bilmek için birim testlere sahip olduğum için gerçekten minnettarım.

Şimdiye kadar, F # ile sürecim, bazı işlevler yazmak, çalıştıklarından "makul ölçüde" emin olana kadar etkileşimli konsolla oynamak ve ince ayar yapmak ve birleştirmek oldu. Bu, Euler Projesi gibi küçük ölçekli problemlerde işe yarar, ancak bu şekilde büyük bir şey inşa etmeyi hayal edemiyorum.

İnsanlar birim testine ve bir F # programı için bir test paketi oluşturmaya nasıl yaklaşıyor? TDD'nin bir eşdeğeri var mı? Herhangi bir işaret veya düşünce takdir edilir.

Test odaklı geliştiriciler F # gibi işlevsel dillerde kendilerini evlerinde hissetmelidir: deterministik olarak tekrarlanabilir sonuçlar veren küçük işlevler, birim testlerine mükemmel bir şekilde katkıda bulunur. F # dilinde yazma testlerini kolaylaştıran yetenekler de vardır. Örneğin, Nesne İfadelerini ele alalım . Girdi olarak bir arabirim türü alan işlevler için kolayca sahte yazabilirsiniz.

Bir şey varsa, F # birinci sınıf bir nesne yönelimli dildir ve C # ile TDD yaparken kullandığınız aynı araçları ve püf noktalarını kullanabilirsiniz. Ayrıca, özellikle F # için yazılmış bazı test araçları da vardır:

• NaturalSpec
• FsCheck
• FsTest
• FsUnit

Matthew Podwysocki , fonksiyonel dillerde birim testi üzerine harika bir dizi yazdı . Bob Amca da burada düşündürücü bir makale yazdı .

NUnit kullanıyorum ve okuması ya da yazması o kadar zor olmuyor:

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

Kodum F # ve diğer .Net dillerinin bir karışımı olduğu için, birim testlerini temelde aynı şekilde ve hem F # hem de C # ile benzer sözdizimiyle yazmam hoşuma gidiyor.

F # için otomatik bir test aracı olan FsCheck'e bir göz atın , temelde Haskell's QuickCheck'in bir bağlantı noktasıdır. Fonksiyonların veya yöntemlerin karşılaması gereken özellikler biçiminde programın bir spesifikasyonunu sağlamanıza ve özelliklerin çok sayıda rastgele oluşturulmuş durumlarda sahip olduğu FsCheck testlerine olanak tanır.

FsCheck CodePlex Sayfası

FsCheck Yazar Sayfası

Dglaubman'ın önerdiği gibi NUnit'i kullanabilirsiniz. xUnit.net ayrıca bunun için destek sağlar ve TestDriven.net ile iyi çalışır . Kod, NUnit testlerine benzer, ancak testi kapsayıcı bir türle sarmalama gerekliliği yoktur.

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

Bence bu, benim de çok merak ettiğim çok ilginç bir soru. Şimdiye kadarki düşüncelerim sadece düşünceler, bu yüzden onları oldukları gibi alın.

Otomatik bir test paketinin güvenlik ağının bırakılamayacak kadar değerli olduğunu düşünüyorum, ancak bu etkileşimli konsol ne kadar çekici olsa da, bu yüzden her zaman yaptığım gibi birim testleri yazmaya devam etmeyi planlıyorum.

.NET'in temel güçlü yönlerinden biri, diller arası yetenekleridir. Yakında F # üretim kodu yazacağımı biliyorum, ancak planım C # ile birim testleri yazmak ve benim için yeni bir dilin ne olduğunu anlamamı kolaylaştırmak. Bu şekilde, F # ile yazdıklarımın C # (ve diğer .NET dilleri) ile uyumlu olup olmayacağını da test edebilirim.

Bu yaklaşımla, F # kodumun yalnızca dahili olarak kullanabileceğim, ancak genel API'mın bir parçası olarak ifşa edemeyeceğim bazı özelliklerinin olduğunu anlıyorum, ancak bunu bugün kabul ettiğim gibi, bazı şeylerin olduğunu kabul ediyorum. C #, uintCLS uyumlu olmayanları ifade etmeme (beğenmeme ) izin veriyor ve bu yüzden onları kullanmaktan kaçınıyorum.

FSUnit'e bir göz atabilirsiniz - henüz kullanmamış olsam da denemeye değer olabilir. F # 'da örneğin (yerel) NUnit kullanmaktan kesinlikle daha iyidir.

Partiye biraz geç kalmamıza rağmen Mathias'ı F #'a davet ediyorum (hiç olmamasından daha iyi;) ve birim test kitaplığım Expecto'yu beğenebileceğinizi söyleyin.

Expecto'nun beğenebileceğiniz bazı özellikleri vardır:

• F # sözdizimi boyunca, değerler olarak test eder; testleri oluşturmak için düz F # yazın
• İddialar için yerleşik Expect modülünü veya Unquote gibi harici bir kitaplığı kullanın
• Varsayılan olarak paralel testler
• Hopac kodunuzu veya Async kodunuzu test edin; Expecto baştan sona eşzamansızdır
• Logary Facade aracılığıyla takılabilir günlük kaydı ve ölçümler; derleme sistemleri için adaptörleri kolayca yazın veya testlerinizin yürütme sürelerinin InfluxDB + Grafana panosunu oluşturmak için zamanlama mekanizmasını kullanın
• BenchmarkDotNet için yerleşik destek
• FsCheck için destek oluşturun; oluşturulan / rastgele verilerle testler oluşturmayı veya nesnenizin / aktörün durum uzayının değişmez modellerini oluşturmayı kolaylaştırır

-

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/