Tests will ensure correctness (minus your uncovered edge cases), but it's not enough for the code to be correct; it must also be as readable/understandable as possible for you and anyone reading it after you. Even with a stringent code review process on my team, I always perform my own self-review before creating a pull request. In doing so, I often find ways to make the intent of the code clearer before sending it to review.
This is a personal question though. It's possible that some developers are capable of writing very readable code from the start. If so, that's great. However, most of us will likely be able to find some improvements after the feature work is done. As such, I highly recommend performing at least a cursory self-review, or a full review if your team does not have a formal code review process in place.
As for what makes code more "readable", this can be very subjective. The goal is to make it readable for as large an audience of developers as possible. There are many resources available that describe techniques for writing clean code, such as the book by Bob Martin, which is generally well-accepted (albeit dated) for this purpose.
To answer your questions more directly: You should not need to review your code visually to check for bugs, but you should review your code visually to ensure that it is readable. There is no magic number for how long you should spend on this review; as the discovery rate of readability problems drops, you're nearing the end. My advice is to write tests for as many reasonably-expected execution paths as possible, and check manually for improvements to readability.