• Save
Curso TDD Ruby on Rails #01: Introducción al testing
Upcoming SlideShare
Loading in...5
×
 

Curso TDD Ruby on Rails #01: Introducción al testing

on

  • 2,800 views

Lección 01 del curso de TDD en Ruby on Rails:

Lección 01 del curso de TDD en Ruby on Rails:
Introducción al concepto de testing.

Statistics

Views

Total Views
2,800
Views on SlideShare
2,783
Embed Views
17

Actions

Likes
4
Downloads
0
Comments
0

3 Embeds 17

http://www.slideshare.net 12
http://www.linkedin.com 3
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Curso TDD Ruby on Rails #01: Introducción al testing Curso TDD Ruby on Rails #01: Introducción al testing Presentation Transcript

  • 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
  • SOBRE MÍ: CONTACTO Email: alberto.perdomo@aentos.es Twitter: @albertoperdomo WEB: http://albertoperdomo.net http://www.aentos.com
  • 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
  • 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
  • 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”.
  • 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”
  • 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]
  • EL COSTE DE LOS ERRORES 150x [AOOP] COSTE RELATIVO DE ARREGLAR UN ERROR 10x 5x 1x REQ. DISEÑO IMPLEM. OPER.
  • EL PROCESO DEL DESARROLLO CLÁSICO REQUISITOS DISEÑO IMPLEMENTACIÓN PRUEBAS / VALIDACIÓN MANTENIMIENTO
  • 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
  • DESARROLLO WEB ÁGIL FUNCIONALIDAD n FUNCIONALIDAD n+1 DISEÑO DISEÑO IMPLEMENTACIÓN IMPLEMENTACIÓN PRUEBAS / VALIDACIÓN PRUEBAS / VALIDACIÓN DESPLIEGUE DESPLIEGUE
  • ¿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?
  • ¿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
  • TIPOS DE PRUEBAS de integración de sistema de carga unitarias de validación de regresión de aceptación funcionales
  • 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
  • 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
  • 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
  • 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?
  • PRUEBAS MANUALES → Repetir todas las pruebas en cada despliegue → Consumen mucho tiempo → Aburridas y mecánicas “Monkey testing”
  • 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
  • PRUEBAS AUTOMATIZADAS vs MANUALES Automatizadas más rentables con el tiempo → Reusables Coste $$$ Tiempo
  • 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)
  • 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
  • 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
  • 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
  • ¿QUIERES SER UN COWBOY? LOS PISTOLEROS DISPARAN SIN PESTAÑEAR Y SIEMPRE SE LA JUEGAN
  • ¿PREGUNTAS? Video: Waterfall vs. Agile