Skip to content

test: stop asserting exception messages in EmailToken and TokenService tests - #8103

Open
maia-andre wants to merge 1 commit into
LibreSign:mainfrom
maia-andre:test/8053-exception-message-assertions
Open

test: stop asserting exception messages in EmailToken and TokenService tests#8103
maia-andre wants to merge 1 commit into
LibreSign:mainfrom
maia-andre:test/8053-exception-message-assertions

Conversation

@maia-andre

Copy link
Copy Markdown
Contributor

Pull Request Description

Follow-up to #8092, addressing the review comments there: the tests added in that PR asserted on exception messages ('Invalid code.' and 'App Two-Factor Gateway is not enabled.'), which couples them to translatable/easily mutable text.

This drops the three expectExceptionMessage() calls and keeps the exception class assertions, which are enough to distinguish the mutants killed in #8092:

  • TokenServiceTest: without ensureAvailable() the flow reaches isGatewayComplete() and throws OCSForbiddenException, which is not a LibresignException.
  • EmailTokenTest: the scenarios still rely on the hasher outcome plus the exception class.

Infection on both source files (--testsuite=unit): 29 mutants, 0 escaped, Covered Code MSI 100%.

The pre-existing assertion on 'Gateway sms not configured on Two-Factor Gateway.' was kept: it checks that the gateway name is interpolated into the message, which is behavior rather than wording. The broader question of how to assert exceptions across the suite (exception codes vs. typed subclasses) is being discussed in #8092.

Backport notes: applies cleanly to stable35 (once #8102 is merged). Not applicable to stable32–34 — TokenServiceTest.php does not exist there.

Related Issue

Ref #8053

Pull Request Type

  • Test

Pull request checklist

  • Tests pass locally (PHPUnit + Infection)
  • AI-assisted: yes (see commit trailer)

…e tests

Follow-up to LibreSign#8092. The review pointed out that asserting on translatable
or easily mutable text couples the tests to strings that may be changed
for non-technical reasons, forcing whoever edits the message to know the
test must change too.

Drop the three expectExceptionMessage() calls added in LibreSign#8092 and keep the
exception class assertions. They are enough to distinguish the mutants:
without ensureAvailable() the flow in TokenService reaches
isGatewayComplete() and throws OCSForbiddenException instead of
LibresignException, and the EmailToken scenarios still rely on the hasher
outcome plus the exception class. Infection on both source files keeps
Covered Code MSI at 100% (29 mutants, 0 escaped).

Ref LibreSign#8053

Assisted-by: Claude Code:claude-fable-5
Signed-off-by: André Maia <andrefnkmm@gmail.com>
$instance->setCodeSentByUser('654321');

$this->expectException(LibresignException::class);
$this->expectExceptionMessage('Invalid code.');

@vitormattos vitormattos Aug 28, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does you think about add an error code to this exception?

With an error code we can confirm that is the expected error without matching the text.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed — I'll add a code so the tests assert expectExceptionCode() instead of the text. Two quick questions before I push:

  1. Should the code follow the "HTTP-like plus one digit" pattern you mentioned (e.g. 4010 for the invalid verification code and 5030 for "Two-Factor Gateway not enabled"), and would you like them as constants, like JSActions?
  2. I'd apply it to both exceptions touched by this PR, unless you prefer only Invalid code. for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 0. Backlog

Development

Successfully merging this pull request may close these issues.

2 participants