Support mixed boxed and unboxed primitives in assertEquals() & assertNotEquals()

[ridono]

Overview

Asserting that an int equals an Integer is not possible with assertEquals() due to the compiler not knowing if it should use assertEquals(int, int) or assertEquals(Object, Object).

This results in the compile error The method assertEquals(int, int) is ambiguous for the type Assertions like in the following example:

	@Test
	void test_parseYear() throws Exception {
		Integer parsedYear = SeparateDateParser.parseYear("2014");
		Assertions.assertEquals(2014, parsedYear); // does not compile
	}

Instead you either have to declare another variable:

	@Test
	void test_parseYear() throws Exception {
		Integer parsedYear = SeparateDateParser.parseYear("2014");
		Integer expectedYear = 2014;
		Assertions.assertEquals(expectedYear, parsedYear);
	}

or use a custom assertion method:

	void assertEquals(Number expected, Number actual) {
		Assertions.assertEquals(expected, actual);
	}

We have already encapsulated this method in a utility class to reuse it in our projects, but as this is a quite common case it would be nice if the framework could provide an assertEquals() method like the one above.

Related Issues

• Introduce support for assertNotEquals for primitive data types #1607

Deliverables

• Support mixed boxed and unboxed primitives in assertEquals()
• Support mixed boxed and unboxed primitives in assertNotEquals()
• Document in Release Notes

[sbrannen]

I agree that that is a bit of a nuisance.

Note that the following is a workaround I often use:

@Test
void test_parseYear() throws Exception {
	Integer parsedYear = Integer.valueOf(2014);
	Assertions.assertEquals(2014, parsedYear.intValue());
}

[sbrannen]

I agree that that is a bit of a nuisance.

Coming back to that...

I suppose this nuisance exists not only for numbers but rather for all primitive types when asserting equality between a primitive and its wrapper type.

So perhaps we should investigate a solution for all such cases.

@junit-team/junit-lambda, thoughts?

[sbrannen]

Tentatively slated for 5.4 M1 for team discussion.

[sbrannen]

Actually, now that I've thought about it...

Along the same lines, the changes in #1607 are breaking changes.

Specifically, the following compiles against Jupiter 5.3.1 but does not compile against master (which contains the changes in #1607).

@Test
void parseYear() {
	Integer parsedYear = Integer.valueOf("2014");
	assertNotEquals(2014, parsedYear);
}

Thus, in order to fix the breaking changes introduced in #1607, we will have to introduce methods that allow the compiler to properly pick the correct assertion method for a combination of boxed and unboxed values.

And... since we have to do that for assertNotEquals(), we should do the same for assertEquals() (as raised in this GitHub issue) for consistency.

I am therefore removing the "team discussion" label.

[sbrannen]

in progress