pruebas unitarias para un analizador csv

14

¿Qué pruebas debo usar para probar un analizador csv?

Tengo un analizador de csv simple en C #, y quiero asegurarme de tener una buena cobertura de pruebas unitarias de todos los casos límite comunes (y poco comunes). ¿Qué pruebas debo usar para identificar posibles problemas y casos límite?

testing parsing Joel Coehoorn
fuente
55
¿Ha revisado generatedata.com para la creación de diferentes archivos de prueba?
Aaron McIver
@ Aaron: las buenas pruebas son repetibles y, por lo tanto, no utilizan datos que varían. Pero tal vez podría usarlos para una generación única que luego guardo para un conjunto de pruebas. Pero incluso entonces, quiero asegurarme de haber cubierto todos los diferentes casos límite, lo que no se garantiza al azar.
Joel Coehoorn el
Los resultados de la prueba Coehorn Good son repetibles. Yo diría que usar datos que varían está bien siempre que el resultado deseado permanezca constante. Si desea asegurarse de haber cubierto todos los casos límite diferentes (según sus comentarios, parece seguro de cuáles son), ¿por qué no comenzar a escribir las pruebas? Pasará más tiempo buscando una solución mágica que simplemente escribiendo las pruebas.
Aaron McIver
El autor está buscando casos de prueba, no datos de prueba. Ojalá supiera dónde encontrar pruebas públicas para varias cosas también.
ProdigySim

Respuestas:

6

Acabo de encontrar https://github.com/maxogden/csv-spectrum :

Un montón de diferentes archivos CSV para servir como prueba de ácido para las bibliotecas de análisis CSV. También hay versiones JSON de los CSV para fines de verificación.

El objetivo de este repositorio es capturar casos de prueba para representar todo el espectro CSV.

Andreas Gohr
fuente
Es interesante que el analizador de csv propio de GitHub falle las pruebas al intentar mostrar los CSV de prueba ( github.com/maxogden/csv-spectrum/blob/master/csvs/… )
Ian Boyd el
16

Aquí hay algunos casos límite en los que debería haber pensado y tener casos de prueba.

  1. Campo básico. ,foo,
  2. Campo básico citado. ,"foo",
  3. Campo citado con nueva línea incrustada. ,"foo\nbar"
  4. Campo citado con coma incrustada. ,"foo,bar"
  5. Campo entre comillas con comillas incrustadas. ,"foo""bar"
  6. ¿Distingue entre cadenas vacías y nulas? Si lo hace, entonces ,,debería ser un valor nulo y ,"",debería dar una cadena vacía.
  7. ¿Intenta detectar tipos de datos y hacer lo correcto? CSV se usa a menudo para datos numéricos. Agregue las pruebas que considere apropiadas para eso.
  8. Si escribe datos, debe cubrir todos los casos anteriores.
  9. ¿Qué haces con líneas con diferentes números de campos? (Pruébalo.)
  10. ¿Qué haces con las líneas en blanco al final? (Pruébalo.)
  11. ¿Cómo es el rendimiento en un archivo grande? (Pruébelo. He visto demasiados analizadores de CSV de cosecha propia que usan cadenas de manera ineficiente y, como resultado, toman tiempo cuadrático, lo que hace que las cosas simples se vuelvan dolorosamente lentas).
btilly
fuente
10

No hay una especificación formal para los archivos CSV. Sin embargo, eche un vistazo a RFC 4180 - Tipos comunes de formato y MIME para archivos CSV , (particularmente la Sección 2) que documenta el formato que parece ser seguido por la mayoría de las implementaciones.

Parece bastante sencillo comenzar a generar algunos casos de prueba de la lista en la sección 2, específicamente:

  1. Cada registro está ubicado en una línea separada, delimitada por un salto de línea (CRLF). Por ejemplo:

    aaa, bbb, ccc CRLF zzz, aaa, xxx CRLF

  2. El último registro en el archivo puede o no tener un salto de línea final. Por ejemplo:

    aaa, bbb, ccc CRLF zzz, aaa, xxx

  3. Puede haber una línea de encabezado opcional que aparece como la primera línea del archivo con el mismo formato que las líneas de registro normales. Este encabezado contendrá los nombres correspondientes a los campos en el archivo y debe contener el mismo número de campos que los registros en el resto del archivo (la presencia o ausencia de la línea del encabezado debe indicarse mediante el parámetro opcional "encabezado" de este Tipo de Mimica). Por ejemplo:

    nombre_campo, nombre_campo, nombre_campo CRLF aaa, bbb, ccc CRLF zzz, aaa, xxx CRLF

  4. Dentro del encabezado y cada registro, puede haber uno o más campos, separados por comas. Cada línea debe contener el mismo número de campos en todo el archivo. Los espacios se consideran parte de un campo y no se deben ignorar. El último campo del registro no debe ir seguido de una coma. Por ejemplo:

    aaa, bbb, ccc

  5. Cada campo puede estar o no entre comillas dobles (sin embargo, algunos programas, como Microsoft Excel, no usan comillas dobles). Si los campos no están encerrados entre comillas dobles, entonces las comillas dobles pueden no aparecer dentro de los campos. Por ejemplo:

    "aaa", "bbb", "ccc" CRLF zzz, aaa, xxx

  6. Los campos que contienen saltos de línea (CRLF), comillas dobles y comas deben ir entre comillas dobles. Por ejemplo:

    "aaa", "b CRLF bb", "ccc" CRLF zzz, aaa, xxx

  7. Si se utilizan comillas dobles para encerrar los campos, se debe escapar una comilla doble que aparezca dentro de un campo precediéndola con otra comilla doble. Por ejemplo:

    "aaa", "b" "bb", "ccc"

Paddyslacker
fuente
4

Consulte este directorio y mire el código en los archivos * .t .:

http://cpansearch.perl.org/src/MAKAMAKA/Text-CSV-1.32/t/

(El número de versión -1.32 podría cambiar eventualmente, por lo que el enlace podría quedar "muerto". Incremente el número de versión usted mismo mediante prueba y error, o vaya al directorio principal o haga clic aquí

https://metacpan.org/pod/Text::CSV

y haga clic en "Examinar" hasta el código fuente de la versión más reciente)

Text :: CSV_XS es ​​un módulo perl maduro para analizar archivos csv. Los archivos * .t están escritos en Perl 5, contienen muchos casos de prueba para autocomprobar el módulo, se deben realizar en el momento de la instalación del módulo.

knb
fuente