I'm not exactly sure what you mean by a circular dependency, but at a general level two micro-services should be able to be deployed, managed, and versioned interdependently of each other. If you're in a position where a change in micro-service A results in a change in micro-service B, then you're kind of doing it wrong. But I can see where two services may have inter-dependencies.
But it's possible to have "circular" dependencies and still be a reasonable micro-service. Say, for example, one service manages users and credentials and the other manages login sessions. In order to change a user's credentials you may need a valid session token that proves you are that same user. To get a session token, you need to be able to authenticate a user with their credentials. The two services both need to be up for security to work, but they may have clearly defined interfaces. For testing you could create a stub version of the other service.
The API for the credentials service might allow a user to validate credentials, register users, and obtain details for a user. The session service has an API that returns a session token, given a set of credentials, and returns the principal for a given session token. If the API definitions are well thought-out and carefully adhered to, I think it would be fine to have these inter-dependencies. But if you can't establish clear contracts, and changes to one service implies changing the other, then you probably should not have split the services.
As part of the micro-service on something as critical as user authentication, you would put a load-balancer in front of a cluster of containers or VMs running the service. That way you could run two or three copies of each service and if one went down, the load balancer would hide that. (In addition to reasonable retry policies for transient failures, etc.). But you wouldn't be able to authenticate unless the user credentials service was available and the session service was also available.
Adding some clarification:
Generally speaking (micro-services, class dependencies, etc.) you want your coupling to be a directed acyclic graph. B depends on A then A should have no knowledge of B. This isn't a micro-service specific, but a general design principle. One way to fix my design above is to split the credential validation into a separate service and get back the DAG. The specific risk you are trying to avoid is that you can't change or evolve A and B independently of each other. You will always wind up making changes to both.
Never is a very strong word and so I wouldn't say you should never do something, but you should avoid circular dependencies. I think coupling is the real danger.