Skip to content

Decide how to report 'unexpected' and 'actual' values in an exception #282

New issue
New issue
Open
Feature
Open
Decide how to report 'unexpected' and 'actual' values in an exception#282
Feature
Labels
component: OTAstatus: waiting-for-interesttype: enhancement
@marcphilipp

Description

@marcphilipp
marcphilipp
opened on May 24, 2016
Member

This is a follow-up on #138 where we used new AssertionFailedError(message, expected, actual) to pass expected and actual for assertEquals, assertSame, and assertNull.

However, we should consider passing unexpected and actual for

  • Assertions.assertNotEquals
    Assertions.assertNotSame (hmm... unexpected == actual in this case)
    Assertions.assertNotNull (just actual?)

Activity

marcphilipp
added
type: enhancement
component: OTA
on May 24, 2016
marcphilipp
added this to the 5.0 M2 milestone on May 24, 2016
jlink
mentioned this on May 24, 2016
sbrannen
modified the milestones: 5.0 M2, 5.0 M3 on Jul 15, 2016
sbrannen
modified the milestones: 5.0 M3, 5.0 M4 on Jul 25, 2016
jbduncan

jbduncan commented on Oct 23, 2016

@jbduncan
jbduncan
on Oct 23, 2016
Contributor

FYI, Google Truth produces IMO rather nice error messages that show how actual and expected differ to each other if they are both strings. Perhaps their error message format could be a source of inspiration for this issue.

marcphilipp
modified the milestones: 5.0 M5, 5.0 M4 on Jan 5, 2017

10 remaining items

stale

stale commented on May 13, 2021

@stale
stalebot
on May 13, 2021

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

stale
added
status: stale
on May 13, 2021
jbduncan

jbduncan commented on May 13, 2021

@jbduncan
jbduncan
on May 13, 2021
Contributor

Google Truth, AssertJ and Kotest's assertions could still be useful sources of inspiration here?

stale
removed
status: stale
on May 13, 2021
marcphilipp
removed this from the 5.x Backlog milestone on Jun 19, 2021
stale

stale commented on Jun 21, 2022

@stale
stalebot
on Jun 21, 2022

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

stale
added
status: stale
on Jun 21, 2022
jbduncan

jbduncan commented on Jul 1, 2022

@jbduncan
jbduncan
on Jul 1, 2022
Contributor

This still seems somewhat useful to me.

stale
removed
status: stale
on Jul 1, 2022
marcphilipp
added
status: waiting-for-interest
on Apr 13, 2023
marcphilipp
mentioned this on Apr 28, 2024
YongGoose
mentioned this on Apr 20, 2025
YongGoose

YongGoose commented on Apr 20, 2025

@YongGoose
YongGoose
on Apr 20, 2025 · edited by YongGoose
Contributor

@marcphilipp

Hope you're enjoying a restful Easter break. 🎉
Just dropping by as I had an idea related to this issue and wanted to share it.

Modifying the reason field could be a good solution as well, but in that issue, I proposed adding explicit support for negation context in AssertionFailedError—such as introducing a boolean flag. (for clearer field semantics expected becomes context-aware)

private static void failEqual(Object actual, Object messageOrSupplier) {
	assertionFailure() //
			.message(messageOrSupplier) //
			.actual(actual) //
			.expected(expected) //
			.isNegated(true) // new boolean flag for context-aware
			.buildAndThrow();
}

I believe this approach could offer a cleaner and more semantically accurate way to report failures in negative assertions like assertNotEquals, assertNotSame, and assertNotNull, while preserving backward compatibility.

WDYT?

YongGoose

YongGoose commented on Apr 20, 2025

@YongGoose
YongGoose
on Apr 20, 2025 · edited by YongGoose
Contributor

#282 (comment)
I believe this approach would consume more resources than modifying the reason, as it would require updating the changes in the IDE and other frameworks as well. However, from the user's perspective, the user experience would improve as they would receive a similar terminal interface (compare with assertEquals).

If the team determines that modifying the reason is more suitable than the approach I have in mind, I will come up with a solution to modify the reason accordingly. 🙂

YongGoose
mentioned this on Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component: OTAstatus: waiting-for-interesttype: enhancement

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @sbrannen@marcphilipp@jbduncan@YongGoose

        Issue actions
          Decide how to report 'unexpected' and 'actual' values in an exception · Issue #282 · junit-team/junit-framework