2008-09-26 8 views

Respuesta

6

Cucumber y RSpec valen un vistazo. Fomentan las pruebas en un estilo basado en ejemplos behaviour-driven.

RSpec es una biblioteca para la prueba de nivel de unidad:

describe "hello_world" 
    it "should say hello to the world" do 
    # RSpec comes with its own mock-object framework built in, 
    # though it lets you use others if you prefer 
    world = mock("World", :population => 6e9) 
    world.should_receive(:hello) 
    hello_world(world) 
    end 
end 

Tiene soporte especial para rieles (por ejemplo, se puede poner a prueba los modelos, vistas y controladores de forma aislada) y puede sustituir a los mecanismos de prueba integrado en rieles .

pepino (anteriormente conocida como la RSpec historia Runner) le permite escribir pruebas de aceptación de alto nivel en (bastante) la llanura Inglés que se podía mostrar a (y estoy de acuerdo) a un cliente, y luego ejecutarlos:

Story: Commenting on articles 

    As a visitor to the blog 
    I want to post comments on articles 
    So that I can have my 15 minutes of fame 

    Scenario: Post a new comment 

    Given I am viewing an article 
    When I add a comment "Me too!" 
    And I fill in the CAPTCHA correctly 
    Then I should see a comment "Me too!" 
+0

La segunda API para pruebas de aceptación ha sido extraída de RSpec y ahora se llama "pepino". –

+0

Gracias - He corregido para actualizar la respuesta. –

4

Mi recomendación es (en serio) omitir la unidad incorporada de rieles/pruebas funcionales, e ir directamente a RSpec.

El material incorporado en los rieles utiliza el marco Test::Unit que se envía con ruby, y que es más o menos un puerto directo de JUnit/NUnit/AnyOtherUnit.
Encontré que estos marcos son bastante tediosos y molestos, lo que conduce a una apatía general acerca de las pruebas de unidades de escritura, que obviamente no es lo que intenta lograr aquí.

RSpec es un animal diferente, siendo en torno a la descripción de lo que el código debería hacer, en lugar de afirmar lo que ya lo hace . Cambiará la forma de ver las pruebas, y te divertirás muchísimo haciéndolo.

Si me parece un poco fanático, es solo porque realmente creo que RSpec es tan bueno. Pasé de estar molesto y cansado de la unidad/pruebas funcionales, a un creyente firme en él, más o menos únicamente por rspec.

+0

Test :: Unit y RSpec son solo herramientas; el valor está en cómo las usa. Todo lo que puede hacer en RSpec lo puede hacer en Test :: Unit. BDD es una mejora con respecto a TDD solo porque indica en un lenguaje claro lo que debería haber estado haciendo en sus pruebas de todos modos. Ver http://dannorth.net/introducing-bdd –

+0

que es exactamente mi punto. Podría escribir todas mis pruebas en ensamblador x86 si quisiera. El valor está en cómo afecta tu pensamiento y, por lo tanto, te ayuda a producir mejores pruebas –

4

Parece que ya ha escrito su aplicación, por lo que no estoy seguro de que obtenga una gran ventaja de usar RSpec sobre Test::Unit.

De todos modos, independientemente de cuál elija, rápidamente se encontrará con otro problema: administrar dispositivos y burlas (es decir, los "datos" de prueba). Así que echa un vistazo a Shoulda y Factory Girl.

0

Incluso si la aplicación ya está escrita, recomendaría usar RSpec sobre Test :: Unit por el simple hecho de que ninguna aplicación termina. Tendrá que agregar funciones y código de refactorización. Conseguir el hábito prueba correcta desde el principio ayudará a hacer estas alteraciones menos doloroso

1

También puede probar la interfaz web con un complemento de Firefox como http://selenium.openqa.org/

Se registrará los clics y de introducción de texto y luego reproduce y revisará la página para ver los elementos de visualización correctos.

Cuestiones relacionadas