https://kotlinlang.org logo
Channels
Powered by
#strikt
  • r

    robfletcher

    10/02/2018, 9:56 PM
    Copy code
    expectThat(person) {
  lastName == "Bowie"
}
  • r

    robfletcher

    10/02/2018, 9:57 PM
    would not give you a very good error message, for example
  • r

    robfletcher

    10/02/2018, 9:57 PM
    (out of the box)
  • r

    robfletcher

    10/02/2018, 9:57 PM
    reminds me a lot of Spock
  • r

    robfletcher

    10/02/2018, 9:57 PM
    (but that does have diagrammed assertions)
  • c

    christophsturm

    10/02/2018, 9:58 PM
    its an evolution of my assertion lib prototype https://github.com/christophsturm/asserto that has syntax like 
    expect(that(userId).equals("12"))
  • c

    christophsturm

    10/02/2018, 9:59 PM
    it just never occured to me that 
    expectThat(userId) {equals("12")}
    is better
  • r

    robfletcher

    10/02/2018, 9:59 PM
    The interesting thing you can do with a closure like that is scope extension methods on any type
  • c

    christophsturm

    10/02/2018, 10:00 PM
    with the file peeking you would get expected that 
    lastName == "bowie" is true
    which is maybe not super nice but useful
  • r

    robfletcher

    10/02/2018, 10:00 PM
    i.e. apply assertion extension functions to regular types
  • r

    robfletcher

    10/02/2018, 10:00 PM
    Copy code
    expectThat(person) {
  lastName.isEqualTo("Bowie")
}
  • r

    robfletcher

    10/02/2018, 10:01 PM
    should (I think) be possible
  • r

    robfletcher

    10/02/2018, 10:01 PM
    if the receiver of the closure exposes an extension method 
    isEqualTo
    on 
    String
    (or 
    Any
    )
  • c

    christophsturm

    10/02/2018, 10:02 PM
    that would be pretty cool!
  • r

    robfletcher

    10/02/2018, 10:02 PM
    it’s somewhat like HamKrest’s syntax at that point
  • r

    robfletcher

    10/02/2018, 10:02 PM
    it would break chained assertions, of course (or require everything to be implemented twice)
  • r

    robfletcher

    10/02/2018, 10:03 PM
    but you’d no longer need 
    chain
    , 
    map
    , etc.
  • c

    christophsturm

    10/02/2018, 10:05 PM
    i didn’t like hamkrest so much, it felt like having to jump through many hoops just to make the assertion lib happy
  • r

    robfletcher

    10/02/2018, 10:06 PM
    Hmm, one other thing you’d lose would be the ability to create matcher functions as extensions
  • r

    robfletcher

    10/02/2018, 10:07 PM
    That’s not good
  • r

    robfletcher

    10/02/2018, 10:07 PM
    hence HamKrest’s approach with a generic 
    shouldMatch
    method that accepts a matcher impl
  • c

    christophsturm

    10/02/2018, 10:10 PM
    maybe just do the boolean support for now?
  • c

    christophsturm

    10/02/2018, 10:11 PM
    what about 
    get
    instead of 
    chain
    ?
    Copy code
    expectThat(person) {
  get{lastName}.isEqualTo("Bowie")
}
  • r

    robfletcher

    10/02/2018, 10:11 PM
    oh
  • r

    robfletcher

    10/02/2018, 10:11 PM
    why the hell didn’t I think of that?
  • r

    robfletcher

    10/02/2018, 10:11 PM
    that’s way better
  • r

    robfletcher

    10/02/2018, 10:12 PM
    yes, 100% yes
  • c

    christophsturm

    10/02/2018, 10:13 PM
    its maybe even better than map.
  • r

    robfletcher

    10/02/2018, 10:16 PM
    it is
  • c

    christophsturm

    10/02/2018, 10:17 PM
    in hindsight it seems simple and obvious
1...272829...52Latest