Curso TDD Ruby on Rails #01: Introducción al testing
5 recomendaciones1,710 vistas
Este documento presenta un curso de pruebas de software (testing) que se llevará a cabo del 12 al 16 de abril de 2010. Incluye información sobre el instructor, Alberto Perdomo, así como sobre conceptos clave relacionados con el testing como los tipos de pruebas, la importancia de automatizar las pruebas y especificar el comportamiento deseado a través de las pruebas.
![EL TÉRMINO “BUG” I
“It has been just so in all of my inventions. The frst
step is an intuition, and comes with a burst, then
difculties arise — this thing gives out and [it is] then
that 'Bugs' — as such little faults and difculties are
called — show themselves and months of intense
watching, study and labor are requisite before
commercial success or failure is certainly reached.”
Thomas Edison, 1878](https://image.slidesharecdn.com/01introduccion-100419105952-phpapp02/85/Curso-TDD-Ruby-on-Rails-01-Introduccion-al-testing-4-320.jpg)
![EL TIEMPO QUE INVERTIMOS EN
BUSCAR ERRORES
“If you look at how most programmers spend their time, you'll fnd that writing
code is actually a small fraction. Some time is spent fguring out what ought to be
going on, some time is spent designing, but most time is spent debugging. […]
Fixing the bug is usually pretty quick, but fnding it is a nightmare.”
Refactoring, Martin Fowler [Ref]](https://image.slidesharecdn.com/01introduccion-100419105952-phpapp02/85/Curso-TDD-Ruby-on-Rails-01-Introduccion-al-testing-7-320.jpg)
![EL COSTE DE LOS ERRORES
150x
[AOOP]
COSTE RELATIVO DE ARREGLAR UN ERROR
10x
5x
1x
REQ. DISEÑO IMPLEM. OPER.](https://image.slidesharecdn.com/01introduccion-100419105952-phpapp02/85/Curso-TDD-Ruby-on-Rails-01-Introduccion-al-testing-8-320.jpg)
Curso TDD Ruby on Rails #01: Introducción al testing
- 1. CURSO DE TESTING OSL 12 – 16 DE ABRIL 2010 Introducción Alberto Perdomo Web: http://albertoperdomo.net Email: alberto.perdomo@aentos.es Twitter: @albertoperdomo http://www.aentos.com
- 2. SOBRE MÍ: CONTACTO Email: alberto.perdomo@aentos.es Twitter: @albertoperdomo WEB: http://albertoperdomo.net http://www.aentos.com
- 3. SOBRE MÍ: TRAYECTORIA Uni Karlsruhe, Alemania Ing. Electrónica y Tecnología FOTON, de la Información LAS PALMAS MEDIA LAB AENTOS, EUROPE, IRLANDA LAS PALMAS 1996 2003 2005 2007 DEPt. DEPt. TEST de SOFTWARE SISTEMA - VEHICULOS - PFC SIEMENS MERCEDES, AUTOMATIZACION ALEMANIA PASCAL JAVA PYTHON C/C++ C/C++ C/C++ RUBY / RUBY ON RAILS 1996 2003 2005 2007
- 4. EL TÉRMINO “BUG” I “It has been just so in all of my inventions. The frst step is an intuition, and comes with a burst, then difculties arise — this thing gives out and [it is] then that 'Bugs' — as such little faults and difculties are called — show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.” Thomas Edison, 1878
- 5. EL TÉRMINO “BUG” II → 9 de Septiembre de 1945 → Universidad de Harvard → Los operadores retiran una polilla de uno de los relés del calculador “Mark II Aiken”. → “First actual case of bug being found”.
- 6. EL CASO ARIANE 5 → 4 de Junio de 1996 → Vuelo 501 del cohete Ariane 5 → 40 segundos después de entrar en secuencia de vuelo el Ariane 5 se autodestruye a una altura de 3700m → Motivos: análisis y pruebas insufcientes del sistema de referencia inercial y el sistema de control de vuelo. → Causa: conversión de un número demasiado grande → “overfow”
- 7. EL TIEMPO QUE INVERTIMOS EN BUSCAR ERRORES “If you look at how most programmers spend their time, you'll fnd that writing code is actually a small fraction. Some time is spent fguring out what ought to be going on, some time is spent designing, but most time is spent debugging. […] Fixing the bug is usually pretty quick, but fnding it is a nightmare.” Refactoring, Martin Fowler [Ref]
- 8. EL COSTE DE LOS ERRORES 150x [AOOP] COSTE RELATIVO DE ARREGLAR UN ERROR 10x 5x 1x REQ. DISEÑO IMPLEM. OPER.
- 9. EL PROCESO DEL DESARROLLO CLÁSICO REQUISITOS DISEÑO IMPLEMENTACIÓN PRUEBAS / VALIDACIÓN MANTENIMIENTO
- 10. EL MANIFIESTO ÁGIL 4 Principios: → Valorar más a los individuos y su interacción que a los procesos y las herramientas → Valorar más el software que funciona que la documentación exhaustiva → Valorar más la colaboración con el cliente que la negociación contractual → Valorar más la respuesta al cambio que el seguimiento de un plan
- 11. DESARROLLO WEB ÁGIL FUNCIONALIDAD n FUNCIONALIDAD n+1 DISEÑO DISEÑO IMPLEMENTACIÓN IMPLEMENTACIÓN PRUEBAS / VALIDACIÓN PRUEBAS / VALIDACIÓN DESPLIEGUE DESPLIEGUE
- 12. ¿QUÉ ES EL TESTING? I Testing = Pruebas de software Preguntas: → ¿El código que acabo de escribir funciona bien? → ¿El software hace lo que el cliente desea? → ¿El software continúa funcionando bien después del último cambio que he introducido?
- 13. ¿QUÉ ES EL TESTING? II Objetivos → Detectar errores (cuanto antes mejor) → Validar que el software hace lo que debe → Especifcación → Confanza y seguridad → Ahorrar tiempo de trabajo
- 14. TIPOS DE PRUEBAS de integración de sistema de carga unitarias de validación de regresión de aceptación funcionales
- 15. TIPOS DE PRUEBAS: UNITARIAS prueban el correcto funcionamiento de un módulo de código CLASE DATOS DE PRUEBA RESULTADOS ÁREA: 7 P. EJ. MÉTODO ÁREA LADO A: 2 DE UN RECTÁNGULO ≠ LADO B: 4 =? RESULTADOS ESPERADOS ÁREA: 8
- 16. TIPOS DE PRUEBAS: DE ACEPTACIÓN prueban el comportamiento desde el punto de vista del cliente Scenario: Login with correct credentials When I go to the login page And I fill in "Login" with "manfred" And I fill in "Password" with "gurke" And I press "Login" Then I should see "Logged in" And I should be on the homepage Scenario: Login with incorrect credentials When I go to the login page And I fill in "Login" with "manfred" And I fill in "Password" with "tomate" And I press "Login" Then I should see "Wrong username/password" And I should be on the login page
- 17. TIPOS DE PRUEBAS: DE REGRESIÓN Regresión → error ya resuelto que vuelve a aparecer Funcionamiento → cuando surge un error escribes una prueba para demostrar que falla y arreglas el error. La prueba garantizará que el error no vuelva a aparecer
- 18. TIPOS DE PRUEBAS: DE CARGA → ¿Cómo responderá el sistema cuando entre en producción con 25.000 usuarios y 50.000 visitas diarias? → ¿Cuáles son los cuellos de botella? → ¿Que partes de la aplicación hay que optimizar?
- 19. PRUEBAS MANUALES → Repetir todas las pruebas en cada despliegue → Consumen mucho tiempo → Aburridas y mecánicas “Monkey testing”
- 20. PRUEBAS AUTOMATIZADAS ¿Por qué? → Tiempo = $$$ → Automatizar = Ahorrar tiempo = Ahorrar $$$ Deben ser → Reusables = rentables → Robustas para que no se dañen con facilidad al modifcar el código
- 21. PRUEBAS AUTOMATIZADAS vs MANUALES Automatizadas más rentables con el tiempo → Reusables Coste $$$ Tiempo
- 22. PRUEBAS AUTOMATIZADAS vs MANUALES II Ejemplo: Probar manualmente un formulario de registro Probar 1 vez Probar 50 veces Manual 2-4 minutos 100 a 200 minutos 5 – 30 minutos ~ 5 – 30 minutos (escribir el test) (escribir el test) Automatizada 10 seg. + (ejecutarlo) 8 minutos (ejecutarlo 50 veces)
- 23. REFACTORIZAR CÓDIGO Cambiar el diseño SIN cambiar el comportamiento → Usualmente motivado por el “mal olor” del código Objetivos: → Aumentar la legibilidad → Reducir la complejidad → Mejorar la mantenibilidad
- 24. PRUEBAS: CONFIANZA Y SEGURIDAD Sentirnos seguros → de que lo estamos haciendo bien → poder refactorizar Sentir y dar confanza a los demás → funcionamiento correcto demostrable
- 25. PRUEBAS: ESPECIFICACIÓN Las pruebas defnen cómo se debe comportar el código y la aplicación → Las pruebas sirven como especifcación → Cuando un nuevo desarrollador se incorpora al equipo o toma el relevo tiene las pruebas y conoce el comportamiento deseado
- 26. ¿QUIERES SER UN COWBOY? LOS PISTOLEROS DISPARAN SIN PESTAÑEAR Y SIEMPRE SE LA JUEGAN
- 27. ¿PREGUNTAS? Video: Waterfall vs. Agile