6

In F#, I want to build a hierarchical data structure in a way with a minimum amount of language noise. The actual problem is trying to build an RSpec inspired framework using F#. RSpec allows the construction of tests in a nested way. For example.

describe Order do
  context "with no items" do
    it "behaves one way" do
      # ...
    end
  end

  context "with one item" do
    it "behaves another way" do
      # ...
    end
  end
end

I have something working here, but there are some potential problems with the current solution. In particular general setup/teardown code can become somewhat ugly.

My primary concern is to write an API that allows the user to write tests/specifications in a way, where the language gets as little in the way as possible.

I think that using computation expressions could allow my to create a better API, but I am struggling with implementing nested contexts.

Currently I do have a builder that allows me to write:

let specs =
    describe "Some feature" {
        it "has some behavior" (fun () -> 
            // Test code goes here
        )
    }

But in order to have nested contexts I need to be able to write something like this:

let specs =
    describe "Some feature" {
        describe "in some context" {
            it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
        describe "in some other context" {
            it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
    }

I have no idea how to implement the nested context. Or even if it is possible to bend F# in a way to allow me to create such a builder.

I did make an experiment, that allowed me to write this:

let specs =
    desribe "Some feature" {
        child (describe "in some other" {
            it "has some behavior" (fun () -> 
                // Test code goes here
            )
        })
        child (describe "in some context" {
            it "has some behavior" (fun () -> 
                // Test code goes here
            )
        })
    }

But the added parenthesis and explicit builder construction is exactly what I want to avoid in the first place.

type DescribeBuilder(name : string) =
    [<CustomOperation("it")>]
    member __.It (x, name, test : unit -> unit) =
        let t = TestContext.createTest name test
        x |> TestContext.addTest t
    [<CustomOperation("child")>]
    member __.Child(x, child :TestContext.T) =
        x |> TestContext.addChildContext child
    member __.Yield y =
        TestContext.create name
    member __.Delay (x) =
        x()
let describe name = new DescribeBuilder(name)
6
  • 3
    Your question is unanswerable unless you can tell us what you consider "elegant." Commented Nov 18, 2013 at 16:18
  • Hmm - I will try think about rephrasing it. But I do provide an example of the syntax I would like, so if there is a solution that allows me to write that syntax, then that solution definitely fall within my idea of "elegant"
    – Pete
    Commented Nov 18, 2013 at 16:25
  • Which example is that, the last one? Commented Nov 18, 2013 at 16:27
  • The one just after "I want to be able to write code like this:" I will try to make my intention more clear
    – Pete
    Commented Nov 18, 2013 at 16:27
  • 2
    Instead of focusing on syntax, focus on composability first. Then write syntax on top of that, if needed. And even if it's not possible to have the syntax exactly the way you wanted, composability is far more important. Commented Nov 18, 2013 at 20:33

3 Answers 3

2

Have you tried any of the bang (!) keywords? You might be able to do it like so:

let specs =
    describe "Some feature" {
        do! describe "in some context" {
            do! it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
        do! describe "in some other context" {
            do! it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
    }

assuming your it returns something in the describe workflow.

(The above might be improper F# as I've been away from it for a while, but you should be able to do something like it.)

0

For this, I don't see why would you want to use computation expressions, a simple discriminated union with single case would suffice:

type Hierarchy = Hierarchy of Hierarchy list

let h = Hierarchy [ Hierarchy []; Hierarchy [ Hierarchy [] ] ]

It's possible you need something more, but it's not clear from your example.

1
  • I need more than that, I simplified the example greatly to highlight the particular problem I want to solve. But based on comments I can determine that my intent is not too clear, so I'm trying to rephrase it.
    – Pete
    Commented Nov 18, 2013 at 17:01
0

I saw your fspec project and by proxy got to this question. I like your attempt to use computation expressions (CE). You seem to be trying to use them like macro definitions.

The Ruby example uses context instead of a second describe. Maybe you can do the same.

let specs = 
    describe "Order" {
        context "with no items"
        it "behaves one way" (fun () -> 0)

        context "with one item"
        it "behaves another way" (fun () -> 1)
    }

Just having the members might give the same expressiveness without needing nesting. You can put the yield and child code together for the context. Zero can have an empty TestContext created and it could work with the forwarded child context as x instead on an explicit one.

x.createTest name test
|> x.addTest
f x // forward through continuation

http://fsharpforfunandprofit.com/posts/computation-expressions-intro/

https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/computation-expressions

So you can do nesting given you that have Delay and Return(Yield) defined, but it may be to noisy with your custom operations. Thank you. Good day.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.