It's important to understand that a single method may not be your "unit". To give a contrived example, if (for some reason) you created a class with public methods:
Add(object key, object value);
which just wrapped a private Dictionary, it would be inconceivable to test just one of those methods at a time, independent of the other.
For the exact situation you describe, though, it may not be so clear-cut. It sounds like rather than being intrinsically dependent on each other for their function like the above example, your methods are linked only in that one happens to be useful in a test of the other.
In this case, it might be informative to start with the idea of duplicating method B exactly in your test code and asking whether or not this is a violation of DRY. Obviously you're repeating your code, but as demonstrated by Mathias Verraes, this doesn't always mean a DRY violation. A good way to think about this is: when one of these methods changes, will the other one always require the same change?
It's hard for me to judge without knowing the exact methods, but it's quite possible that you might want, for example, your test version of B not to do some validation that the production version does, or similar. In this case, having two versions may be fine.
There are additional practical trade-offs:
If you do use method B in testing method A, then a bug in method B could mask a bug in method A, or at least prevent you from knowing the true result of your test of method A. This is similar to the reason that people generally try to avoid multiple asserts.
On the other hand, if you make a test version of method B and allow it to vary independently of the production version, the test version itself will not be as well tested, which could be a problem if the method is sufficiently complex or liable to change.