¿Ejemplos del mundo real de aplicaciones escritas con TDD y buena cobertura de prueba? [cerrado]

Cerrado. Esta pregunta está fuera de tema . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que sea sobre el tema de Software Engineering Stack Exchange.

Cerrado hace 6 años .

¿Hay alguna aplicación de código abierto que se desarrolle utilizando un desarrollo basado en pruebas que sirva como modelo de cómo deberían funcionar las pruebas unitarias?

Prefiero ver ejemplos en C # y .NET. (Tenga en cuenta que mencioné aplicaciones, no solo bibliotecas).

Soy un programador de nivel medio que realmente quiere creer y practicar TDD. La aplicación en la que trabajo en mi trabajo diario es bastante complicada, aproximadamente 1 millón de líneas de código, y me encantaría presentar más pruebas unitarias. Tenemos algunas pruebas unitarias, pero mis esfuerzos en TDD y en trabajar en código que ya está bajo prueba no han sido alentadores.

En mi experiencia ciertamente limitada, TDD parece alentar una gran complejidad en nombre del desacoplamiento. Los bits de la aplicación que son difíciles de probar, y que casualmente tienden a ser críticos, son empujados a la periferia, al ámbito de las pruebas de integración que pueden o no escribirse. (Estoy pensando en los sospechosos habituales aquí, acceso al sistema de archivos, objetos hidratantes de una base de datos, llamadas web asincrónicas, etc.)

El código que se está probando tiende a involucrar mucha colaboración entre objetos, y tal vez una lógica de flujo simple, todo lo cual sucede en la memoria y que podría decirse que podría escribirse de una manera más simple y más comprensible si todo no tuviera que estar totalmente desacoplado para las pruebas.

Entiendo las técnicas para burlarse de las dependencias y demás, pero en mi experiencia el uso intensivo de la burla conduce a pruebas muy frágiles. Si mi primer instinto al ver que un grupo de pruebas se vuelve rojo es: "Genial, ahora tengo que arreglar todos los simulacros", entonces mis pruebas se han convertido en un obstáculo en lugar de una red de seguridad.

Estoy tratando de superar esta barrera mental, y como parte de eso estoy leyendo el libro de Michael Feathers, Working Effectively with Legacy Code . Espero que me muestre algo de lo que me estoy perdiendo.

También me gustaría estudiar algunas aplicaciones .NET no triviales con buena cobertura de código, tal vez un sistema de administración de contenido o una aplicación CRUD. El marco de prueba FitNesse del que habla el tío Bob es algo que probablemente miraré, pero sería bueno ver algo escrito en el idioma con el que estoy más familiarizado.

Cualquier sugerencia o palabra de sabiduría sería apreciada.

unit-testing tdd

— Josh Earl
fuente

Duplicado de programmers.stackexchange.com/questions/21791/…

— liori

No del todo ... Estoy interesado en ver ejemplos de aplicaciones del mundo real. La respuesta aceptada en esa publicación recomienda un marco de prueba. He visto algunos ejemplos de marcos y bibliotecas antes, pero eso no responde a mi pregunta.

— Josh Earl

@JoshEarl - Estoy de acuerdo ... No creo que mi respuesta a continuación haya sido relevante para la otra publicación

— hanzolo

Respuestas:

No sé si se utilizó TDD, pero un ejemplo estelar de prueba es sqlite, que tiene una notable cobertura de sucursal del 100% y tiene más de 1000 veces más código de prueba y secuencias de comandos que el código de producto.

— Bryan Oakley
fuente

eso suena como un desperdicio de esfuerzo notable si su relación de código a código de prueba es tan alta

— Ryathal

@Ryathal: El costo de la falla dicta el esfuerzo de prueba, no la longitud del código probado. Dado el uso suficientemente amplio en enfoques suficientemente críticos para la misión, las pruebas podrían haber valido la pena. Sin embargo, no estoy realmente seguro si SQLite no se excedió.

— Thiton

sqlite es definitivamente una misión crítica para mucha gente. Es posible que se sorprenda con qué frecuencia se usa (OSX, iOS, Android OS, por ejemplo). Y debes darte cuenta, muchas de esas líneas de código de prueba y datos probablemente fueron generadas por máquina. Una base de datos de fuerza industrial tiene muchos casos extremos.

— Bryan Oakley

SQLite es la base de datos SQL más utilizada en el planeta, su base de instalación es un orden de magnitud mayor que MySQL, PostgreSQL, SQL Server, Oracle, DB2 combinados . Es probablemente una de las piezas de software más utilizadas, punto. Si hubiera un error en SQLite, todos los teléfonos inteligentes del planeta dejarían de funcionar. Creo que eso justifica un poco la paranoia.

— Jörg W Mittag

@ JörgWMittag wow, nunca supe eso de SQLite. Divertido. Gracias. Pero 1000 veces más código de prueba. Eso es increíble.

— Mike roedor

El proyecto Orchard podría ser lo que estás buscando. Es una aplicación .NET / MVC / TDD que es bastante compleja, pero no está mal y demuestra algunas buenas prácticas y patrones.

http://orchard.codeplex.com/wikipage?title=solution

y supongo que el enlace actualizado:

http://docs.orchardproject.net/

— hanzolo
fuente

Esto parece prometedor, no puedo esperar para cavar. :)

— Josh Earl

Muchas bibliotecas de código abierto de terceros son TDDed. Hibernar las bibliotecas de Rhinos, como RhinoMocks y NHibernate, son TDDed por sus desarrolladores utilizando XUnit como el marco de prueba de la unidad.

Ahora, con OSS, generalmente no puede garantizar que TODO el producto haya sido TDDed. La comunidad puede tener estándares que incluyen esta práctica, e incluso pueden usar un build-bot que realiza métricas de cobertura de código, pero TDD es una mentalidad que debe ser adquirida por el desarrollador y con el público en general capaz de comprometerse a abrir troncales VCS de origen como las de GitHub, cualquiera puede cometer cualquier cambio con cualquier cantidad de cobertura de prueba (o si se requiere cobertura, las pruebas podrían haberse escrito después del hecho, lo cual es una violación del espíritu de TDD, pero realmente no existe una buena manera de atraparlo en commit).

— KeithS
fuente