Aufruf Standard-FsCheck-Generator von einem benutzerdefinierten Generator des gleichen Typs

Question

Ich definierte einen Typ mit ein paar benutzerdefinierten Generatoren, damit FsCheck benutzerdefinierte Instanzen von ein paar Typen generieren. Aber für einen der komplexen Typen möchte ich zuerst die Standard-FsCheck-Generierung verwenden und dann das Ergebnis anpassen. Hier ist eine (vereinfachte) Code:

type CustomGenerators = 
    static member FirstCustomType() = /* function that returns FirstCustomType */ 
    static member SecondCustomType() = 
     Arb.generate<SecondCustomType> 
     |> Gen.map (fun x -> /* adjust some data in the generated instance */) 
     |> Arb.fromGen 

Das Problem ist, dass, wenn SecondCustomType() statische Methode nennt es Arb.generate ruft sofort SecondCustomType() verursacht eine endlose Rekursion. Ich verstehe, dass Arb.generate benutzerdefinierte Generatoren respektieren muss, deshalb ruft es statische SecondCustomType() auf, aber ich muss die standardmäßige (nicht angepasste) Arb.generate-Implementierung für SecondCustomType aufrufen. Ich kann die Implementierung nicht von einem anderen Typ aufrufen, da mein benutzerdefinierter Generator einen benutzerdefinierten Generator für FirstCustomType verwendet. Daher muss die SecondCustomType-Standardimplementierung alle benutzerdefinierten Generatoren kennen, die im Typ CustomGenerators definiert sind. Dies ist eine Art schlechter Kreis, für den ich noch keine saubere Lösung gefunden habe (nur Workaround).

Answer 1

Alle "default" (d. H. Aus der Box) Generatoren sind in der FsCheck.Arb.Default Klasse. Abhängig davon, was Ihre SecondCustomType tatsächlich ist, können Sie einige Methoden für diese Klasse verwenden, z. B. Bool oder String.

Wenn Ihr Typ ein ordnungsgemäßer algebraischer F # -Typ ist (z. B. Vereinigung, Datensatz oder Tupel), können Sie den automatisch abgeleiteten Generator für solche Typen nutzen, der durch dargestellt wird.

type CustomGenerators = 
    static member SecondCustomType() = 
     Arb.Default.Derive<SecondCustomType>() 
     |> Arb.toGen 
     |> Gen.map (fun x -> (* adjust some data in the generated instance *)) 
     |> Arb.fromGen 

---

Having said that, würde ich oben mit Mark Kommentar einig: diese statisch-Methode-Shim-for-Typ-Klasse-Generatoren verwendet, wird immer ein bisschen umständlich. Genau wie Mark, ich bevorzuge es, wenn FsCheck bietet, was es aus der Box bieten kann, und dann die gewünschte Eingabe mit regulären Funktionen zusammenzustellen. Ich gebe dir ein Beispiel.

Betrachten Sie diese Art, die vermutlich nicht durch FsCheck aus dem Kasten heraus generiert werden:

type SomeAwkwardType(name: string, id: int, flag: bool) = 
    member this.Name = name 
    member this.Id = id 
    member this.Flag = flag 

Hier ist die unangenehme Art und Weise des statischen-Shim-für-Typ-Klasse Generator:

type AwkwardTypeGenerator() = 
    static member Gen() = 
     gen { 
     let! name = Arb.generate<string> 
     let! id = Arb.generate<int> 
     let! flag = Arb.generate<bool> 
     return SomeAwkwardType(name, id, flag) 
     } 

module Tests = 
    let [Property] ``Test using the awkward generator`` (input: SomeAwkwardType) = 
     someFn input = 42 

Und hier ist die einfacher (meiner Meinung nach) Weg, um die Eingabe zu erzeugen:

module Tests = 
    let [Property] ``Test using straightforward generation`` (name, id, flag) = 
     let input = SomeAwkwardType(name, id, flag) 
     someFn input = 42 

Dies ist nicht nur kürzer und sauberer, sondern hat auch den Vorteil, dass Sie Ihr Haar ein Jahr später nicht ziehen müssen, wenn Sie die Codebasis für die statische Klasse durchsuchen müssen, die den Generator implementiert.