Such a method only makes sense if it makes changes that
are observable through other means -- java.util.Set#clear(),
for example, takes no arguments and returns no value, but
changes the state of a Set in ways other methods can observe.

    The way to test clear() is not to observe its behavior
directly, but to observe what happens to the Set when you
use it.  A plausible unit test might apply clear() to Sets
in various states -- brand-new, with one element, with a
hundred elements, just-cleared, after insertion and individual
removal of elements -- and then use Set's other methods to see
whether clear() has had its intended effect: call isEmpty(),
or call size(), or call iterator().hasNext(), and so on.

    Test your xyz() the same way.  Figure out what effect it
is supposed to have in various circumstances, and use other
methods to verify that the effect has in fact occurred.  If
xyz() is supposed to throw an exception in some cases (as
clear() is), that's another thing you can check.