Hi, new to strikt, I guess there must be a more el...

# strikt

[Pihentagy]

Hi, new to strikt, I guess there must be a more elegant way to say:

expectThat(result) {
            get { statusCode }.isEqualTo(HttpStatus.OK)
            get { body }.isNotNull().and {
                get { elements }.and {
                    hasSize(1)
                    expectThat(first().subject) {
                        get { coordinates }.isEqualTo(listOf(coord))
                        get { networkType }.isEqualTo(NetworkType.SWITCH)
                    }
                }
            }
        }

[Saharath Kleips]

I’m not a pro, but it looks like you have basically the gist of it, but there are a couple of comments.
• The StriKT docs suggest preferring to use `get` with function references: So get(HttpResponse::statusCode).isEqualTo(…) over get { statusCode }. In my experience needing the lambda version is an edge case.
• You probably should be using that(first().subject) rather than expectThat but to me it’s probably another get ?
• StriKT also has functions for asserting collections: So I’d probably write some variation of get(Subject::coordinates).containsExactlyInAnyOrder(coord)
I think in general, StriKT lets you write these assertions in a way that makes the output of a test result become immediately clear and specific as to what failed. So, I wouldn’t say any of it is necessarily wrong (the assertions still ultimately work) but reading the result of a failure could be improved.

[robfletcher]

A couple of things you could do to simplify:

expectThat(result) {
  get { statusCode }.isEqualTo(HttpStatus.OK)
  get { body }
    .isNotNull().get { elements }
    .hasSize(1)
    .withFirst {
      get { coordinates }.isEqualTo(listOf(coord))
      get { networkType }.isEqualTo(NetworkType.SWITCH)
    }
}

You shouldn’t nest an expect method inside another one. Unfortunately there’s not really a way for me to prevent that, but it can create unpredictable results.

The and method is for grouping multiple assertions and there are a couple of places where you only really have one thing inside of it, so it’s not necessary.

[robfletcher]

also, the earlier point about function references is valid. They perform a bit better (due to the way the failure message is generated with just a closure) but that’s only really a concern with very large numbers of tests, e.g. when doing generative tests

[Eric]

What about single() instead of hasSize(1).withFirst { ... }?

[robfletcher]

oh, I think I missed navigating to .subject there, but hopefully you get the idea

[robfletcher]

yeah, single is basically hasSize(1).first(). I went for withFirst in order to group the 2 assertions on that element

[Pihentagy]

Cool, thanks, learned a lot about strikt about these comments

[Pihentagy]

I find get with closure readable and I don't mind the little performance loss (yet).

[Pihentagy]

What about changing

.hasSize(1).withFirst() { ... }

to

.single().and() { ... }

Shouldn't be a single version with blocks, so that I can write:

.single() { ... }

[robfletcher]

we could add a withSingle { } yeah

[robfletcher]

(which would effectively just be .single().and { } as you say)

[Pihentagy]

Nice, thanks!