Support AssertJ variant in MockMvc [SPR-16637]

[spring-projects-issues]

Brian Clozel opened SPR-16637 and commented

This Spring Boot issue shows that many developers would like to use AssertJ-style assertions with MockMvc. This would also be a nice complement to the existing Kotlin support, since Kotlin users seem to favor this style of assertions.

The linked Spring Boot issue contains a fairly advanced branch with a working prototype.

---

Reference URL: spring-projects/spring-boot#5729

8 votes, 12 watchers

[ngeor]

I've put together a library that offers AssertJ assertions for MockMvc but also for ResponseEntity (returned by TestRestTemplate): https://github.com/ngeor/yak4j-spring-test-utils

[manueljordan]

I have read the comments in the other post (about SB), why not work around two branches? One for Hamcrest (Keeping the current available approach) and the other one for AssertJ ... Sadly Hamcrest is very verbose to test data about returned data either in XML or JSON.

[manueljordan]

Hello @sbrannen here for your consideration. Thanks for your understanding

[cassiomolin]

+1
Support for AssertJ assertions would be great!

[sbrannen]

I've been thinking about this, and I'm not sure that we need to add explicit support for AssertJ in order to allow people to choose to use AssertJ, Truth, or any other assertion framework.

For example, if we introduce generic "consumer" support (as in Consumer<T>), we might be able to do something like the following.

mockMvc.perform(get("/users"))
    .andExpect(model().attribute("userList", List.class),
        list -> assertThat(list).hasSize(2)));

• That attribute() method would have a signature like <T> T attribute(String name, Class<T> requiredType).
• That andExpect() method would have a signature like andExpect(T object, Consumer<T> consumer). Though perhaps something like andConsume() would make more sense for such a use case.
• assertThat(list) is from AssertJ in this example.

[sbrannen]

A quick local spike with the following new method in ModelResultMatchers...

public <T> ResultMatcher attribute(String name, Class<T> requiredType, Consumer<T> valueConsumer) {
	return result -> {
		ModelAndView mav = getModelAndView(result);
		T value = (T) ClassUtils.resolvePrimitiveIfNecessary(requiredType).cast(mav.getModel().get(name));
		valueConsumer.accept(value);
	};
}

... results in the following working test case, modified from Spring's test suite.

@Test
public void testAttributeEqualTo() throws Exception {
	mockMvc.perform(get("/"))
		// Hamcrest
		.andExpect(model().attribute("integer", equalTo(3)))
		// AssertJ
		.andExpect(model().attribute("integer", int.class, num -> assertThat(num).isEqualTo(3)));
}

The "consumer" variant is obviously considerably more verbose, but it shows that it's possible to provide such generic functionality with the current building blocks in MockMvc.

[philwebb]

That's good to know we could provide hooks. One of the more annoying aspects of trying to create this type of assertion is that you really need to expose AssertProvider in your API. There's no easy way I found of making mockMvc directly assertable. In my earlier spike I ended up creating a new MvcTester class that was AssertJ specific. That makes the tests look nice but means it wont work without AssertJ on the classpath.

[sbrannen]

That makes the tests look nice but means it wont work without AssertJ on the classpath.

Indeed, it does look nice: fluent!

But I agree that forcing people to have AssertJ on the classpath is a major drawback. So, if we do anything AssertJ-specific, we should do our best to ensure that AssertJ remains an optional dependency.

[123Haynes]

@philwebb would it be possible to use a wrapper class that checks if AssertJ is available on the classpath and if not, falls back to hamcrest? That way AssertJ could remain optional.

Something like https://stackoverflow.com/questions/11432212/java-class-with-possibly-missing-run-time-dependencies

[sbrannen]

would it be possible to use a wrapper class that checks if AssertJ is available on the classpath and if not, falls back to hamcrest?

I'm not sure what you mean by falling back to Hamcrest.

The Hamcrest and AssertJ APIs are not compatible. So any explicit support for AssertJ would have to be in addition to the existing Hamcrest support.

[123Haynes]

I'm not sure what you mean by falling back to Hamcrest.

The Hamcrest and AssertJ APIs are not compatible. So any explicit support for AssertJ would have to be in addition to the existing Hamcrest support.

Sorry. Wrong wording. I was just trying to propose a possible solution that would keep AssertJ optional.