Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: complete AbstractAssert.as...() methods #1020

Closed
tkruse opened this issue Jun 26, 2017 · 7 comments
Closed

Idea: complete AbstractAssert.as...() methods #1020

tkruse opened this issue Jun 26, 2017 · 7 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@tkruse
Copy link
Contributor

tkruse commented Jun 26, 2017

Hi,
just an idea, similar to AbstractAssert.asList(), AbstractAssert could have asOptional, asMap, ... returning the respective specialized Assertions instance.

I think this is particularly useful in combination with .extracting()

@tkruse
Copy link
Contributor Author

tkruse commented Jun 26, 2017

Also, I wonder if asList() could be extended to take a class as argument like:

assertThat(listAsObject).asList(Integer.class).allMatch(v -> v > 10);

@joel-costigliola
Copy link
Member

joel-costigliola commented Jun 27, 2017

asList(Class) is something we can do but I'm worried adding all the other ones will clutter the API, especially if code completion shows assertion alphabetically, users will have to scroll after all asXXX methods to discover the API.

I'm ok to add the main ones as a per request basis (for example I would not add asBoolean )

I'm saying (more or less) the same thing in #167 (comment)

@jonfreedman
Copy link

How about changing the isInstanceOf & isExactlyInstanceOf signatures to cast?

@oliverlockwood
Copy link

Plus one to asMap().

@joel-costigliola
Copy link
Member

joel-costigliola commented May 16, 2019

I believe you have been heard in #1498 ;-)

@scordio
Copy link
Member

scordio commented Aug 18, 2019

Hi @tkruse, could you check if asInstanceOf satisfies your requirements?

@tkruse
Copy link
Contributor Author

tkruse commented Aug 18, 2019

yes, seems this can be closed.

@tkruse tkruse closed this as completed Aug 18, 2019
@scordio scordio closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2024
@scordio scordio added the status: declined A suggestion or change that we don't feel we should currently apply label Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants