Frankly, I see at least three huge misconceptions in this question:
what TDD is about, and
what the OCP is about, and
software is developed in a waterfall approach.
Let me start with the OCP. The OCP is a principle for producing reusable, generic, black box components or libraries. Such components may be developed and released by a vendor A, and then reused by a vendor B who has no direct control over the code (so it is closed against modification from B's point of view). But since A does not know the exact cases where B will reuse the component, they provide parametrization or extension points for the component - this is what open for extensions mean in the acronym OCP. Note that though the OCP is often explained using inheritance/polymorphism, this is not the essential characteristic of this principle.
In any business system of reasonable size, there will usually be a few components which follow the OCP, but most of them will not (except when you are in the role of the library vendor A and your task is to design nothing else but such components).
Now take the fact that requirements are not "finalized" (ar least, not all at once). Requirements are implemented one by one, each new one changes the existing system, the implementation can take influence on the design and change the basis for the next requirement to implement.
Whenever a new requirement is implemented in a system, there are parts of the existing code which have to be touched, extended and refactored. Components which fit to the OCP (at that time, and with regard to the specific requirement) can stay untouched, the code which uses these components will have to be adapted.
Now TDD comes into play. TDD is an implementation technique to write one test at a time, for the next "arriving" requirement (or "slice" of a requirement), before the requirement (slice) is actually implemented. Afterwards code gets written to make the test succeed and refactoring takes places. The refactoring may just clean up the code a little bit, but sometimes it can also be used to extract parts of the non-OCP compliant code and make it "OCP compliant", by introducing more parameters and extension points, or by extracting new reusable parts and components. So when the next requirement "arrives", one may be lucky and can reuse these parts of the existing code without any change.
I hope this made clear that TDD, refactoring, and the OCP are in no way contradictory: quite the opposite, TDD can actually help to develop OCP compliant components , and the OCP helps to build components which require less refactoring, less code changes and fewer tests.