As stated by everyone else, unfortunately, what you have described is the "real world".
I have heard rumors of the mythical organizations where the highest level of CMMI is acheived, BDD/TDD is budgeted for and employed, requirements are well documented and are both accurate and unchanging, S.O.L.I.D. architectures principles are adhered to, there are no over estimations of the ability to produce a feature in a given time frame, there is active open and honest communication between project managers, team leaders, and developers, and you actually like the people you work with, but I think these organizations all reside in Shangri-La somewhere on the Western end of the Kunlun mountains...you often can find an organization with one or more of these characteristics, but rarely with them all (I tend to opt for the ones with people I like to work with).
It seems that you have pretty much decided to leave, so here is my answer to your question about how to find out whether future potential employers use these techniques on a day to day basis:
It is perfectly fine to ask about such things in an interview, but don't expect to always get an honest up front answer.
Companies tend to want employ developers that are concerned about such things as mentioned above.
Companies are made up of individuals.
Individuals are known to lie or stretch the truth (speak of hopes and dreams as realities) to either get what they want or to not appear to be incompetent.
Therefore, companies will often lie to you (or be misleading/not be completely forthcoming), about whether employing all of the techniques listed above just to get a great prospect like yourself.
Now, they may have plans to do all of these things or they may have some individual developer who does them just to stay sane, so technically they were telling the truth, but the only way you'll get the real scoop is to talk with someone in the trenches who has nothing to gain by lying to you.
This is one time it would actually be preferable to speak with someone who is negatively biased and/or disgruntled, because it'll take them about 5 minutes to fill you in on the real scoop.
At any rate, you can take heart. This too shall pass. Look at every experience as just that...more experience. Seek methods to increase communication between the team. Start taking charge of the design of whatever is under your control and code it like a BOSS. Be sure to leave everything you touch in a better state than what you found it so that it is clear that pikachu0 has been here. Then document it all on your resume.
Is your Team Lead over optimistic? Factor that into the estimates you give him. At the end of the day, if your actual time matches what's recorded for your estimated time, you come out looking much better...so estimate to offset his under-estimation.
You want to employ TDD? Do it. Make it part of the development process for yourself. If inquiries are made into why you're doing something, respond that "this is the way I write code...this is the right way to write code...I don't know of any other way to write code".(<-- period!)
The ability to successfully navigate challenging situations are what potential employers want from an applicant. You're going to have customers, end users, co-workers, and clients that are worse...much much worse, so you need to be able to develop those interpersonal skills that will allow you to navigate these treacherous waters safely.
You also must just take control of your technical career. If you can't do it on the job, start a side project to pickup the skills you want. You can come in early to do it or stay late to get it done. Yea, no one likes working for free, but it'll pay dividends exponentially when you have mastered an in demand skill set.
And don't stress. You're a recent grad, so you may be nervous about retaining employment, but if you're committed to producing quality software, then you're already in high demand and you'll be in even higher demand as soon as you get a few years of experience to go along with your cutting edge skills.