Skip to content

GH-2647 stack trace assertions skeleton base - #2687

Open
ascopes wants to merge 2 commits into
assertj:3.xfrom
ascopes:feature/GH-2647-stack-trace-assertions-base
Open

ascopes wants to merge 2 commits into
assertj:3.xfrom
ascopes:feature/GH-2647-stack-trace-assertions-base

Conversation

@ascopes

@ascopes ascopes commented Jun 25, 2022

Copy link
Copy Markdown
Contributor

First PR for GH-2647 to implement assertions for StackTraceElement and StackTraceElement[] types.

GH-2647: Implement skeleton for stack trace assertions.

This introduces the skeleton for two new types of
assertion/assumption:

- assertThat(StackTraceElement) - to perform assertions
  upon StackTraceElement types.
- assertThat(StackTraceElement[]) - to perform assertions
  upon StackTraceElement[] types.

Due to the new signature conflicting with one of the existing
test suites, I have implemented a temporary workaround to prevent
having to totally reimplement that class, since the new
API is not yet usable in this set of changes. I will remove
this in the second PR that implements the actual functionality.

I have also made one of the proxy methods in the API less restrictive
to allow it to work with passing array types around.

@ascopes
ascopes force-pushed the feature/GH-2647-stack-trace-assertions-base branch from 843dc2f to 6522b39 Compare June 25, 2022 15:59
@ascopes ascopes changed the title Feature/gh 2647 stack trace assertions base GH-2647 stack trace assertions skeleton base Jun 25, 2022
@ascopes
ascopes force-pushed the feature/GH-2647-stack-trace-assertions-base branch 2 times, most recently from f33734c to 7a15cd4 Compare June 29, 2022 09:53
@github-actions

Copy link
Copy Markdown
  • Surviving mutants in this change: 7
  • Killed mutants in this change: 13
class surviving killed
org.assertj.core.api.StandardSoftAssertionsProvider 2 0
org.assertj.core.api.BDDSoftAssertionsProvider 2 0
org.assertj.core.api.WithAssumptions 2 0
org.assertj.core.api.StackTraceAssert 1 0
org.assertj.core.api.WithAssertions 0 2
org.assertj.core.api.Assertions 0 2
org.assertj.core.api.AssertionsForClassTypes 0 2
org.assertj.core.api.BDDAssumptions 0 2
org.assertj.core.api.BDDAssertions 0 2
org.assertj.core.api.Assumptions 0 3

See https://pitest.org/

ascopes added 2 commits July 16, 2022 13:40
…afely

This updates the signature of three proxy-returning methods for the
assumptions conduit which enables the proxy implementations to
consume array types safely, which is needed for the next commit.

This should not be a breaking API change as the only public signature
that has changed is now less restrictive than it was previously.

Public API changes:

- SoftAssertionsProvider#proxy signature is now less
  restrictive, having changed from
    (Class<SELF> a, Class<ACTUAL> b, ACTUAL c)
  to
    (Class<SELF> a, Class<? extends ACTUAL> b, ACTUAL c).
  This allows passing array types in for parameter `b`
  correctly without unnecesarry casts.

Internal changes:

- Assumptions#asAssumption signature changed from
    (Class<ASSERTION> a, Class<ACTUAL> b, Object c)
  to
    (Class<ASSERTION> a, Class<? extends ACTUAL> b, ACTUAL c).
  This allows converting instances where b is an array
  type correctly. This also makes this class more typesafe, which
  will simplify maintainability in the future. An explicit cast
  is needed to prevent the internal arguments being ambiguous
  in intent within varargs expansion.

- SoftProxies#createSoftAssertionProxy signature changed from
    (Class<SELF> a, Class<ACTUAL> b, ACTUAL c)
  to
    (Class<SELF> a, Class<? extends ACTUAL> b, ACTUAL c).
  This allows passing in an array type for parameter `b`, which
  previously would not compile.
  (e.g. (..., StackTraceElement[].class, ex.getStackTrace());
This introduces the skeleton for two new types of
assertion/assumption:

- assertThat(StackTraceElement) - to perform assertions
  upon StackTraceElement types.
- assertThat(StackTraceElement[]) - to perform assertions
  upon StackTraceElement[] types.

Due to the new signature conflicting with one of the existing
test suites, I have implemented a temporary workaround to prevent
having to totally reimplement that class, since the new
API is not yet usable in this set of changes. I will remove
this in the second PR that implements the actual functionality.

I have also made one of the proxy methods in the API less restrictive
to allow it to work with passing array types around.
@ascopes
ascopes force-pushed the feature/GH-2647-stack-trace-assertions-base branch from b91db6b to c3fe8ca Compare July 16, 2022 12:40
@github-actions

Copy link
Copy Markdown
  • Surviving mutants in this change: 8
  • Killed mutants in this change: 12
class surviving killed
org.assertj.core.api.StandardSoftAssertionsProvider 2 0
org.assertj.core.api.BDDSoftAssertionsProvider 2 0
org.assertj.core.api.WithAssumptions 2 0
org.assertj.core.api.WithAssertions 1 1
org.assertj.core.api.StackTraceAssert 1 0
org.assertj.core.api.Assertions 0 2
org.assertj.core.api.AssertionsForClassTypes 0 2
org.assertj.core.api.BDDAssumptions 0 2
org.assertj.core.api.BDDAssertions 0 2
org.assertj.core.api.Assumptions 0 3

See https://pitest.org/

@ascopes

ascopes commented Dec 23, 2023

Copy link
Copy Markdown
Contributor Author

hey, is there any update on this?

@joel-costigliola

joel-costigliola commented Dec 24, 2023 •

Copy link
Copy Markdown
Member

@ascopes nope, sorry, a bit too busy on our side. We'll plan this one for the next release (either 4.0 or 2.26.0)

Could you rebase on main to solve the conflicts.

@scordio scordio added this to the 3.27.0 milestone Apr 9, 2024
@scordio
scordio force-pushed the 3.x branch 2 times, most recently from 301ca01 to c730d18 Compare June 1, 2024 16:04
@scordio scordio modified the milestones: 3.27.0, 3.28.0 Nov 25, 2024
@scordio scordio modified the milestones: 3.28.0, 4.0.0-M1 Jan 3, 2025
@scordio scordio modified the milestones: 4.0.0-M1, 4.0.0-M2 Jan 31, 2025
@joel-costigliola joel-costigliola modified the milestones: 4.0.0-M2, 4.x Jul 5, 2026

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants