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)
                    }
                }
            }
        }

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.

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.

What about

single()

instead of

hasSize(1).withFirst { ... }

?

oh, I think I missed navigating to

.subject

there, but hopefully you get the idea

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

we could add a

withSingle { }

yeah

Nice, thanks!