https://kotlinlang.org logo
Channels
Powered by
#spek
  • i

    iamsteveholmes

    11/05/2015, 6:53 PM
    I'm using chai and mocha in my day job. I like the syntax but find it a bit long.
  • i

    iamsteveholmes

    11/05/2015, 6:54 PM
    And it would be nice to create flexible, type safe and extensible descriptors.
  • h

    hastebrot

    11/05/2015, 6:54 PM
    I use Hamcrest-style assertions (
    assertThat(value, matcher
    ) a lot and find it a bit cumbersome to import all these matchers. Also auto-complete is not so nice with Hamcrest.
  • i

    iamsteveholmes

    11/05/2015, 6:54 PM
    To be honest I prefer spock
  • i

    iamsteveholmes

    11/05/2015, 6:55 PM
    Although I love wrapping descriptions within descriptions
  • h

    hastebrot

    11/05/2015, 6:56 PM
    Yeah, Spock's power assertions are very nice, but also have their limits. That' s why Spock also supports Hamcrest matchers.
  • h

    hastebrot

    11/05/2015, 6:57 PM
    Maybe Kotlin's extension functions could make a big difference here.
  • o

    orangy

    11/05/2015, 7:02 PM
    @hastebrot: so you basically want to replace given/on with more generic “describe” and allow for arbitrary depth hierarchies, and then bind to given/on with just shortcut functions?
  • h

    hastebrot

    11/05/2015, 7:02 PM
    @orangy: yes
  • o

    orangy

    11/05/2015, 7:03 PM
    How would you ensure the structure, i.e. that I have 
    on
    inside 
    given
    and not just top-level 
    on
    and then inside it 
    on
    again, etc?
  • o

    orangy

    11/05/2015, 7:04 PM
    but well, some kind of wrapper types could help, yes
  • h

    hastebrot

    11/05/2015, 7:05 PM
    the tree structure would allow arbitrary hierarchies. but the DSL classes would prevent calling 
    on()
    in an 
    OnSpecContext
    (or whatever this could be named).
  • o

    orangy

    11/05/2015, 7:05 PM
    But then, all the issues I’ve outlined above are no-problem for you?
  • o

    orangy

    11/05/2015, 7:06 PM
    but I see, mocha.js has all the same issues
  • o

    orangy

    11/05/2015, 7:08 PM
    apparently nobody cares and use beforeEach/afterEach to setup/cleanup simple smile
  • h

    hastebrot

    11/05/2015, 7:08 PM
    the memory issues require more thoughts. I don't know if there is a good way. maybe it could traverse the whole spec definition tree, remove lambdas and retrieve them on demand later. I don't know
  • h

    hastebrot

    11/05/2015, 7:11 PM
    I don't understand the side-effects issues you mentioned.
  • h

    hastebrot

    11/05/2015, 7:24 PM
    Don't know how good are JUnit's report capabilities in regard of hierarchical test structures. IDEA (at least version 15) already has sufficient support to display JUnit tests as hierarchies. I know it took quite some work to implement spock-reports. So a clean API to traverse test hierarchies would be very nice.
  • h

    hastebrot

    11/05/2015, 7:26 PM
    It could be very nice if we could compile test code and test results into dokka documentations. I saw some frameworks in .NET that supports this.
  • o

    orangy

    11/05/2015, 7:30 PM
    with dokka, you can inline method (test) body, though not results. Why results? They should all pass before you deploy 😉
  • h

    hastebrot

    11/05/2015, 7:31 PM
    oh, that's nice. yepp, results should better be placed into the test report and not API documentation, that's right.
  • o

    orangy

    11/05/2015, 7:40 PM
    I don't understand the side-effects issues you mentioned.
    when evaluating hierarchy you have to execute lambdas, so that you get nested “describe” calls, and since they are just lambdas, they could establish some shared state:
    Copy code
    describe(“a") {
  val db = connect()
  describe(“b”) { … use db … } 
  describe(“c”) { … use db … }   
}
    As soon as you execute describe(“a”), you get “db” captured in lambdas for b & c, which keeps connection, etc
  • o

    orangy

    11/05/2015, 7:41 PM
    if we had lazy local vars, we could do something like this:
  • o

    orangy

    11/05/2015, 7:41 PM
    val db by lazy { connect() }
  • o

    orangy

    11/05/2015, 7:41 PM
    but we don't
  • h

    hastebrot

    11/05/2015, 7:43 PM
    that's nasty
  • o

    orangy

    11/05/2015, 7:44 PM
    same problem with mocha.js, though
  • o

    orangy

    11/05/2015, 7:46 PM
    in JS, theoretically, we could have something like
    Copy code
    context(function () {
   db = connect()
})
    and through this-substitution and using dynamic nature of JS make 
    db
    available in nested describes, resetting it before each call
  • o

    orangy

    11/05/2015, 7:46 PM
    in Kotlin not so much
  • h

    hastebrot

    11/05/2015, 8:01 PM
    Copy code
    class ConcreteSpec : AbstractSpec({
    describe("compare numbers") {
        beforeEach {
            context["other"] = 12
        }

        it("should not be equal") {
            assert(14 != context["other"])
        }
    }
})
    We could use 
    beforeEach()
    , but this makes problems with scoped values. A hashmap like 
    context["other"]
    in the above code doesn't make it better.
1...101112...112Latest