Java test state
Keyword the assert (test) appeared in Java 1.4. It seems to me that many still try to avoid it, or wrap it in utility static methods with the ability to quickly change
throughout the code. Someone is afraid that the checks are not reliable enough, and if someone forgets to turn them on, some bugs will go unnoticed. Someone, on the contrary, manically thinks about performance: if someone turns on the checks for the subsystem / library written by the guys from the first group and forgets to exclude packages or classes of the “productive” library, execution will be slowed down by useless calculations.
Although, in my opinion, there is nothing wrong with the checks, they can and should be arranged as generously as possible on the code. Firstly, as I already mentioned (but for some people this may be new), checks can be flexibly configured ( enable / disable in packages and individual classes) both from the command line when starting the JVM, and programmatically (via ClassLoader), so if you suddenly want to enable checks in one system and turn it off in another, this is definitely the problem to be solved.
Secondly, sometimes I want to check not trivial conditions like
The trick is simple: initialization and updating of the verification state is carried out in methods that, according to the meaning, do not return anything (
Example:
assert condition : message;
toif (!condition)
throw new AssertionError(message);
throughout the code. Someone is afraid that the checks are not reliable enough, and if someone forgets to turn them on, some bugs will go unnoticed. Someone, on the contrary, manically thinks about performance: if someone turns on the checks for the subsystem / library written by the guys from the first group and forgets to exclude packages or classes of the “productive” library, execution will be slowed down by useless calculations.
Although, in my opinion, there is nothing wrong with the checks, they can and should be arranged as generously as possible on the code. Firstly, as I already mentioned (but for some people this may be new), checks can be flexibly configured ( enable / disable in packages and individual classes) both from the command line when starting the JVM, and programmatically (via ClassLoader), so if you suddenly want to enable checks in one system and turn it off in another, this is definitely the problem to be solved.
Secondly, sometimes I want to check not trivial conditions like
какая-то булева переменная == false или true
, but to maintain some check state inside the class and check it in methods. With the trick c, assert
you can achieve this almost for free when running with disabled checks. The trick is simple: initialization and updating of the verification state is carried out in methods that, according to the meaning, do not return anything (
void
), and in the code - boolean
always true
. These methods are called "through"assert
. That is, when the checks for the class are disabled, the methods are not called, the test state is not initialized or updated, and in overhead only one null
link remains in the object's memory. Example:
import java.util.HashSet;
import java.util.Set;
public final class MyCoolSet {
private Object[] coolStorage;
private transient Set referenceSet;
public MyCoolSet() {
// ... init cool storage
assert initReferenceSet();
}
private boolean initReferenceSet() {
referenceSet = new HashSet<>();
return true;
}
public int size() {
// return the cool size
return 42;
}
public boolean add(E e) {
// .. add an element to the cool storage
boolean added = true;
assert addToReferenceSet(e);
return added;
}
private boolean addToReferenceSet(E e) {
referenceSet.add(e);
checkSize();
return true;
}
private void checkSize() {
assert referenceSet.size() == size() :
"Cool size diverged from reference size";
}
public boolean remove(Object o) {
// ... remove an element from the cool storage
boolean removed = true;
assert removeFromReferenceSet(o);
return removed;
}
private boolean removeFromReferenceSet(Object o) {
referenceSet.remove(o);
checkSize();
return true;
}
}