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

[sbrannen]

Analysis

Declaring methods like the one proposed in this issue's description only works if the methods are declared locally as in the following example.

class MixedBoxedAndUnboxedPrimitivesTests {

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

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

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

	@Test
	void bytes() {
		assertEquals((byte) 42, Byte.valueOf("42"));
	}

	@Test
	void shorts() {
		assertEquals((short) 42, Short.valueOf("42"));
	}

	@Test
	void integers() {
		assertEquals(42, Integer.valueOf("42"));
	}

	@Test
	void longs() {
		assertEquals(42L, Long.valueOf("42"));
	}

	@Test
	void floats() {
		assertEquals(42.0f, Float.valueOf("42.0"));
	}

	@Test
	void doubles() {
		assertEquals(42.0d, Double.valueOf("42.0"));
	}

	@Test
	void booleans() {
		assertEquals(false, Boolean.valueOf("false"));
	}

	@Test
	void chars() {
		assertEquals('a', Character.valueOf('a'));
	}

}

Declaring those same methods as static in Assertions does not remove the ambiguity for the compiler. 😞

[sbrannen]

This has been addressed in master in 0ec5a7b and 382e9ea.