2. ¿Y QUÉ SE ENTIENDE POR PRUEBAS?
Mecanismo de detección de:
Errores Regresiones
3. ¿Y QUÉ SE ENTIENDE POR PRUEBAS?
Partes del código Facilita la
que no se utiliza refactorización
4. ¿POR QUÉ UTILIZAR PRUEBAS?
Arreglar problemas pequeños cada pocas horas
toma menos tiempo que arreglar problemas
enormes justo antes de la fecha limite.
5. ¿POR QUÉ UTILIZAR PRUEBAS?
Permiten descubrir errores cometidos sin
darse cuenta tanto en el diseño como en la
construcción del software.
6. ¿POR QUÉ UTILIZAR PRUEBAS?
Verificación: ¿Estamos construyendo el
producto correctamente?
Validación: ¿Estamos construyendo el
producto correcto?
8. AGRUPACIÓN DE PRUEBAS
1. Pruebas unitarias
○ Unidades de software: Clases, Modelos,
Helpers
2. Pruebas de integración
○ Módulos del sistema
3. Pruebas del sistema
○ El sistema en su integridad, interacción del
usuario
9. TECNOLOGÍA
Te
ec Selenium
stu
Rsp
ni
t
s
o nj
nt
P ha Fabricator
b kit
a- we
r
y ba
Faker C ap
Cucumber
10. PRUEBAS UNITARIAS
Ej. Guardar la dirección a partir de georefenciación
class Report
field :address, :type => String
...
def localize(lat, long)
self.address = GeoDataService.address(lat, long)
self.save
end
end
11. PRUEBAS UNITARIAS
describe "Report Model" do
let(:report) { Report.new }
class GeoDataService
def address(lat, long)
Faker::Address.street_address
end
end
...
end
12. Pruebas unitarias UNITARIAS
PRUEBAS
it "Should save the address field" do
GeoDataService.should_receive(:address).
with('4.630024', '-74.094973').
and_return('Carrera 42 # 22BIS-2')
report.localize('4.630024', '-74.094973')
report.address.should == "Carrera 42 # 22BIS-2"
end
13. Pruebas unitarias UNITARIAS
PRUEBAS
Test Unit
class TestDeMates < Test::Unit::TestCcase
def test_suma
assert_equal 4, Mates.run("2+2")
assert_equal 4, Mates.run("1+3")
assert_equal 5, Mates.run("5+0")
assert_equal 0, Mates.run("-5 + 5")
end
end
14. PRUEBAS DE INTEGRACIÓN
describe ReportsController do
let(:report) { Fabricate(:report) }
describe "GET index" do
it "Should render the reports index" do
get :index
assigns[:reports].should == [report]
response.should render_template('index')
end
end
15. PRUEBAS DEL SISTEMA
describe "the signup process", :type => :request do
let(:user) { Fabricate(:user, :email => 'user@example.
com', :password => 'caplin')}
it "signs me in" do
within("#session") do
fill_in 'Login', :with => 'user@example.com'
fill_in 'Password', :with => 'password'
end
click_link 'Sign in'
end
end
16. ¿QUÉ SE DEBE TENER EN CUENTA?
Eliminar comportamientos aleatorios
17. ¿QUÉ SE DEBE TENER EN CUENTA?
No depender de la anterior ni de la siguiente
18. ¿QUÉ SE DEBE TENER EN CUENTA?
Funcionar sin conexión a red
19. ¿QUÉ SE DEBE TENER EN CUENTA?
Deben ser independientes del momento en que
se ejecutan
20. ¿QUÉ SE DEBE TENER EN CUENTA?
No detallar cada uno de los pasos de tu
metodo
no decir cómo, sino qué hace
22. Test Driven Development (TDD)
Escribir las pruebas primero, luego
implementación y refactorización.
23. Test Driven Development (TDD)
"El propósito del desarrollo guiado por pruebas es
lograr un código limpio que funcione. La idea es que
los requisitos sean traducidos a pruebas, de este
modo, cuando las pruebas pasen se garantizará el
software cumple con los requisitos que se han
establecido."
Wikipedia
24. VENTAJAS TDD
● Evita escribir código innecesario
● Aplicación de mejor calidad en menos tiempo
● Permite al programador centrarse en la tarea
actual
25. BEHAVIOR DRIVEN DEVELOPMENT
(BDD)
Versión mejorada de TDD que responde las
inquietudes, tales como:
● Cuando iniciar el proceso
● Que probar y qué no probar
26. BDD BDD
Scenario: Create a post under a category
Given a category exists
And I am signed in as an admin
When I go to create a new post
And I select "Category 1" from "Categories"
And I press "Create"
And I go to view all posts
Then I should see a post with the category
"Category 1"
