Custom assertions use primitive comparison, not assertions
@scordio ci sta già lavorando.
Dal 10/10/2023.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
https://assertj.github.io/doc/#assertj-core-custom-assertions-creation shows how to create custom assertion classes. One part that I find very confusing is this piece of code in the custom hasName assertion implementation:
// check assertion logic
if (!Objects.equals(actual.getName(), name)) {
failWithMessage("Expected character's name to be <%s> but was <%s>", name, actual.getName());
}
I would expect to reuse existing String assertions there, e.g. to write this instead:
// check assertion logic
Assertions.assertThat(actual.getName)
.withFailMessage(() -> "Expected character's name to be <%s> but was <%s>", name, actual.getName())
.isEqualTo(name);
Is there a good reason to not use other existing assertions there (like confusing the logic to shorten stack traces or similar internal things)? If yes, can we please document it? Otherwise, shouldn't we change the example code?
I typically do use existing assertions in my own assertions, and I have this nagging feeling of doing something wrong without knowing what exactly. :)
- Lingua principale
- CSS
- Stelle
- 26
- Fork
- 32
- Merge medio
- 1g 19h
- PR unite (30g)
- 4
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di assertj/doc
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 52/100