I understand that unit tests must be as isolated as possible, i.e. are self-contained and do not have to rely on outside resources like databases, network access or even the execution of previous unit tests.
However, suppose I want to test class Y. Class Y uses class X. However, I have already a number of unit tests that test class X.
I think that in the unit tests of class Y, I could just assume that class X works properly and use instantiations of it to test class Y (instantiated in the class Y unit tests, so no leftovers or other pollution).
Is this correct? Or do I need to mock class X when testing class Y or do something else entirely? If so or if I should mock class X, what are the reasons for that?
I'll play devil's advocate here and recommend that unless this is an integration test of some kind, you don't use class X in your class Y tests, but use a Mock (or even a stub) instead.
My reasoning behind this is:

If your test of Y relies on some side-effect or state from X being invoked by Y, then by definition it is not a unit test.
Therefore all you want in your Unit Tests for class Y is something that looks and behaves like a class X whilst at the same time being fully defined by, and under the control of, the test method driving class Y.
Since assumptions are antitheses to unit testing, if you want to ensure  that when X.SomeMethod is invoked during a test of Y that nothing explodes, the only way to be 100% certain (and therefore have 100% confidence in your test) is to provide via a Mock or Stub an implementation of X.SomeMethod that you can guarantee won't fail because it does nothing and therefore cannot possibly fail.
Since your class X is already written and doesn't contain methods that do nothing, you therefore cannot use it for a unit test of class Y.
Another point to consider is how you can simulate failure when using a "real" class X. . How do you provide X to Y such that X always causes an exception, in order to test how Y behaves when faced with a dodgy X dependency? The only sane solution is to use a Mock/Stub of X. (of course you might not be going to this level of detail with your unit tests so I mention it just as an example)
Consider what may happen 6 months down the line when a change in class X which you did not unit test properly (omission of test, genuine error in designing the test, etc) causes an exception to be thrown when X.SomeMethod is invoked during a test of class Y. 
How can you know immediately that the problem is class X? Or indeed class Y? You can't, and therefore have lost the primary benefit of isolated unit tests.

Of course when you move on to Integration tests you will use class X to test how class Y behaves in a production context but that's a whole different question...
Is assuming that another unit test has tested the input of the unit code breaking isolation?