You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While writing tests for issue #3853, I noticed that there are duplicates code in the test cases for the Expect functionality. For example, the following test cases share repetitive code fragments:
@TestvoidthrowsCorrectErrorForNewSizeAttrNaN() {
MatcherAssert.assertThat(
"the message in the error is correct",
Assertions.assertThrows(
ExAbstract.class,
() -> newDataized(
newPhWith(
newEOmallocTest.PhiWithIdDummy(
newEOmalloc$EOof$EOallocated$EOresized()
).it(),
"new-size",
newData.ToPhi(true)
)
).take(),
"put TRUE in int attr fails with a proper message that explains what happened"
).getMessage(),
Matchers.equalTo("the 'new-size' attribute must be a number")
);
}
@TestvoidthrowsCorrectErrorForNewSizeAttrNotAnInt() {
MatcherAssert.assertThat(
"the message in the error is correct",
Assertions.assertThrows(
ExAbstract.class,
() -> newDataized(
newPhWith(
newEOmallocTest.PhiWithIdDummy(
newEOmalloc$EOof$EOallocated$EOresized()
).it(),
"new-size",
newData.ToPhi(42.42)
)
).take(),
"put double in int attr fails with a proper message that explains what happened"
).getMessage(),
Matchers.equalTo("the 'new-size' attribute (42.42) must be an integer")
);
}
@TestvoidthrowsCorrectErrorForNewSizeAttrNotNatural() {
MatcherAssert.assertThat(
"the message in the error is correct",
Assertions.assertThrows(
ExAbstract.class,
() -> newDataized(
newPhWith(
newEOmallocTest.PhiWithIdDummy(
newEOmalloc$EOof$EOallocated$EOresized()
).it(),
"new-size",
newData.ToPhi(-42)
)
).take(),
"put negative int in natural attr fails with a proper message that explains what happened"
).getMessage(),
Matchers.equalTo("the 'new-size' attribute (-42) must be greater or equal to zero")
);
}
These tests share a common structure and could be refactored to reduce duplication and improve maintainability.
I propose to depelop classes for testing Expect.Number, Expect.IntExpect.Natural in ExpectTest.java. For example:
/** * Test that dataization of Phi throws an error about an incorrect attribute which must use {@link Expect.Number}. * * @since 0.51 */publicstaticfinalclassNumber {
privatefinalPhiphi;
/** * Constructor. * @param phi The Phi object for dataization */publicNumber(Phiphi) {
this.phi = phi;
}
/** * Perform the test. */publicvoidit() {
MatcherAssert.assertThat(
"the message in the error is correct",
Assertions.assertThrows(
ExAbstract.class,
() -> newDataized(phi).take(),
"fails with correct error message while transforming Phi to Number"
).getMessage(),
Matchers.matchesRegex(".*the '.*' attribute must be a number.*")
);
}
}
@maxonfjvipon I'm not yet sure. It seems that extra validation inside atoms will only make error messages more interesting, not anyhow contradicting with the public contracts of them. With the presence of Except we don't make any false promises to users. It's just to make testing more fun: atoms still fails if inputs are broken, but they fail with nicer messages.
Safe decorators is a different story -- they are visible to users and we definitely need them.
While writing tests for issue #3853, I noticed that there are duplicates code in the test cases for the
Expect
functionality. For example, the following test cases share repetitive code fragments:These tests share a common structure and could be refactored to reduce duplication and improve maintainability.
I propose to depelop classes for testing
Expect.Number
,Expect.Int
Expect.Natural
inExpectTest.java
. For example:So upper test will look:
@yegor256 What do you think?
Ref: #3461
The text was updated successfully, but these errors were encountered: