It's easier to do in this case, because the two parties are independent. If they don't talk to each other, it's not hard to create cycles. You have to be mindful to avoid them.
Cyclic dependencies aren't hard to create. Look at Java itself: java.lang, java.util, and java.io have cycles. Will you stop writing Java, since it's so "terrible"?
It means that you can never use libA without libB and vice versa. They've become one big library. Same with packages in Java and other systems: once you have a cycle, you have to use all those packages together as if they were one.
The guys who write Spring pay a lot of attention to cycles. They design and refactor their framework to eliminate them.
So - what's the harm? Juergen Heller says they're bad, and he's right. But from your point of view, what evil is visited upon you? It means you have to use both when you run and test. You can't test class A without class B and vice versa when there's a cycle between them. It makes testing and running harder.
You can choose an alternative that doesn't have the cycle. If you can change the source, you can refactor and maintain it. But that's it.
You should check your own code to see if you've done it to yourself. IntelliJ has nice analysis tools which can be applied to a code base. Check it out.