1. PRUEBAS EN METODOLOGÍAS ÁGILES
1.1. Pruebas relacionadas:
1.1.1. TDD
1.1.1.1. Tiene como objetivo que la aplicación funcione bien. (Luis Alejandro Barreto Quintana)
1.1.2. ATDD
1.1.2.1. Se basa en pruebas de aceptación, tomas como referencia al usuario. (Luis Alejandro Barreto Quintana)
1.1.3. STDD
1.1.3.1. Es una extensión de TDD pero enfocado a pruebas de aceptación de nivel superior. (Luis Alejandro Barreto Quintana)
2. Diferencia entre las pruebas para la calidad
2.1. Pruebas para el aseguramiento de calidad
2.2. Pruebas de mejoramiento de calidad
3. Riesgo: Un factor que podría resultar en futuras consecuencias negativas. -J Denisse Huerta Cortes
3.1. Riesgos relacionados con el fracaso de implementar todas las características necesarias.
3.2. Riesgos relacionados con versiones anteriores.
3.3. Riesgos relacionados con el presupuesto y con las restricciones de los recursos.
4. • Falla: Desviación del componente o el sistema de su prevista entrega, servicio o resultado.
5. • Calidad: El grado en el cual un componente, un sistema o un proceso cumple los requisitos
5.1. Calidad desde el enfoque de pruebas puede ser la conformidad con el uso
5.1.1. Desde el enfoque de pruebas calidad tambien puede ser la conformidad con los requisitos
6. OSWALDO RODRÍGUEZ
7. Ángel Guillermo Hernández Zambrano
8. Pre-condiciones
9. Ejemplos de Pruebas en el software. -J. Denisse Huerta Cortes
9.1. Objetivo de la prueba: Una Rozon o propósito para el diseño y la ejecución de una prueba.
9.1.1. Pruebas unitarias: se podrían encontrar defectos en las partes individuales del sistema sometidos a pruebas antes de que las partes estén totalmente integradas al mismo.
9.1.2. Pruebas de aceptación: usualmente es un problema si encontramos defectos, mas bien se quiere demostrar que el producto esta casi listo para su despliegue.
9.1.3. Pruebas de sistema: es posible que se quiera encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad.
9.1.4. Pruebas de integración: defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan.
9.1.5. Pruebas de mantenimiento: se podrían estar buscando especialmente un tipo particular de defecto, aquellos introducidos durante el desarrollo de los cambios.
9.1.6. Pruebas operativas: se busca un tipo particular de defecto, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento.
9.2. Ejemplos de Pruebas en el software. -J. Denisse Huerta Cortes
9.2.1. Objetivo de la prueba: Una Rozon o propósito para el diseño y la ejecución de una prueba.
9.2.1.1. Pruebas unitarias: se podrían encontrar defectos en las partes individuales del sistema sometidos a pruebas antes de que las partes estén totalmente integradas al mismo.
9.2.1.2. Pruebas de aceptación: usualmente es un problema si encontramos defectos, mas bien se quiere demostrar que el producto esta casi listo para su despliegue.
9.2.1.3. Pruebas de sistema: es posible que se quiera encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad.
9.2.1.4. Pruebas de integración: defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan.
9.2.1.5. Pruebas de mantenimiento: se podrían estar buscando especialmente un tipo particular de defecto, aquellos introducidos durante el desarrollo de los cambios.
9.2.1.6. Pruebas operativas: se busca un tipo particular de defecto, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento.
10. Diseño de alto nivel
11. Diseño de bajo nivel
12. Código
13. Software ejecutable
14. Tomando en cuenta se toman el modelado de lo que desea el cliente, desarrollando cada uno de los esquemas(Diagramas, Casos de Uso etc).
15. Desarrollo y pruebas durante la codificación de Back/FrontEnd del software
16. Producto terminado(Proceso posterior) Mantenimiento y escalabilidad del software
17. Pruebas de caja negra
18. Es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.Luis Antonio Bautista Rendón
18.1. Tomando en cuenta estos dos caso debe solidarse con el siguiente flujo de pruebas del ciclo de vida del Sw
19. se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. Luis Antonio Bautista Rendón
20. Pruebas de caja blanca
21. Programas de Pruebas automatizadas
22. Son programas que permiten ejecutar cadenas de acciones como clicks e inserción de datos de forma automatica despues de configurarlas una vez sirven para ahorrar tiempo pues se pueden añadir eventos a las pruebas ya guardadas. Luis Antonio Bautista Rendon
23. Casos de prueba
24. BASE DE PRUEBA
24.1. Documentación en la que se basan los casos de prueba. (Luis Alejandro Barreto Quintana)
24.1.1. REQUISITO
24.1.1.1. Codición o capacidad necesitada por un cliente o usuario para lograr un objetivo que debe poseer un sistema o componente (Luis Alejandro Barreto Quintana)
24.1.1.2. Necesarios para cumplir con un contrato, estándar, especificación u otro documento formal escrito. (Luis Alejandro Barreto Quintana)
24.1.2. INCIDENCIA
24.1.2.1. Cualquier evento que sucede y se necesita de su investigación. (Luis Alejandro Barreto Quintana)
24.1.3. POLÍTICAS DE PRUEBAS
24.1.3.1. Documento de alto nivel que describen los principios, métodos y objetivos principales de la organización respecto a las pruebas. (Luis Alejandro Barreto Quintana)
24.1.4. DATOS DE PRUEBA
24.1.4.1. Datos que existen antes que una prueba sea ejecutada. (Luis Alejandro Barreto Quintana)
24.1.4.1.1. Afectan al sistema o al componente sometido a las pruebas o son afectados por estos. (Luis Alejandro Barreto Quintana)
24.1.5. OBJETIVO DE PRUEBA
24.1.5.1. Razón o propósito para el diseño y la ejecución de una prueba. (Luis Alejandro Barreto Quintana)
25. Plan de pruebas de aceptación
26. un conjunto de condiciones o variables bajo las cuales un analista determinará si una aplicación, un sistema software (software system), o una característica de éstos es parcial o completamente satisfactoria Luis Antonio Bautista Rendón
27. Documento importante que contempla todas las pruebas necesarias para el sistema se basa en los requerimientos del sistema. Luis Antonio Bautista Rendón
28. Prueba fallida
29. Si en la ejecución de una prueba no se cumple el requisito para completar la prueba se considera que es una prueba fallida Luis Antonio Bautista Rendón
30. Test frameworks
31. Los test frameworks son parecidos a los anteriores automatizan las pruebas pero con la diferencia que es una herramienta en las que las pruebas se programan en vez de seguir el proceso mediante el uso del sistema.Por ejemplo jest Luis Antonio Bautista Rendón
32. Equipo de pruebas
33. Es el personal a cargo de realizar la documentación del plan de pruebas y de ejecutarlas a veces suele confundirse con el equipo de aseguramiento de calidad. Luis Antonio Bautista Rendón
34. Prueba exitosa
35. Si la ejecución de una prueba cumple con los requisitos de éxito de la misma esta se considera como una prueba exitosa .Luis Antonio Bautista Rendón
36. Equipo de aseguramiento de calidad
37. Es el personal que se encarga de verificar que todos los equipos sigan las normas al redactar la documentación y hagan buenas practicas para asegurar la calidad a menudo confundido con el equipo de pruebas. Luis Antonio Bautista Rendón
38. Regulaciones - Gustavo García Sánchez
38.1. Sarbanes-Oxley es una regulación que se promulgó en Estados Unidos con el propósito de monitorizar las empresas que cotizan en la bolsa de valores. (Gustavo García Sánchez)
39. Caso de Prueba - Gustavo García Sánchez
39.1. Es un conjunto de valores de entrada, pre-condiciones de ejecución, resultados esperados y pos-condiciones de ejecución. (Gustavo García Sánchez)
40. Herramientas de Testing - Gustavo García Sánchez
40.1. JMeter: Es una herramienta para intentar realizar pruebas de rendimiento. (Gustavo García Sánchez)
40.2. Selenium: Es una herramienta para hacer pruebas automatizadas. (Gustavo García Sánchez)
40.3. JUnit 5: Herramienta para hacer pruebas unitarias. (Gustavo García Sánchez)
40.4. TestNG: Este sirve como ejecutor de pruebas del Selenium. (Gustavo García Sánchez)
40.5. Bugzilla: Es una herramienta basada en Web desarrollada y usada por Mozilla. (Gustavo García Sánchez)
40.6. HP Quality Center: Es una herramienta de Micro Focus, desarrollado por Mercury Interactive y adquirido por HP posteriormente. (Gustavo García Sánchez)
40.7. Silik Central: Integra un Framework para mejorar la productividad, trazabilidad y visibilidad de todos los tipos de prueba de software. (Gustavo García Sánchez)
41. Defectos - Gustavo García Sánchez
41.1. Los defectos son carencias o falta de cualidades, en el software se encuentran debido a que alguien los colocó ahí, debido a una equivocación. (Gustavo García Sánchez)
42. Arquitectura Open-HMI Tester
42.1. Tiene como principal cometido el controlar los procesos de grabación y de reproducción,y el mantenimiento de los casos de pruebas.
43. Generación automática de test
43.1. Una ves identificadas las entradas del programa y los tipos de datos entrantes podemos generar tests ligados a dichos valores de forma automática, se presentarán tantos casos de prueba como tipos de entrada halla.
44. Funciona como macros que graba procesos de testeo que pueden varearse para obtener diferentes resultados
44.1. Si lo que varea es el ambiente de pruebas se tiene que volver a grabar un proceso de testeo, esto funge como una debilidad de la arquitectura.
45. Generación a tres pasos (Descritas por Alejandro López) *Anotación de la GUI *Generación Automática de Casos de Prueba *Ejecución y Validación
46. VENTAJAS Se ahorran gastos de manufactura de pruebas por cada módulo ya que con la definición de valores de entrada podemos generar tantos casos como sean necesarios para las pruebas.
47. DESVENTAJAS El elemento puede ahorrarnos tiempo, pero si persisten cambios en los planes de prueba, se tienen que modificar las variables de entrada, esto provoca pequeños retrasos en la implementación del test
48. UNA DEBILIDAD de esta arquitectura es el sistema de ventanas de una aplicación, en caso de ser demasiadas, se torna complicado definir tantos entornos de pruebas como variables a testear en la aplicación.
48.1. Una arquitectura definida para probar GUIs pretende solucionar dicho problema definiendo un conjunto de entradas y funcionando como librería de la cual dispondremos de sus herramientas
49. Pruebas a GUIs Alexis Herrera Ramirez
50. Gracias a las historias de usuario se puede realizar pruebas en XP
51. Pruebas en el Software Ricardo Ascencio F
51.1. Actividades que se realizan para detectar posibles fallas en un programa o aplicación
51.2. Pruebas en las GUI
51.2.1. Sub conjunto de las pruebas en el Software que aseguran el correcto funcionamiento en las GUI
51.2.2. GUI (Graphic User Interface) Es el intermediario entre el usuario y un Programa/ Aplicación
51.2.3. Son un paso crítico antes de aceptar un producto final
52. Enfoque tradicional de pruebas: Carlos A Galván
52.1. Requisitos ->
52.1.1. Análisis y diseño ->
52.1.1.1. Implementación ->
52.1.1.1.1. Pruebas: unitaria, integración, sistema y aceptación ->
53. El testing exhaustivo es imposible. Probar absolutamente todas las permutaciones posibles de un sistema no es factible, excepto para casos muy triviales.
54. BERENICE VILLAFUERTE ZAVALA "PRUEBA" ÁGIL VS TRADICIONAL.
54.1. Convencional --> Deja las pruebas hasta el final.
54.2. Ágil --> Prueba cada sprint para poder continuar, minimizando el costo de fallas y errores.
55. • Depuración: El proceso de encontrar, analizar y retirar las causas de las fallas en el software.
56. Proceso Básico de Pruebas en el Software. -Miguel Kevin Rodriguez M.
57. Existen infinitas formas de probar un sistema terminado
58. 1 .Planificación y Control de Pruebas.
59. 3 .Implementacion de las Pruebas
60. 4. Evaluación de Pruebas
61. 5. Cierre de las Pruebas
62. Es el proceso en el cual se definen los objetivos, alcance, herramientas, riesgos, de cada set de pruebas que se desea implementar, así como su priorizacion y monitorizacion de estas, como implementarlas y ejecutarlas en un software.
63. Condiciones
64. Proceso en donde se contempla los escenarios funcionales, no funcionales y críticos de cada requerimiento en un documento de set de pruebas obteniendo los datos que serán utilizados para ejecutar las pruebas.
65. Estos deben tomarse en consideración a las necesidades del cliente(Empresa) a desarrolla el sistema o aplicación
66. Principios de las pruebas Juan José Martínez Paniagua
66.1. Las pruebas demuestran la presencia de defectos (pero no demuestran su ausencia)
66.2. Las pruebas tempranas ayudan a prevenir defectos y ahorrar dinero
66.3. La falacia de la ausencia de errores (es decir, el intento de probar la calidad del sistema al final).
66.4. El agrupamiento de defectos ocurre ya sea si sabe acerca de ello o no
66.5. La paradoja del pesticida. Imaginar que ejecutamos los mismos tests una y otra vez sobre una parte ciertamente estable de nuestro sistema
67. Es el proceso en el cual se realiza la ejecución de los set de prueba funcionales, no funcionales y los desarrollados por los analistas en el orden de prioridad establecido verificando que el entorno de pruebas a sido instalado correctamente
68. Proceso en el que se analizan y verifican que los resultados de las pruebas se encuentren dentro de los objetivos y alcance definidos durante la etapa de planeacion y control de las pruebas del software.
69. Pruebas En metodologías ágiles Juan José Martínez Paniagua
69.1. XP(Extreme Programing): Se hacen lo que se llaman historias de usuario y cada historia de usuario, entre otras cosas, lleva asociada una lista de criterios de aceptación y, para cada criterio de aceptación, se define el conjunto de casos de prueba necesarios para validar el criterio de aceptación.
69.2. TDD: cada requisito se representa como un artefacto denominado historia de usuario al que se le asocian sus correspondientes pruebas unitarias. Cuando se aplica TDD, en primer lugar define el repositorio de historias de usuario, conocido como “Product backlog”, que representa los requisitos del sistema.
69.3. ATDD: Cada historia de usuario tiene asociados un conjunto de criterios de aceptación. Posteriormente, para cada criterio de aceptación se definen las pruebas de aceptación que se deben superar. Una vez que las pruebas de aceptación están claramente definidas, el equipo de desarrollo comienza a escribir el código fuente que es necesario para superar los criterios de aceptación
69.4. Las metodologías ágiles y particularmente Extreme Programming (XP), son de alguna manera los responsables del aumento de popularidad de las pruebas de software. Carlos A Galván
69.5. Aunque en las metodologías convencionales las pruebas son importantes, estás dependen directamente del resto de actividades del proceso de desarrollo. Carlos A Galván
69.6. En los enfoques ágiles las pruebas son el centro de la metodología y, por lo tanto son ellas las que dirigen el proceso de desarrollo. Carlos A Galván
69.7. Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más, sino que abogan porque las prácticasny el desarrollo est+en completamente integradas. Carlos A Galván
70. Proceso en donde se identifican si los productos de software pueden ser puestos en producción, cerrando informes y definiendo planes de acción en caso de futuras incidencias en el producto de software.
71. Pruebas de Software Miguel Kevin Rodriguez M.
71.1. Prueba de Estabilidad
71.1.1. Es una prueba que se ejecuta durante mas de 24 horas para determinar si la aplicación puede aguantar una carga esperada continua.
71.2. Prueba de Carga
71.2.1. Es el tipo de prueba relacionado con la medida del comportamiento de un componente o sistema con una carga creciente ya sea el numero de usuarios o un numero de transacciones.
71.3. Pruebas de regresion
71.3.1. Tipo de Pruebas de un programa previamente probado a raíz de sus modificaciones para garantizar la calidad del software
71.4. Prueba de Estres
71.4.1. Esta tipo de prueba evalúa la robustez y confiabilidad del software sometiéndolo a condiciones de uso extremas saturando el programa hasta llegar a un punto de quiebre
71.5. Prueba de Portabilidad
71.5.1. Es un tipo de prueba que verifica que el software pueda ser ejecutado en diferentes plataformas y/o sistemas operativos
72. Pruebas en metodologías tradicionales Juan José Martínez Paniagua
72.1. Las pruebas en las metodologías convencionales se basa en la definición de los casos de prueba en función de unos requisitos previamente establecidos, mediante los lenguajes adecuados, por ejmeplo XUnit, FIT, o similares. Por lo tanto, el objetivo principal es comprobar que el desarrollo realizado cumple los requisitos definidos.
73. Aplicación de la arquitectura Open - HMI Tester. Adrian Lopez Valdes
73.1. Herramienta de captura y reproducción para pruebas de interfaz grafica. La cual se centra en capturar la interacción del usuario con la aplicación.
73.1.1. El desarrollo de las GUI acaparan el 60% de la codificación de un sistema
73.2. uUNA
73.2.1. De igual forma se esta trabajando en la generación automática del Test y procesos de validación de las interfaces de usuario.
73.3. Data Model Manager. Alejandro García Barajas
74. OHT: Generación automática de test y procesos de validación. -Samuel Alejandro López
74.1. Es una de las aplicaciones principales para OHT. Aplicar pruebas a las GUI generadas automáticamente.
74.1.1. Elementos
74.1.1.1. Casos de uso
74.1.1.1.1. Describe el comportamiento de la GUI.
74.1.1.2. Anotaciones
74.1.1.2.1. Describe las posibles variaciones que afectarían o influirían en el funcionamiento de la GUI.
74.1.1.2.2. Contiene una serie de reglas que comprobarán propiedades de los elementos.
74.1.2. Fases
74.1.2.1. Anotación de la GUI
74.1.2.1.1. Es la creación del elemento 'anotaciones' mencionado previamente.
74.1.2.2. Generación automática de los casos de pruebas
74.1.2.2.1. Se genera un caso de prueba para cada posible combinación de valores.
74.1.2.2.2. Crea validaciones para satisfacer las reglas establecidas en las anotaciones.
74.1.2.3. Ejecución y validación
74.1.2.3.1. Ejecuta los casos de prueba del paso anterior.
74.1.2.3.2. Se basa en implementar test oracles. Principalmente los siguientes tres tipos.
75. Representan un elemento fundamental y crítico de las aplicaciones de hoy en día, llegando a acaparar incluso hasta el 60 % del código. Alejandro García Barajas.
75.1. Tiene como principal objetivo, controlar los procesos de grabación y de reproducción. Alejandro García Barajas.
75.1.1. Estos módulos permiten integrar en la arquitectura Open-HMI Tester la implementación de cualquier representación del modelo de datos. Alejandro García Barajas.
76. 2 . Análisis y diseño
77. Interfaces Gráficas de Usuario (GUI)
78. Arquitectura OHT. Alejandro García Barjas
79. HMI Tester, encargado del control de procesos. Alejandro García Barajas.
80. Modulo Preload Modulo inyectado en la aplicación testada. Alejandro Garcia Barajas
81. Preloading Action Module. Alejandro García Barajas.
82. El principal objetivo de este módulo es llevar a cabo el proceso de precarga, permitiendo la inyección del Módulo Preload al lanzar la aplicación a testar. Alejandro García Barajas
83. Técnica de Prueba Blanca "Cobertura lógica" Berenice Villafuerte Zavala
83.1. Sentencias
83.2. Desiciones
83.3. Condiciones
83.4. Desición/Condición
83.5. Multiple desición
83.6. Toda p
84. Pruebas de ALTO NIVEL Berenice Villafuerte Zavala
84.1. Pruebas alfa :Conducidas por cliente en lugar de desarrollo El equipo registra las anomalías.
84.2. Pruebas beta: Se distribuye el producto a potenciales usuarios Estos prueban el producto e informan de los fallos detectados.
84.3. Pruebas de aceptación: El cliente certifica que el sistema es válido para él Utilizar el plan de aceptación existente.
84.4. Pruebas de instalación: Buscar fallos en la instalación del sistema en un entorno concreto.
85. En SWEBOOK, las pruebas se presentan como una actividad que se desarrolla para evaluar la calidad de un producto y mejorarlo mediante la identificación de los defectos y problemas. Carlos A Galván
85.1. Pru
86. PRUEBAS EN ENFOQUES CONVENCIONALES Oscar Vallejo T.
86.1. Metodologias Convencionales
86.2. Enfoque de las Pruebas en Metodologias Convencionales
86.2.1. En estas metodologías se presta especial atención a la elaboración de la especificación de requisitos software
86.2.2. Se basa en la definición de los casos de prueba en función de unos requisitos previamente establecidos, mediante los lenguajes adecuados, por ejmeplo XUnit, FIT o similares
86.3. Objetivo de las Pruebas Convencionales
86.3.1. Comprobar que el desarrollo realizado cumple los requisitos definidos.
86.4. Porcentaje de Pruebas Convencionales en Proyectos
86.4.1. 70% de los proyectos desarrollados, disponen de procesos de pruebas documentados
86.4.2. 80% de los proyectos disponen de planes de pruebas detallados, casos de prueba, etc
87. Ejemplo Pruebas Jonathan Alejandro Colin Medina
87.1. Un programa acepta tres enteros que representan las longitudes de los lados de un triángulo. Éste da como resultado “escaleno” (lados no iguales), “isósceles” (dos lados iguales), o “equilátero” (tres lados iguales).
87.1.1. Acciones y datos a probar
87.1.1.1. UN CASO DE PRUEBA CON A,B,C NO NUMERICOS
87.1.1.1.1. UN MENSAJE DE ERROR
87.1.1.2. PARTICIÓN DEL TRIANGULO ESCALENO
87.1.1.3. 2.3.4
87.1.1.3.1. ESCALENO
87.1.1.4. 0,1,2
87.1.1.4.1. UN MENSAJE DE ERROR
87.1.1.5. PARTICION DEL TRIANGULO ISOCELES
87.1.1.6. 2,2,1
87.1.1.6.1. ISOSCELES
87.1.1.7. 2,2,0
87.1.1.7.1. UN MENSAJE DE ERROR
87.1.1.8. 1,1,1
87.1.1.8.1. EQUILATERO
87.1.1.9. 0,0,0
87.1.1.9.1. UN MENSAJE DE ERROR
88. LAS PRUEBAS EN LAS METODOLOGIAS AGILES Oscar Vallejo T.
88.1. Historias de Usuario
88.1.1. Representan de una forma particular los requisitos del sistema
88.2. Metodologías
88.2.1. ATDD
88.2.1.1. Se basa en las pruebas de aceptación. Este enfoque toma como punto de referencia al usuario.
88.2.2. TDD
88.2.2.1. Cada requisito se representa como un artefacto denominado historia de usuario al que se le asocian sus correspondientes pruebas unitarias
88.3. Entornos de Integración Continua
88.3.1. Es necesario disponer de una mínima infraestructura que permita automatizar la ejecución del elevado número de pruebas que se diseñan y la toma de medidas que permitan conocer el nivel de calidad que está alcanzando el desarrollo
88.4. Enfoques Agíles
88.4.1. Las pruebas son el centro de la metodología y, por lo tanto son ellas las dirigen el proceso de desarrollo
88.4.2. Pruebas de Regresion
88.4.2.1. Se realizan despues de anexar una nueva funcionalidad con el fin asegurar que no se ha introducido ningún error nuevo en el sistema
88.5. Responsables de su Aplicación
88.5.1. Los ingenieros de desarrollo los encargados de ejecutar este tipo de pruebas mediante pruebas unitarias
89. Ejemplo de pruebas Mario Valentin Ochoa Mota
89.1. En base al siguiente código en Golang
89.1.1. func Reverse(s string) string { r := []rune(s) for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 { r[i], r[j] = r[j], r[i] } return string(r) }
89.1.1.1. func TestReverse(t *testing.T) { for _, c := range []struct { in, want string }{ {"Hello, world", "dlrow ,olleH"}, {"Hello, 世界", "界世 ,olleH"}, {"", ""}, } { got := Reverse(c.in) if got != c.want { t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want) } } }
89.1.1.2. La prueba que es necesaria es comprobar que la cadena que se ingresa se tranformada a su inverso. Gracias a que es un lenguaje tipado no es necesario comprobar el valor de entrada ya que siempre va a ser una cadena