Imaginemos que tenemos un step:
Dado un usuario registrado
Aquí hay dos enfoques diferentes a la hora de implementarlo:
step "un usuario registrado" do
visit home_path
fill_in "Username", with: "JohnDoe"
fill_in "Password", with: "mypass"
fill_in "Password confirmation", with: "mypass"
click_button "Sign up"
end
step "un usuario registrado" do
User.create!(username: "JohnDoe", password: "mypass")
end
Obviamente con el segundo enfoque vamos a ahorrar código y tiempo de ejecución en el test, pero esto tiene un problema y es que el test va a estar acoplado con el código y va a incrementar la fragilidad del test.
La ventaja del primer enfoque es que el test va a ser 100% un test de integración y ni siquiera requiere que quien lo desarrolla conozca los detalles de la implementación de lo que significa que un usuario esté registrado, acercándose más por tanto a ser una prueba de caja negra.
Siempre debe escribirse un test que reproduzca el bug y después debe hacerse pasar (TDD). Es la única manera de asegurarse que el test cubre el problema.
Idealmente debería usarse un test unitario si es posible, normalmente no merece la pena usar un test de integración.