Ninguna de esas cosas que el código no comprobable. Pueden dificultar la búsqueda de errores en el borde del caso pero, siempre que haya especificado los criterios de éxito para las pruebas (y el desarrollo basado en pruebas lo facilita), todo lo que tiene que hacer es aprobar los criterios.
TDD se puede aplicar al comportamiento de piezas específicas, así como del proyecto en su conjunto, para que pueda probar fácilmente componentes muy pequeños. Pero, está destinado a probar los resultados, no los medios por los cuales se obtuvieron esos resultados.
Siempre que se superen las pruebas, usted ha cumplido con los requisitos. Si hay errores después de eso, este es un problema con las pruebas, no con el código que se está probando (en cuyo caso las pruebas deben modificarse para detectar el problema previamente no previsto).
No debe importar (en términos de entrega de funcionalidad) si hay una instrucción while en uno de sus constructores. Debería preguntarse qué requisitos empresariales así lo exigen. Dudo mucho que su cliente entregue una lista de requisitos que incluya "herencia limitada a 4 niveles". Es muy posible que incluyan una lista de "sin errores" como un requisito, pero tendrá que negociarlos con ese :-).
¿Alguno de éstos no huele código? –