/**
* Copyright (C) 2022 by Martin Robillard. See https://codesample.info/about.html
*/
package e2.chapter5;
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
public class AbsTest {
void () {
(5, Math.abs(5));
}
@Test
void testAbs_Negative() {
assertEquals(5, Math.abs(-5));
}
@Test
void testAbs_Max() {
// This test will fail.
assertEquals(Integer.MAX_VALUE, Math.abs(Integer.MIN_VALUE));
}
}
A Java annotation is a structured piece of meta-data that can be read and used by compilers and other tools.
A Java annotation is a structured piece of meta-data that can be read and used by compilers and other tools.
A common naming convention for unit tests is to start with name with test
, followed by the name of the method under test,
an underscore, and some description of the input values or state.
A common naming convention for unit tests is to start with name with test
, followed by the name of the method under test,
an underscore, and some description of the input values or state.
A statement formed of an expression that follows the Java reserved word assert
.
A statement formed of an expression that follows the Java reserved word assert
.
The Unit Under Test: typically the method we are testing, although the unit could be something other than a method (for example, an entire class).
The Unit Under Test: typically the method we are testing, although the unit could be something other than a method (for example, an entire class).
The @Test
is what flags this method as a unit test. The
method must return void
.
@Test
is used to signal that the annotated method is a test method.
The @Test
is what flags this method as a unit test. The
method must return void
.
@Test
is used to signal that the annotated method is a test method.
@Test
methods must not be private
or static
and must not return a value.
@Test
methods may optionally declare parameters to be resolved by ParameterResolvers
.
@Test
may also be used as a meta-annotation in order to create a custom composed annotation that inherits the semantics of @Test
.
@Test
methods are inherited from superclasses as long as they are not overridden according to the visibility rules of the Java language. Similarly, @Test
methods declared as interface default methods are inherited as long as they are not overridden.
By default, test methods will be ordered using an algorithm that is deterministic but intentionally nonobvious. This ensures that subsequent runs of a test suite execute test methods in the same order, thereby allowing for repeatable builds. In this context, a test method is any instance method that is directly annotated or meta-annotated with @Test
, @RepeatedTest
, @ParameterizedTest
, @TestFactory
, or @TestTemplate
.
Although true unit tests typically should not rely on the order in which they are executed, there are times when it is necessary to enforce a specific test method execution order — for example, when writing integration tests or functional tests where the sequence of the tests is important, especially in conjunction with @TestInstance(Lifecycle.PER_CLASS)
.
To control the order in which test methods are executed, annotate your test class or test interface with @TestMethodOrder
and specify the desired MethodOrderer
implementation.
This is a call to an assertion method, not to be confused with an . Assertion methods are defined in the JUnit library and automate the comparison of an oracle with the result of the execution of a .
expected
and actual
are equal.
This is a call to an assertion method, not to be confused with an . Assertion methods are defined in the JUnit library and automate the comparison of an oracle with the result of the execution of a .
Chapter 5, insight #1
Every unit test includes the execution of unit under test (UUT), some input data passed to the UUT, an oracle that describes what the result of executing the UUT should be, and one or more assertions that compare the result of the execution with the oracle
Chapter 5, insight #1
Every unit test includes the execution of unit under test (UUT), some input data passed to the UUT, an oracle that describes what the result of executing the UUT should be, and one or more assertions that compare the result of the execution with the oracle
Math
contains methods for performing basic numeric operations such as the elementary exponential, logarithm, square root, and trigonometric functions.
Math
contains methods for performing basic numeric operations such as the elementary exponential, logarithm, square root, and trigonometric functions.
Unlike some of the numeric methods of class StrictMath
, all implementations of the equivalent functions of class Math
are not defined to return the bit-for-bit same results. This relaxation permits better-performing implementations where strict reproducibility is not required.
By default many of the Math
methods simply call the equivalent method in StrictMath
for their implementation. Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available, to provide higher-performance implementations of Math
methods. Such higher-performance implementations still must conform to the specification for Math
.
The quality of implementation specifications concern two properties, accuracy of the returned result and monotonicity of the method. Accuracy of the floating-point Math
methods is measured in terms of ulps, units in the last place. For a given floating-point format, an ulp of a specific real number value is the distance between the two floating-point values bracketing that numerical value. When discussing the accuracy of a method as a whole rather than at a specific argument, the number of ulps cited is for the worst-case error at any argument. If a method always has an error less than 0.5 ulps, the method always returns the floating-point number nearest the exact result; such a method is correctly rounded. A correctly rounded method is generally the best a floating-point approximation can be; however, it is impractical for many floating-point methods to be correctly rounded. Instead, for the Math
class, a larger error bound of 1 or 2 ulps is allowed for certain methods. Informally, with a 1 ulp error bound, when the exact result is a representable number, the exact result should be returned as the computed result; otherwise, either of the two floating-point values which bracket the exact result may be returned. For exact results large in magnitude, one of the endpoints of the bracket may be infinite. Besides accuracy at individual arguments, maintaining proper relations between the method at different arguments is also important. Therefore, most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements.
The platform uses signed two's complement integer arithmetic with int and long primitive types. The developer should choose the primitive type to ensure that arithmetic operations consistently produce correct results, which in some cases means the operations will not overflow the range of values of the computation. The best practice is to choose the primitive type and algorithm to avoid overflow. In cases where the size is int
or long
and overflow errors need to be detected, the methods whose names end with Exact
throw an ArithmeticException
when the results overflow.
sin
, cos
, tan
, asin
, acos
, atan
, exp
, expm1
, log
, log10
, log1p
, sinh
, cosh
, tanh
, hypot
, and pow
. (The sqrt
operation is a required part of IEEE 754 from a different section of the standard.) The special case behavior of the recommended operations generally follows the guidance of the IEEE 754 standard. However, the pow
method defines different behavior for some arguments, as noted in its specification. The IEEE 754 standard defines its operations to be correctly rounded, which is a more stringent quality of implementation condition than required for most of the methods in question that are also included in this class.
int
value. If the argument is not negative, the argument is returned. If the argument is negative, the negation of the argument is returned.
int
value. If the argument is not negative, the argument is returned. If the argument is negative, the negation of the argument is returned.
Note that if the argument is equal to the value of Integer.MIN_VALUE
, the most negative representable int
value, the result is that same value, which is negative. In contrast, the absExact(int)
method throws an ArithmeticException
for this value.
a
- the argument whose absolute value is to be determined
expected
and actual
are equal.
@Test
is used to signal that the annotated method is a test method.
@Test
is used to signal that the annotated method is a test method.
@Test
methods must not be private
or static
and must not return a value.
@Test
methods may optionally declare parameters to be resolved by ParameterResolvers
.
@Test
may also be used as a meta-annotation in order to create a custom composed annotation that inherits the semantics of @Test
.
@Test
methods are inherited from superclasses as long as they are not overridden according to the visibility rules of the Java language. Similarly, @Test
methods declared as interface default methods are inherited as long as they are not overridden.
By default, test methods will be ordered using an algorithm that is deterministic but intentionally nonobvious. This ensures that subsequent runs of a test suite execute test methods in the same order, thereby allowing for repeatable builds. In this context, a test method is any instance method that is directly annotated or meta-annotated with @Test
, @RepeatedTest
, @ParameterizedTest
, @TestFactory
, or @TestTemplate
.
Although true unit tests typically should not rely on the order in which they are executed, there are times when it is necessary to enforce a specific test method execution order — for example, when writing integration tests or functional tests where the sequence of the tests is important, especially in conjunction with @TestInstance(Lifecycle.PER_CLASS)
.
To control the order in which test methods are executed, annotate your test class or test interface with @TestMethodOrder
and specify the desired MethodOrderer
implementation.
Integer
class wraps a value of the primitive type int
in an object. An object of type Integer
contains a single field whose type is int
.
Integer
class wraps a value of the primitive type int
in an object. An object of type Integer
contains a single field whose type is int
.
In addition, this class provides several methods for converting an int
to a String
and a String
to an int
, as well as other constants and methods useful when dealing with an int
.
This is a value-based class; programmers should treat instances that are equal as interchangeable and should not use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail.
Implementation note: The implementations of the "bit twiddling" methods (such as highestOneBit
and numberOfTrailingZeros
) are based on material from Henry S. Warren, Jr.'s Hacker's Delight, (Addison Wesley, 2002).
int
can have, 231-1.
int
can have, 231-1.
int
can have, -231.
int
can have, -231.