Este documento habla sobre pruebas unitarias. Explica que una prueba unitaria comprueba un método o función invocándolo y verificando sus suposiciones después. También cubre características como ser rápidas, aisladas y repetibles, y la estructura básica de preparar, actuar y afirmar. Además, discute cómo escribir código más testable y usar patrones de diseño y dobles de prueba.
En esta presentación te encuentras información sobre los operadores lógicos en JavaScript, aquí te encuentras el vídeo en youtube :https://www.youtube.com/watch?v=zV7-DPg-T2g
Employers need to be aware that decisions they are making now about the size and make-up of their workforce will affect whether they exceed the 50 employee threshold that triggers the "pay or play" penalty in the Affordable Care Act. This presentation will focus on strategies for avoiding or minimizing exposure to the penalties under the Act.
En esta presentación te encuentras información sobre los operadores lógicos en JavaScript, aquí te encuentras el vídeo en youtube :https://www.youtube.com/watch?v=zV7-DPg-T2g
Employers need to be aware that decisions they are making now about the size and make-up of their workforce will affect whether they exceed the 50 employee threshold that triggers the "pay or play" penalty in the Affordable Care Act. This presentation will focus on strategies for avoiding or minimizing exposure to the penalties under the Act.
Slides de la charla "Carrera de fondo: la continuada lucha de AngularJS" realizada en el CodeMotion 2015 (Madrid). En ella se hace una introducción al desarrollo frontend, librerías más utilizadas y panorama actual.
Después de una breve introducción al funcionamiento de Backbone se realiza el desarrollo y la exposición de los conceptos del framework a nivel básico y medio.
Los ejemplos desarrollados para esta charla están alojados en github: https://github.com/semagarcia/angularjs-codemotion-2015
Slides de la charla "Carrera de fondo: la continuada lucha de AngularJS" realizada en el CodeMotion 2015 (Madrid). En ella se hace una introducción al desarrollo frontend, librerías más utilizadas y panorama actual.
Después de una breve introducción al funcionamiento de Backbone se realiza el desarrollo y la exposición de los conceptos del framework a nivel básico y medio.
Los ejemplos desarrollados para esta charla están alojados en github: https://github.com/semagarcia/angularjs-codemotion-2015
Con el uso de CDI, para la inyección de dependencias, y la consolidación de la plataforma Arquillian, ya no hay excusas en la plataforma Java EE para el desarrollo de pruebas.
Testing de Aplicaciones Móviles, Públicas, Masivas y CríticasBelatrix Software
Ser QA no es fácil. Existen diferentes aspectos a cubrir: funcionalidad, usabilidad, accesibilidad, performance, seguridad, entre otros. Si la aplicación es móvil, entonces hay que considerar: diferentes sistemas operativos y versiones, fabricantes de smartphones y la naturaleza de la construcción de la aplicación. En un contexto de Transformación Digital, donde el trabajo en equipo, el enfoque a usuario y el time-to-market son claves para triunfar, como QA, ¿cómo enfrentar esta gran suma de retos?
En esta presentación vamos a entender cuáles son los aspectos a considerar y retos que un QA debe superar si es el responsable de una aplicación pública, cuyo uso es 24/7 y cuyo fallo podría causar impactos negativos en la imagen de una organización en camino hacia la Transformación Digital.
VLCtesting 2013 - Comprobando y refutando las promesas del testing automatiza...Abstracta
http://www.vlctesting.es/
Es importante que los usuarios confíen en el software que desarrollamos, y no hay mejor camino que probándolo. Para probar software siempre se habla de que el testing automatizado es un camino para acelerar, ser más eficiente, reducir costos, reducir riesgos, aumentar productividad, aumentar la motivación del equipo, etc. Pero ¿todo eso es realmente cierto? En nuestra experiencia podemos decir que no siempre es completamente cierto. Si no enfocamos bien nuestros esfuerzos no lograremos cumplir con esas promesas. Entonces, ¿cómo hacemos testing automatizado en forma efectiva y eficiente? ¿Cómo hacemos que valga la pena? ¿Cómo lo hacemos para obtener el máximo beneficio? ¿No siempre es beneficioso automatizar pruebas? ¿Cómo decido cuándo sí y cuándo no?
Testear efectiva y eficientemente es un gran desafío, que siempre nos lleva a querer ver cómo mejorar la productividad en la búsqueda de la calidad. En esta charla veremos algunas buenas prácticas, lecciones aprendidas, consejos y observaciones que hemos tomado nota en nuestra experiencia dando servicios de pruebas, viendo así cómo enfocar nuestros esfuerzos para tener éxito en nuestras pruebas, haciendo reales, o lo más reales posible, esos beneficios que siempre nos prometen del testing automatizado. También compartiremos los problemas más comunes con los que nos enfrentamos a menudo, y las alternativas que hemos encontrado para solventarlos. Compartiremos la experiencia de proyectos en distintos dominios de aplicación (sector financiero, logística, venta y distribución, etc.), contextos y plataformas, con diversos clientes. Intentaremos mostrar cuándo creemos que sí es factible y beneficioso automatizar, y cuándo rotundamente no.
Esta es la presentación que he preparado para mis compañeros de @NITSNETS en la que explico la integración del testing a todos los niveles de un proyecto y profundizo un poco más en la aplicación práctica para un entorno basado en Laravel.
Vistazo a React (la librería JavaScript para UI), la arquitectura Flux y React Native. Se cuentan los fundamentos del "One Direction Data Flow": Como pensar como React y Flux y una introducción a React Native: la versión de React que permite crear aplicaciones Android y iOS usando JavaScript
Entender el significado real del testing en un entorno de desarrollo ágil plantea grandes retos. Es importante encontrar la mejor manera de agregar valor con conocimientos de conceptos básicos de pruebas funcionales y la comprensión de la arquitectura del producto que estamos probando.
Conversaremos sobre las consideraciones más importantes y daremos tips imperdibles que debes saber como ingeniero de calidad, para sobrevivir y destacar en un entorno ágil cada vez más creciente y competitivo.
l sistema de control de versión que más se ha extendido en los últimos años posiblemente sea Git. Algo que no ha pasado desapercibido para los desarrolladores de Microsoft. Así que han decidido integrarlo en todas sus herramientas. Y este hecho… Me ha destrozado la vida. ...
Charla sobre las capacidades de extensión de Roslyn para c#.net. Queremos profundizar como añadir adaptaciones para la sintaxis y semántica en los lenguajes .net, nuevas expresiones, generación de código , y como utilizar las extensiones en el IDE de Visual Studio. En la sesión se mostrará cómo realizar adaptaciones sobre Roslyn para extender el comportamiento del análisis sintáctico y semántico del código, y generación de código y añadir estas extensiones sobre Visual Studio, disponiendo de esta forma de nuevas capacidades sobre .net. Será una sesión más práctica que teórica, mostrando código y realizando la explicación sobre este.
Como desarrolladores tenemos que crear el mejor código posible; que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad.
Una buena forma de conseguir esta buena calidad en nuestras apps de UWP es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código; si las pruebas que realizan no aportan valor.
A lo largo de esta charla estudiaremos la mejor forma de probar el código de las apps Windows 10: Diferenciaremos entre los diferentes tipos de pruebas; sentaremos las bases de un buen unit test; aprenderemos a probar métodos asíncronos; usaremos visual studio; crearemos test doubles; y refactorizaremos para conseguir código "testeable", usando los patrones que más favorecen los tests, como es MVVM.
Comúnmente conocemos redis como un sistema de caché distribuido que podemos usar en modo PaaS gracias a la plataforma de azure. Pero redis se define como un sistema de base de datos NoSql de tipo clave valor, que funciona perfectamente como memoria caché, pero que además tiene muchas características adcionales. A lo largo de esta charla comentaremos las posibilidades de este servicio y cómo podemos explotarlas.
Los olores del código (Code Smells en inglés) son la forma que utilizamos para referirnos a signos en el código fuente que podrían indicar un problema más profundo.
Un code smell no tiene por qué implicar que una aplicación no funcione correctamente. Indica un problema de diseño que puede enlentecer el desarrollo, generar más errores en el futuro y hacer aparecer una mayor cantidad de bugs en nuestra aplicación. Dentro de las buenas prácticas de programación, con el objetivo de escribir cada vez mejor código, necesitamos ir aprendiendo todos estos signos.
La caché es una memoria más pequeña y rápida que la de nuestro almacén de información, por lo que su uso se ha extendido desde el hardware hasta el software. Con la evolución de las tecnologías hacia internet y la utilización de diferentes servidores en entornos cloud, se ha creado la necesidad de desarrollar sistemas de caché distribuidos. Microsoft Azure nos provee de diferentes servicios de caché distribuida, pero debemos aprender a utilizarlos de la forma más eficiente. A lo largo de esta charla revisaremos los sistemas de caché disponibles y cómo podemos explotarlos en nuestras aplicaciones.
Descubriendo las caches por Quique Martínez y Fernando Escolar.
Hoy en día en la nube puedes hospedarlo todo, incluso la memoria caché que usan tus aplicaciones. Pero no todas las cachés que encontramos son iguales, ni se usan para los mismos fines, ni siquiera tienen el mismo comportamiento.
A lo largo de esta charla realizaremos un viaje a través de los tipos de datos, cuales es mejor almacenarlos en caché y qué caché es más recomendabe para cada uno. Y terminaremos con los resultados de un estudio acerca de la performance de diferentes sistemas de cachés hospedados en la nube.
Como desarrolladores tenemos que crear el mejor código posible, que sea eficiente y que realice correctamente las funciones para las que ha sido creado: calidad. Una buena forma de conseguir esta buena calidad es probando nuestro código. Creando unit tests (pruebas unitarias) para cada una de las diferentes funcionalidades e intentando acercarnos lo máximo posible a una cobertura completa. Pero de nada sirve obligar al equipo a cubrir un 80% de código, si las pruebas que realizan no aportan valor.
A lo largo de esta charla estudiaremos la mejor forma de probar código: Diferenciaremos entre los diferentes tipos de pruebas, sentaremos las bases de un buen unit test, nos ayudaremos de herramientas de diagnóstico y métricas de código, y refactorizaremos para conseguir código "testeable".
Estamos demasiado acostumbrados a que como javascript tiene el nombre script, podemos programar como y donde nos parezca. Pero eso ha cambiado. Hoy en día js es una compleja plataforma de programación de clientes ricos, válida para móviles, tablets y todos los ordenadores de escritorio. Así que ha llegado la hora de empezar a programar javascript con calidad.
Vamos a explorar el mundo de las Social Networks en busca de las tecnologías y las arquitecturas ideales.
Desarrollaremos la red Social más cool del momento, beer to beer.
Donde nos veremos envueltos en el complejo mundo de REST, WEP API, ASP.NET y las últimas tecnologías que nos podemos encontrar en la nube de Microsoft, Windows Azure.
basándonos en las prácticas de los coding dojo, intentaremos mostrar cómo aplicar en vivo, conceptos de la programación orientados a la calidad.
-----
El código zombi es aquel que está infectado del virus de la mala calidad. Este virus provoca que el código se degrade poco a poco hasta corromper el sistema, se ejecute lentamente y consuma todos los recursos disponibles. Todo programador que entre en contacto con código zombi y no esté preparado puede infectarse y empezar a hacer código de mala calidad.
Programar es difícil, y hacer buen código todavía más. Por suerte para nosotros, gente como Robert C. Martin, Bertrand Meyer,
Barbara Liskov o los miembros de GoF nos han dado las herramientas como los patrones de diseño y los principios SOLID que hacen nuestra tarea más sencilla.
Con su ayuda podremos pasar de hacer código que simplemente funciona, a aplicaciones robustas y mantenibles que serán fáciles de modificar y en las que será más difícil que haya bugs gracias a los tests unitarios. Subiremos un nivel (o dos) la calidad de nuestro código y veremos cómo dejamos atrás la frustración que provoca hacer código que no se entiende.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
2. MADRID · NOV 27-28 · 2015
Fernando Escolar
@fernandoescolar
fernando.escolar@tokiota.com
3. MADRID · NOV 27-28 · 2015
Agenda
Definición de Unit Test
Estructura
Código Testeable
Unit Test
Estructura
Herramientas
Conclusiones
4. MADRID · NOV 27-28 · 2015
¿Qué es una prueba de software?
Input Process Output
5. MADRID · NOV 27-28 · 2015
Clasificación de las pruebas
Installation testing
Compatibility testing
Smoke and sanity testing
Regression testing
Acceptance testing
Alpha testing
Beta testing
Functional vs non-functional testing
Destructive testing
Software performance testing
Usability testing
Accessibility testing
Security testing
Internationalization and localization
Development testing
A/B testing
Unit testing
Integration testing
System testing
Acceptance testing
White-Box testing
Black-box testing
Visual testing
Grey-box testing
6. MADRID · NOV 27-28 · 2015
¿Qué es una prueba unitaria?
7. MADRID · NOV 27-28 · 2015
¿Qué es una prueba unitaria?
A unit test is a piece of a code (usually a method) that
invokes another piece of code and checks the correctness
of some assumptions afterward. If the assumptions turn
out to be wrong, the unit test has failed.
A “unit” is a method or function.
Unit test definition – The art of unit testing
Roy Osherove – Manning Publications co
8. MADRID · NOV 27-28 · 2015
Caraterísticas
FIRST
Fast
Isolated
Repeatable
Self-Validating
Timely
9. MADRID · NOV 27-28 · 2015
Caraterísticas
SECOND
Profesional
Unitario
Automatizable
No usa recursos
10. MADRID · NOV 27-28 · 2015
Estructura
Triple A
Arrange
Act
Assert
11. MADRID · NOV 27-28 · 2015
Estructura
Triple Cuádruple A
Assume
Arrange
Act
Assert
22. MADRID · NOV 27-28 · 2015
[TestMethod]
public async Task SpyTest()
{
// arange
var service = new WeatherServiceSpy();
// act
await service.GetCityWeatherAsync(CityName);
// assert
service.HasBeenCalled().GetCityWeatherAsync();
service.HasBeenCalled().GetCityWeatherAsync(CityName);
service.HasBeenCalled().Once().GetCityWeatherAsync();
service.HasBeenCalled().Once().GetCityWeatherAsync(CityName);
var invokation = service.GetCalls().First().GetCityWeatherAsync();
Assert.AreEqual("GetCityWeatherAsync", invokation.Name);
}
23. MADRID · NOV 27-28 · 2015
[TestMethod]
public async Task StubTest()
{
// arange
var service = new WeatherServiceStub();
var dummy = new WeatherInfo();
service
.AddHandlers()
.GetCityWeatherAsync(cityName => Task.FromResult(dummy));
// act
var actual = await service.GetCityWeatherAsync(CityName);
// assert
Assert.AreEqual(dummy, actual);
}
24. MADRID · NOV 27-28 · 2015
[TestMethod]
public async Task MockTest()
{
// arange
var service = new WeatherServiceMock();
service
.AddVerifications()
.GetCityWeatherAsync(CityName)
.GetCurrentCityWeatherAsync(CityName);
// act
await service.GetCityWeatherAsync(CityName);
await service.GetCurrentCityWeatherAsync(CityName);
// asserts
service.VerifyAll();
}
28. MADRID · NOV 27-28 · 2015
Simplificar constructores
No usar “new”
No asignar algo que no sea un atributo
No usar “Initializer”
No usar condicionales o bucles
29. MADRID · NOV 27-28 · 2015
Test positivo y negativo
30. MADRID · NOV 27-28 · 2015
Ventajas de los unit tests
Encontrar bugs pronto
Red de seguridad
Documentación
Mejor diseño
31. MADRID · NOV 27-28 · 2015
Limitaciones de los unit tests
No detectan problemas de:
Integración
Performance
…
No todo puede ser testeado fácilmente:
Multi-threading
Algoritmos no deterministas
…
32. MADRID · NOV 27-28 · 2015
Técnicas para hacer unit testing
TDD
ATDD
BDD
33. MADRID · NOV 27-28 · 2015
Métricas de código
Code Coverage
Cyclomatic Complexity
35. MADRID · NOV 27-28 · 2015
Muchas gracias
Fernando Escolar
@fernandoescolar
fernando.escolar@tokiota.com
Notas del editor
Una prueba de software es una investigación que se lleva a cabo con el fin de proporcionar a los stakeholders información sobre la calidad del mismo.
No tienen por qué basarse solo en código.
Nos pueden aportar en adición datos sobre performance y reporte de errores o defectos en el software.
Métodos de testing:
White Box: pruebas de las estructuras internas de trabajo de un programa. El tester especifica unas entradas que se ejecutarán a lo largo de diferentes ámbitos del código y definirá unas salidas apropiadas. Este método se aplica en las pruebas unitarias, de integración y del sistema.
Black Box: son pruebas del comportamiento externo de una aplicación. Sin tener en cuenta ni conocimiento de como se han implementado internamente. Pueden ser aplicados a todos los niveles de testing: unitarios, integración, sistema y aceptación. Un ejemplo y subtipo de este método de testing son los visuales o de UI.
Grey Box: son pruebas de tipo black box en las que hay que tener cierto conocimiento de la implementación interna, pero no de todo el código fuente. (ejemplo test de carga de wke).
Niveles de testing:
Unitarios: verifica una funcionalidad de una sección del código fuente específica. Generalmente utilizados por los desarrolladores usando el método de White box.
Integración: verifican que los diferentes componentes, interfaces y artefactos de un sistema trabajan bien entre ellos.
Sistema: se usan sobre un sistema totalmente integrado y desplegado. Y validan que el sistema cumple los requisitos deseados y que el software se comporta correctamente dentro de este.
Aceptación: se usan sobre el aplicativo terminado, para validar que realmente realiza las operaciones como se espera.
Tipos de testing:
Hay muchos, en dependencia de cual es el objetivo del test que estamos realizando. Una prueba unitaria puede ser de cualquiera de estos tipos….
Una prueba unitaria es una pieza de código (generalmente un método) que invoca a otra pieza de código y comprueba después la exactitud de ciertos supuestos. Si alguno de estos supuestos termina siendo erróneo, la prueba unitaria ha fallado.
Una “unidad” es un método o una función.
Fast: Rápidos. Tenemos que ser capaces de ejecutar cientos de pruebas en un solo segundo.
Isolated: Una prueba unitaria tiene que estar aislada del resto de pruebas y del resto del código que no se quiere probar.
Repeatable: Tenemos que poder repetir una prueba tantas veces como sea necesario sin que esto afecte al resultado.
Self-validating: Una prueba unitaria devuelve si se ha pasado o si ha fallado. No tiene que dejar cosas al aire para la interpretación.
Timely: Estamos acostumbrados a escribir las pruebas justo después de hacer el código que queremos probar. Y esas pruebas las realiza el mismo desarrollador. Lo cierto es que hacerlas antes de codificar o que las escriba otra persona después, aportará valor. Un unit test tiene que ser escrito en el momento oportuno.
Organizar: establecer el contexto de la unidad bajo prueba
Actuar: ejecutar la unidad bajo prueba, capturando cualquier estado resultante
Afirmar: verificar el comportamiento a través de afirmaciones (assertions)
Suposiciones: asumir condiciones previas sobre las entradas de prueba
Organizar: establecer el contexto de la unidad bajo prueba
Actuar: ejecutar la unidad bajo prueba, capturando cualquier estado resultante
Afirmar: verificar el comportamiento a través de afirmaciones (assertions)
Are you fucking kidding me?
Lo que puedes hacer es escribir mejor código, código “testeable”.
Vamos a ver algunos truquillos:
Test doubles es el nombre genérico que recibe la técnica de reemplazar un objeto del sistema existente por otro, solo con fines de prueba. Estos objetos ayudarán a que nuestras pruebas unitarias solo prueben una cosa y no las demás.
Tipos:
Dummy (maniquí): son objetos que se van pasando por el test, pero que en realidad no se usan. Se suelen usar para almacenar datos “vacíos”.
Fake (falso): es un objeto que contiene lógica que funciona. Pero esta lógica no sirve para producción. Un ejemplo sería la gestión de una base de datos en memoria, para no crear sockets ni tocar archivos.
Stubs (esbozo): proporcionan respuestas enlatadas a las llamadas realizadas durante la prueba, por lo general no responden en absoluto a nada fuera de lo que está programado en la prueba.
Spies (espias): son stubs que además de proporcionar esas llamadas específicas, también guardan una estadística de las mismas. Por ejemplo cuantas veces ha sido llamado un método.
Mocks (simulacro): son objetos pre-programados con las expectativas de las llamadas que van a recibir. Pueden lanzar excepciones cuando reciben llamadas no admitidas. Y al final se verifica que se han realizado todas las llamadas que se esperaban.
Fake Server de sinonjs
Simplificar los constructores de los objetos. No meter lógica:
Si dentro de un constructor tienes que usar la palabra “new” para instanciar otro objeto, es que tienes un problema.
No asignes valores que no sean atributos de la propia clase. Es decir, mantén la cohesión.
No usar métodos como “Initializer” o algo así, aunque sean más fáciles de testear que el propio constructor.
Y por supuesto no se debería insertar ninguna lógica o flujo dentro de un constructor, así que ni condiciones ni bucles.
Siempre solemos probar el caso afirmativo de un problema. Cuando un test tiene que dar este resultado. Una buena práctica es también probar el caso de que no lo dé. Es decir, si hago una operación obtengo este resultado, pero es interesante saber que si no la hago exactamente igual, no voy a obtener ese mismo resultado.
- TDD: escribir pruebas antes que el código que las resuelva
ATDD: es similar a TDD, pero TDD se basa en pruebas unitarias y ATDD en pruebas de aceptación
BDD: similar a TDD pero en lugar de unit tests se crean specs. Las specs se centran en el comportamiento antes que en la implementación.