Spring Support multiple matchers in MockMvc Kotlin DSL

Affects: 5.2.1.RELEASE

I would expect that in a DSL everything in a lambda block will be executed. But if i try to assert multiple matchers in the model block only the last one will be executed. I didn't get any feedback about this behaviour, so i get the false impression that my code is executed, if it isn't.

Doesn't work like expected:

mockMvc.get(url)
  .andExpect {
    model {
      attribute("foo", "foo")
      attribute("bar", "bar")
    }
}

Works, but is redundant code:

mockMvc.get(url)
  .andExpect {
    model { attribute("foo", "foo") }
    model { attribute("bar", "bar") }
}

Comment From: sdeleuze

I can understand how it could be confusing, but here we are reusing the ModelResultMatchers Java API:

fun model(matcher: ModelResultMatchers.() -> ResultMatcher) {
    actions.andExpect(MockMvcResultMatchers.model().matcher())
}

One way of supporting your use case would be to create a ModelResultMatchersDsl that would support multiple matchers.

Any thoughts @checketts @jnizet?

Comment From: checketts

I absolutely want a ModelResultMatchersDsl (and would even be interested in implementing it).

I'll be converting my tests over from the kd4smt to this new DSL and I suspect I'll run into these sorts of issues.

Comment From: sdeleuze

@checketts Do you want to provide a PR? @jnizet Any thoughts?

Comment From: jnizet

@sdeleuze I haven't been using the DSL in a while, and I've never been hit by this issue myself but I agree that the current situation is confusing, and that a ModelResultMatchersDsl would be nice.

Comment From: sdeleuze

@devtribe Thanks for raising this important issue, I think it is now properly fixed.

Comment From: LifeIsStrange

@sdeleuze while this seems like an important fix, I really miss the property access syntax of isOk, etc. is'nt there a way to undo this breaking change just for the status { } block? From my understanding (I might be wrong) the status block is always intended to only have only one statement, therefore being unaffected by this issue, but still, the fix has a side effect on this block. could the previous way be used specifically for the status block so that we could have the best of both worlds?