¿Cuál es la mejor práctica para organizar la estructura de carpetas de prueba de Ruby?

Question

En Java, normalmente crearía dos carpetas de origen src y test con una jerarquía de paquetes idéntica.

En Ruby ¿acabas de poner todas las pruebas en la misma carpeta que la clase bajo prueba? ¿O creas una jerarquía similar en una carpeta separada? Si es así, ¿cómo maneja las rutas require en las pruebas de su unidad?

Answer 1

Al principio, cada gema tiene un diseño típico. El código está casi completamente en lib. En el directorio raíz, solo hay metadatos como READMEs, el archivo gemspec y algunos datos de configuración opcionales. Si escribe una aplicación web con algo como Rails o Sinatra, sus estándares de diseño se usan en su lugar

En todos los tipos de proyectos, las pruebas se pueden encontrar en lugares similares. Según el marco de prueba que utilice, existen diferentes estándares.

Si usa Test::Unit, las pruebas se encuentran en un directorio test. No existen estándares reales sobre cómo organizar realmente los archivos de prueba en ese directorio. Personalmente, me pareció útil reflejar al menos parcialmente el diseño de archivo del código probado. Si usa módulos/espacios de nombres generosamente, eso debería hacerlo bastante legible.

Si usa RSpec, las pruebas (luego llamadas especificaciones) van a un directorio spec. Las notas anteriores sobre el diseño de las pruebas reales también se aplican aquí.

Al final, es principalmente una decisión de los desarrolladores cómo configurar sus pruebas. Como las pruebas son un área donde cualquier persona tiene opiniones diferentes (y de cuerdas), no hay un camino sagrado hacia el éxito. Deberías echarle un vistazo a algunas gemas que usas y cómo hacen esas cosas. Se puede encontrar un ejemplo de diseños de Test :: Unit en las gemas de Rails, p. para ActiveRecord. Un ejemplo para las pruebas de RSpec es el complemento chiliproject_backlogs para ChiliProject.

Answer 2

Soy nuevo en Ruby y me pregunto lo mismo. La parte que no obtuve fue cómo organizarlos jerárquicamente para que coincida con una organización potencialmente jerárquica de los componentes en el directorio lib, y luego ejecutarlos todos como un conjunto.

No he estado buscando en Google tanto tiempo, pero mis hallazgos ya son más delgados de lo esperado. Lo más útil que he encontrado es esto de los ruby wiki:

clases de casos de prueba pueden reunirse en conjuntos de pruebas que son archivos de Ruby que requieren otros casos de prueba:

archivo #: ts_allTheTests.rb
requieren 'test/unit'
requieren 'TESTONE'
requieren
requerir

De esta manera, los casos de prueba 'testTwo' 'testThree' relacionados se puede agrupar naturalmente. Además, las suites de prueba pueden contener otras suites de prueba, lo que permite la construcción de una jerarquía de pruebas.

Anteriormente, había estado evitando subdirectorios en mi directorio de prueba y hacer algo como esto en mi Rakefile, o cualquier archivo de rubí que realmente ejecuta las pruebas:

$LOAD_PATH << File.dirname(__FILE__) 
require 'test/unit' 
Dir.glob('test/test_*', &method(:require)) 

Así que si se combinan las dos técnicas , Tendría un archivo para cada directorio que requiere dinámicamente pruebas de ese directorio, que a su vez sería requerido por el archivo para el directorio principal. Pero esto parece frustrar mi esfuerzo original por evitar el tedio.

Luego encontré someclasses en ruby-doc que sonaba relevante pero no estaba documentado. Sin embargo, parece que hay más información disponible al alza para Test::Unit que fácilmente podría haber pasado por alto. Aún no lo he leído todo, pero parece prometedor.