Hay muchas razones Eric Lippert ha declarado muchas veces que la razón feature X
no está en C # es porque simplemente no está en su presupuesto. Los diseñadores de idiomas no tienen una cantidad infinita de tiempo ni dinero para implementar cosas, y cada nueva característica tiene costos de mantenimiento asociados. Mantener el lenguaje lo más pequeño posible no solo es más fácil para los diseñadores de lenguaje: también es más fácil para cualquiera que escriba implementaciones y herramientas alternativas (por ejemplo, IDE) Además, cuando algo se implementa en términos del lenguaje en lugar de parte de él, se obtiene portabilidad gratis. Si las pruebas unitarias se implementan como una biblioteca, solo necesita escribirla una vez y funcionará en cualquier implementación conforme del lenguaje.
Vale la pena señalar que D tiene soporte de nivel de sintaxis para pruebas unitarias . No sé por qué decidieron incluir eso, pero vale la pena señalar que D está destinado a ser un "lenguaje de programación de sistemas de alto nivel". Los diseñadores querían que fuera viable para el tipo de código inseguro y de bajo nivel en el que C ++ se ha utilizado tradicionalmente, y un error en el código inseguro es increíblemente costoso: comportamiento indefinido. Así que supongo que tiene sentido para ellos gastar un esfuerzo adicional en cualquier cosa que lo ayude a verificar que algún código inseguro funcione. Por ejemplo, puede exigir que solo ciertos módulos confiables puedan realizar operaciones inseguras como accesos de matriz no verificados o aritmética de puntero.
El desarrollo rápido también era una prioridad para ellos, tanto es así que lo convirtieron en un objetivo de diseño que el código D compila lo suficientemente rápido como para que se pueda usar como lenguaje de script. Las pruebas de unidad de horneado directamente en el idioma para que pueda ejecutar sus pruebas simplemente pasando una bandera adicional al compilador ayuda con eso.
Sin embargo, creo que una gran biblioteca de pruebas unitarias hace mucho más que solo encontrar algunos métodos y ejecutarlos. Tome QuickCheck de Haskell, por ejemplo, que le permite probar cosas como "para todos los x e y f (x, y) == f (y, x)
". QuickCheck se describe mejor como un generador de prueba de unidad y le permite probar cosas a un nivel más alto que "para esta entrada, espero esta salida". QuickCheck y Linq no son tan diferentes: ambos son lenguajes específicos de dominio. Entonces, en lugar de agregar el soporte de pruebas unitarias a un idioma, ¿por qué no agregar las características necesarias para que las DSL sean prácticas? Terminarás con no solo pruebas unitarias, sino un mejor lenguaje como resultado.