F # 개발 및 단위 테스트?


107

제 첫 번째 기능 언어 인 F #으로 막 시작했습니다. 저는 C #과 유사하게 작업 해 왔으며 F #이 코드 작성 방법을 다시 생각하게하는 방법을 많이 즐깁니다. 내가 조금 혼란스러워하는 한 가지 측면은 코드 작성 과정의 변화입니다. 저는 C #에서 수년 동안 TDD를 사용해 왔으며 현재 위치를 알 수있는 단위 테스트가 있다는 점에 감사드립니다.

지금까지 F #을 사용한 저의 프로세스는 일부 함수를 작성하고, "합리적으로"작동하는지 "합리적으로"확인 될 때까지 대화 형 콘솔로 재생하고, 조정 및 결합하는 것이 었습니다. 이것은 오일러 프로젝트와 같은 소규모 문제에서 잘 작동하지만 그렇게 큰 것을 만드는 것을 상상할 수 없습니다.

사람들은 어떻게 단위 테스트에 접근하고 F # 프로그램을위한 테스트 제품군을 구축합니까? TDD에 상응하는 것이 있습니까? 어떤 조언이나 생각이라도 감사합니다.


1
expert-fsharp.com/CodeSamples/Forms/… 는 F #과 함께 NUnit을 사용하는 간단한 예를 보여줍니다.
itowlson


관련 : stackoverflow.com/questions/5667372/...는 (이 페이지에 answerset 내에있는 인용을 끝내 훨씬 더 각주 / 주석보다)
루벤 Bartelink

이 답변에서 빠진 한 가지는 F #의 유형 추론과 관련된 Foq, AutoFixture.AutoFoq 및 AutoFixture.xUnit의 적절한 예입니다. 맛보 는 사람 은 trelford.com/blog/post/test5.aspxtrelford.com/blog/post/fstestlang.aspx 를 참조하십시오. 언젠가 여기에 적절한 답변을 작성하겠습니다
Ruben Bartelink 2013

답변:


77

테스트 기반 개발자는 F #과 같은 기능적 언어를 사용하는 편이 좋습니다. 결정적으로 반복 가능한 결과를 제공하는 작은 함수가 단위 테스트에 완벽하게 적합합니다. F # 언어에는 테스트 작성을 용이하게하는 기능도 있습니다. 예를 들어, Object Expressions . 인터페이스 유형을 입력으로 취하는 함수에 대한 가짜를 매우 쉽게 작성할 수 있습니다.

F #은 최고 수준의 개체 지향 언어이며 C #에서 TDD를 수행 할 때 사용하는 것과 동일한 도구와 트릭을 사용할 수 있습니다. 또한 F #으로 작성되었거나 특별히 작성된 몇 가지 테스트 도구가 있습니다.

Matthew Podwysocki는 기능적 언어의 단위 테스트에 대한 훌륭한 시리즈 를 썼습니다 . 밥 삼촌도 여기에 생각을 자극하는 기사를 썼다 .


9
또한 Unquote : code.google.com/p/unquote 라는 F # 특정 단위 테스트 라이브러리를 개발했으며 적극적으로 개발 중 입니다. F # 인용문을 사용하여 테스트 어설 션을 정적으로 확인 된 일반 F # 부울 식으로 작성하고 자동으로 멋진 테스트 실패 메시지를 생성 할 수 있습니다. xUnit.net 및 NUnit에 대한 특별 지원으로 구성없이 작동하며 일반적으로 모든 예외 기반 단위 테스트 프레임 워크를 지원합니다. FSI 세션 내에서도 작동하므로 대화 형 테스트에서 공식 테스트 스위트로 원활하게 마이그레이션 할 수 있습니다.
Stephen Swensen 2011

있다 PEX는 그 조금 더 어려운 grok 수하기 비록, 너무.
Benjol 2013 년

1
삼촌 밥 링크가 죽은 것 같다
AAGE

22

나는 NUnit을 사용하고 있으며 읽기가 어렵거나 쓰기가 번거롭지 않습니다.

open NUnit.Framework

[<TestFixture>]
type myFixture() = class

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

end

내 코드는 F #과 다른 .Net 언어가 혼합되어 있기 때문에 기본적으로 동일한 방식으로 F #과 C #에서 유사한 구문으로 단위 테스트를 작성한다는 사실이 마음에 듭니다.


4
여기에서 다른 답변을 읽은 후 FSUnit을 사용해 보았는데 대단하다고 생각합니다. TestDriven.Net (NUnit과 마찬가지로)과 잘 작동하고, 자체 문서화 테스트를 작성하는 유동적 인 스타일을 장려하며, Ray가 말한 것처럼 "F # 언어에서 집에 더 가깝습니다". 21 줄의 코드에는 나쁘지 않습니다! (그리고 몇 가지 레이아웃 / 이름 지정 권장 사항). 두 가지 간단한 참고 사항 : 1. 미리 컴파일 된 FSUnit DLL이 작동하지 않았습니다. 소스 (FsUnit.NUnit-0.9.0.fs)에서 빌드하면 문제가 해결되었습니다. 2. TestDriven.Net은 .NET으로 보이는 TextFixture 이름을 인식하지 못합니다 `like this`. 이중 틱 형식을 사용하는 테스트 이름이 인식됩니다.
David Glaubman 2010 년

15

한 번 봐 가지고 FsCheck , F #의 자동 테스트 도구를 기본적으로 하스켈의 QuickCheck의 포트입니다. 이를 통해 함수 나 메서드가 충족해야하는 속성의 형태로 프로그램 사양을 제공 할 수 있으며, FsCheck는 속성이 무작위로 생성 된 많은 경우에서 보유하는지 테스트합니다.

FsCheck CodePlex 페이지

FsCheck 작성자 페이지


예, FsCheck는 NUnit 등과 같은 기존 단위 테스트 프레임 워크보다 훨씬 더 많은 것을 제공한다고 생각합니다.
Robert

11

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) 

1.9.1부터 Xunit의 새로운 과부하가 내 F #에 혼란을 일으키는 것 같습니다.
Rick Minerich 2012

@RickMinerich 나는 내 코드에서 똑같은 일이 일어나는 것을 경험했습니다. 올바른 오버로드가 선택되도록 명시 적 유형 주석을 추가했습니다. 그러나, 이것은 않습니다 불행히도 코드에 더 많은 노이즈를 추가합니다.
Erik Schierboom

11

제 자신이 많이 궁금해했던 매우 흥미로운 질문이라고 생각합니다. 지금까지의 내 생각은 생각 일 뿐이므로 그대로 가져 가십시오.

자동화 된 테스트 스위트의 안전망은 놓치기에는 너무 가치가 있다고 생각하지만, 대화 형 콘솔이 매력적일 수 있으므로 항상 그랬던 것처럼 단위 테스트를 계속 작성할 계획입니다.

.NET의 주요 강점 중 하나는 언어 간 기능입니다. 조만간 F # 프로덕션 코드를 작성할 예정이라는 것을 알고 있지만, 제 계획은 C #으로 단위 테스트를 작성하여 저에게 새로운 언어를 쉽게 적용하는 것입니다. 이런 식으로 F #으로 작성한 내용이 C # (및 기타 .NET 언어)과 호환되는지 테스트 할 수 있습니다.

이 접근 방식을 사용하면 F # 코드에서 내부적으로 만 사용할 수 있지만 공용 API의 일부로 노출 할 수없는 F #의 특정 기능이 있다는 것을 이해합니다. C #을 사용하면 uintCLS 규격이 아닌 것을 표현 (예 :) 할 수 있으므로 사용하지 않습니다.


2
계획은 어땠어? C # 코드로 f # 코드를 테스트하는 것이 쉬웠습니까? 나는 f #을 배우기 시작했고 내 계획은 내 프로젝트의 일부를 f #으로 작성하는 것이며, 같은 생각이 있습니다 : f #에 대한 단위 테스트도 C #으로 작성하는 것입니다.
Peter Porfy 2012 년

@ 업데이트를 표시 하시겠습니까? 또한 F #에서 TDD를 사용하여 흐름을 시작하는 데 어려움을 겪고 있습니다.
Scott Nimrod

1
@ScottNimrod 꽤 많은 업데이트 : 내 Pluralsight 과정 중 4 개는 테스트 또는 F #을 사용한 TDD에 관한 것입니다. 또한 내 Lanyrd 프로필 에서 컨퍼런스 강연에 대한 많은 무료 녹음을 찾을 수 있습니다 . 마지막으로 내 블로그가 있습니다.
Mark Seemann 2015

3
@ScottNimrod 저는 Mark의 PS 코스 전체 세트를 충분히보기 위해 시간을 할애하거나 돈을 지불하는 것을 추천 할 수 없습니다. 최대한의 효율성으로 모든 것을 머릿속에 담을 것입니다. 특정 요구 사항에 적용 할 수도 있고 적용하지 않을 수도 있지만 "F #의 기능적 아키텍처"도 많은 점을 연결하므로 강력하게 고려해야합니다.
Ruben Bartelink

7

FSUnit을 살펴볼 수 있습니다. 아직 사용하지는 않았지만 시도해 볼 가치가 있습니다. 예를 들어 F #에서 (네이티브) NUnit을 사용하는 것보다 확실히 낫습니다.


1
ShdNx, 왜 NUnit을 추천하지 않습니까? Don Syme의 F # 책은 테스트를위한 NUnit을 보여 주며 C #에서 NUnit을 사용하는 것과 매우 유사합니다. FSUnit DSL은 멋져 보이지만 이미 NUnit에 익숙한 사람들에게는 (Mathias가 "수년간 TDD를 사용해 왔습니다") NUnit을 F #과 함께 사용하는 것이 C # 또는 VB보다 문제가 더 많다는 경험이 있습니까?
itowlson

나는 두 번째 itowlson 코멘트와 질문. 확실히 F #의 NUnit은 상당히 이상해 보이지만 그 외에도 다른 것을 사용하는 것이 좋은 아이디어가되는 특정 문제를 알고 있습니까?
Mathias

1
나는 "매우 이상해 보이는 것"이 ​​일반적으로 더 나은 것을 찾는 설득력있는 이유라고 말하고 싶습니다. 이상해 보이는 것은 읽기 어렵다는 것을 의미하고 읽기 어렵다는 것은 버그를 의미합니다. (저는 "이상해 보이는 것"이 ​​"새롭거나 익숙하지 않은 것"과 완전히 다르다고 가정하고 있습니다. 익숙하지 않은 사람은 익숙해 질 것이고 이상한 것은 이상하게 보일 것입니다.)
James Moore

1
솔직히 말해서 (내 응답에서 언급했듯이) 아직 FSUnit을 사용하지 않았지만 F #에서 NUnit을 사용하는 것이 매우 고통 스럽다는 것을 읽었습니다. 그렇지 않다면 죄송합니다.
ShdNx

4
명확하게 말하면 FsUnit을 사용하는 경우에도 TestFixtures 및 Test 멤버가 있습니다. 당신이 가질 수없는 것은 표준 Assert.X 호출입니다. FsUnit은 NUnit의이 부분에 대한 래퍼를 제공하여 F # 언어로 집에서 더 많이 사용할 수 있도록합니다.
Ray Vernagus 2010 년

1

파티에 조금 늦었음에도 불구하고 Mathias를 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/

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.