¿Cómo harías un blog con un enfoque TDD?

Question

Estoy considerando volver a crear mi blog (actualmente en PHP, pero < 100 líneas de código sin diseño) en Ruby on Rails solo por el gusto de hacerlo. Quiero hacer otro proyecto en Rails, pero debería aprender Rails (más que hola mundo) antes de ir para intentar crear un proyecto completo.

Otra cosa que quiero hacer mientras rehago mi blog es al menos descubrir de qué se trata el TDD. Entonces, ¿cómo tomarías un enfoque basado en la prueba para la creación de un blog? ¿Qué pruebas escribirías? ¿Cómo comenzarías?

Cada vez que visualizo escribiendo un blog, terminaría necesitando un millón de pruebas para un solo componente para probarlo por completo. ¿Cómo evito escribir demasiadas pruebas?

Además, estoy haciendo esta comunidad wiki porque tengo la intención de que esto básicamente ser hecho en base de un mini tutorial/conocimiento ...

fui adelante y poner precio a esta pregunta así que tal vez puede en realidad obtener una buena respuesta a esto ..

Answer 1

TDD es más sobre el diseño, entonces se trata de pruebas. Mucha gente lo extraña y terminará practicando algo que no se siente como TDD. Con TDD, está escribiendo una prueba para generar un cambio en su código. No debe preocuparse por escribir demasiadas pruebas, ya que solo debe tener una prueba para escribir si hay más código de producción para escribir (y, por lo tanto, más código para probar). Una vez más, TDD NO se trata solo de escribir muchas pruebas para su código, pero terminará con muchas pruebas y, por lo tanto, tendrá un conjunto de pruebas muy potente para darle feedback a medida que su código crece y cambia.

En lugar de hablar sobre cómo probar el desarrollo de una determinada pieza de software, le recomiendo que lea y aprenda a practicar TDD y descubra, como usted dijo, de qué se trata. Un buen libro para considerar es: Growing Object Oriented Software, Guided by Tests. El libro usa Java, pero es una gran aplicación en la vida real de usar TDD para construir una pieza bastante compleja de software.

TDD tiene mucho que ofrecer, y yo recomendaría profundizar en algunas buenas fuentes si quiere aprender y tratar de practicarlo porque hay más de lo que se puede plantear en las respuestas a esta pregunta.

Answer 2

Comience escribiendo las características de Cucumber para proporcionar una cobertura de "afuera adentro". Estos deberían ser capaces de probar la gran mayoría de su funcionalidad por sí mismos. Muy fácil de escribir Un blog no tiene tantas pruebas, después de todo solo son publicaciones y comentarios, ¿verdad? Eche un vistazo a mi aplicación blorgh, que es una aplicación de Rails desarrollada con Cucumber.

Answer 3

Interesante, esto es exactamente lo que comencé hace un par de días. Estoy usando RSpec y Cucumber. Empecé escribiendo un par de especificaciones para los modelos Article y Comment. Cuando todos se volvieron verdes, escribí las pruebas de Cucumber para implementar vistas, controladores, etc.

Esto funciona muy bien para mí, pero creo que comenzar con Pepino también es bueno ya que a muchos parece gustarles este enfoque.

En caso de tener sólo unos pocos conocimientos de RSpec y pepino le recomiendo Railscasts:

• Beginning with Cucumber
• More on Cucumber
• Testing Controllers with RSpec
• RSpec Matchers & Macros

También me gustó el Peepcode screencasts, pero a diferencia de los railscasts cuestan 9 $ cada uno.

Answer 4

Eche un vistazo a las partes interesadas, y lo que quieren lograr. Es importante comenzar allí, porque le permite priorizar correctamente (es decir, no en la parte técnica más interesante, sino en la parte con mayor valor comercial). El desarrollador es un interesado, y reducir sus temores (de no poder construir algo) es un objetivo válido.

El pensamiento sobre el diseño está escrito en pruebas. Comience con las metas finales de las partes interesadas, trabaje desde allí hacia atrás hasta el comienzo (Inversión temporal). Eso asegura que te concentres en qué y menos en cómo. La interacción entre objetos es más importante para obtener los atributos correctos que los atributos del objeto.

Ver:

• http://www.robvens.nl/en/articles/computers/29-time-inversion-pattern
• http://www.robvens.nl/en/articles/computers/28-active-passive-pattern

Answer 5

que tienen una opinión similar a Pete, su más sobre el diseño.

Es probable que saltar sobre él antes de haber examinado información de calidad no le proporcione los resultados. Probablemente te haga pensar: estas pruebas se sienten como un dolor. Esta es una constatación de que hay problemas de diseño, pero no le indicará cómo mejorarlo.

Dijiste "actualmente en PHP, pero < 100 líneas de código no de disposición", si ese es el caso, probablemente haya un puñado de características. Si se enfoca en las características reales necesarias, también debería haber algunas pruebas/más altas que la cantidad de características, por supuesto, pero mientras esas sean las pruebas correctas de la unidad, el número no debería explotar: check this video.