2010-02-24 32 views
9

He estado haciendo TDD y lo estaba usando más como prueba unitaria que para manejar mi diseño. Recientemente, he leído mucho sobre BDD; ahora que tengo una mejor idea sobre ambos, estaba tratando de descubrir cómo usar BDD y pruebas unitarias al mismo tiempo.BDD y pruebas unitarias

Por ejemplo, conduciría mi diseño usando BDD, estilo Dan North, y digamos que estoy trabajando en una aplicación y tengo una especificación simple y la implemento. Tengo suficiente bdd/spec para cubrirlo. Ahora, después de volver a factorizarlo y estoy contento y aprobado como hecho para esa especificación, ¿debería comenzar a escribir pruebas unitarias para cubrir todas las entradas posibles, porque eso es lo que hice en TDD?

Soy el único desarrollador de la empresa y todo está sobre mis hombros, aunque el otro equipo intenta probar la aplicación manualmente, me gustaría reducir la tasa de defectos.

+2

Entonces, ¿podemos ver una respuesta real a _Debería empezar a escribir Pruebas unitarias para cubrir todas las entradas posibles, porque eso es lo que hice en TDD_? En serio, tengo la misma pregunta y no creo que ese enlace al libro (incluso si es tan genial) es lo suficientemente bueno como para aceptarlo. – jibiel

+0

jibie Tu derecho He agregado una respuesta a mi auto. aunque tarde! – Jamie

Respuesta

7

Levante "The RSpec Book". El libro usa Cucumber & RSpec. Podría ser fácilmente pepino & NUnit o algo más. Cucumber y BDD extienden el concepto de refactor rojo, verde a un nivel más profundo.

http://www.pragprog.com/titles/achbd/the-rspec-book

Pepino: http://cukes.info/
RSpec: http://rspec.info/
NUnit: http://www.nunit.org/
JUnit: http://www.junit.org/

+0

Soy un desarrollador de .NET, pero voy a probar el libro ¡gracias! – Jamie

+0

Estoy de acuerdo, este libro es genial. Y Cucumber también se puede usar con .NET. –

+0

Sí, y Java. Cuke para Nuke y Cuke para Duke. –

0

estoy de acuerdo. El libro de RSpec Book hace un trabajo decente al describir el enfoque de desarrollo "Outside-In". El pepino (afuera) ayuda a describir el comportamiento esperado (en términos que el usuario entienda); y RSpec/* Unit (inside) ayuda a describir el comportamiento de su clase.

+0

Outside-in comienza con los escenarios en Cucumber, pero luego la idea es que trabaje desde las interfaces de usuario hacia adentro a través de controladores, repositorios, servicios, etc. hasta que su escenario pase. Nunca se escribe un código que no sea necesario para una clase más cercana a la interfaz de usuario (los usuarios pueden ser otros sistemas). Incluso a nivel de clase hacemos primero las clases "externas". – Lunivore