Enrique Matías Sánchez
6 years ago
committed by
Alexander Makarov
5 changed files with 153 additions and 65 deletions
@ -0,0 +1,20 @@
|
||||
Tests de aceptación |
||||
=================== |
||||
|
||||
Un test de aceptación verifica escenarios desde la perspectiva de un usuario. |
||||
Se accede a la aplicación testeada por medio de PhpBrowser o de un navegador de verdad. |
||||
En ambos casos los navegadores se comunican vía HTTP así que la aplicación debe ser |
||||
servida por un servidor web. |
||||
|
||||
Los tests de aceptación se implementan con ayuda del _framework_ Codeception, que tiene |
||||
una buena documentación: |
||||
|
||||
- [Codeception para el _framework_ Yii](http://codeception.com/for/yii) |
||||
- [Tests funcionales de Codeception](http://codeception.com/docs/04-FunctionalTests) |
||||
|
||||
## Ejecución de tests en las plantillas básica y avanzada |
||||
|
||||
Si ha empezado con la plantilla avanzada, consulte la [guía de testeo](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide/start-testing.md) |
||||
para más detalles sobre la ejecución de tests. |
||||
|
||||
Si ha empezado con la plantilla básica, consulte la [sección sobre testeo de su README](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing). |
||||
@ -1,11 +1,25 @@
|
||||
Tests Funcionales |
||||
Tests funcionales |
||||
================= |
||||
|
||||
> Note: Esta sección se encuentra en desarrollo. |
||||
Los tests funcionales verifican escenarios desde la perspectiva de un usuario. |
||||
Son similares a los [tests de aceptación](test-acceptance.md) pero en lugar de |
||||
comunicarse vía HTTP rellena el entorno como parámetros POST y GET y después ejecuta |
||||
una instancia de la aplicación directamente desde el código. |
||||
|
||||
- [Tests Funcionales de Codeception](http://codeception.com/docs/04-FunctionalTests) |
||||
Los tests funcionales son generalmente más rápidos que los tests de aceptación y |
||||
proporcionan _stack traces_ detalladas en los fallos. |
||||
Como regla general, debería preferirlos salvo que tenga una configuración de servidor |
||||
web especial o una interfaz de usuario compleja en Javascript. |
||||
|
||||
Ejecutar test funcionales de templates básicos y avanzados |
||||
---------------------------------------------------------- |
||||
Las pruebas funcionales se implementan con ayuda del _framework_ Codeception, que tiene |
||||
una buena documentación: |
||||
|
||||
Por favor consulta las instrucciones provistas en `apps/advanced/tests/README.md` y `apps/basic/tests/README.md`. |
||||
- [Codeception para el _framework_ Yii](http://codeception.com/for/yii) |
||||
- [Tests funcionales de Codeception](http://codeception.com/docs/04-FunctionalTests) |
||||
|
||||
## Ejecución de tests en las plantillas básica y avanzada |
||||
|
||||
Si ha empezado con la plantilla avanzada, consulte la [guía de testeo](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide/start-testing.md) |
||||
para más detalles sobre la ejecución de tests. |
||||
|
||||
Si ha empezado con la plantilla básica, consulte la [sección sobre testeo de su README](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing). |
||||
|
||||
@ -0,0 +1,80 @@
|
||||
Tests |
||||
===== |
||||
|
||||
Las pruebas son una parte importante del desarrollo de software. Seamos conscientes |
||||
de ello o no, ralizamos pruebas contínuamente. |
||||
Por ejemplo, cuando escribimos una clase en PHP, podemos depurarla paso a paso o |
||||
simplemente usar declaraciones `echo` o `die` para verificar que la implementación |
||||
funciona conforme a nuestro plan inicial. En el caso de una aplicación web, introducimos |
||||
algunos datos de prueba en los formularios para asegurarnos de que la página interactúa |
||||
con nosotros como esperábamos. |
||||
|
||||
El proceso de testeo se puede automatizar para que cada vez que necesitemos verificar |
||||
algo, solamente necesitemos invocar el código que lo hace por nosotros. El código que |
||||
verifica que el restulado coincide con lo que habíamos planeado se llama *test* y el proceso |
||||
de su creación y posterior ejecución es conocido como *testeo automatizado*, que es el |
||||
principal tema de estos capítulos sobre testeo. |
||||
|
||||
|
||||
## Desarrollo con tests |
||||
|
||||
El Desarrollo Dirigido por Pruebas (_Test-Driven Development_ o TDD) y el Desarrollo |
||||
Dirigido por Corpotamientos (_Behavior-Driven Development_ o BDD) son enfoques para |
||||
desarrollar software, en los que se describe el comportamiento de un trozo de código |
||||
o de toda la funcionalidad como un conjunto de escenarios o pruebas antes de escribir |
||||
el código real y sólo entonces crear la implementación que permite pasar esos tests |
||||
verificando que se ha logrado el comportamiento pretendido. |
||||
|
||||
El proceso de desarrollo de una funcionalidad es el siguiente: |
||||
|
||||
- Crear un nuevo test que describe una funcionalidad a implementar. |
||||
- Ejecutar el nuevo test y asegurarse de que falla. Esto es lo esperado, dado que todavía no hay ninguna implementación. |
||||
- Escribir un código sencillo para superar el nuevo test. |
||||
- Ejecutar todos los tests y asegurarse de que se pasan todos. |
||||
- Mejorar el código y asegurarse de que los tests siguen superándose. |
||||
|
||||
Una vez hecho, se repite el proceso de neuvo para otra funcionalidad o mejora. |
||||
Si se va a cambiar la funcionalidad existente, también hay que cambiar los tests. |
||||
|
||||
> Tip: Si siente que está perdiendo tiempo haciendo un montón de iteraciones pequeñas |
||||
> y simples, intente cubrir más por cada escenario de test, de modo que haga más cosas antes |
||||
> de ejecutar los tests de nuevo. Si está depurando demasiado, intente hacer lo contrario. |
||||
|
||||
La razón para crear los tests antes de hacer ninguna implementación es que eso nos permite |
||||
centrarnos en lo que queremos alcanzar y sumergirnos totalmente en «cómo hacerlo» después. |
||||
Normalmente conduce a mejores abstracciones y a un más fácil mantenimiento de los tests |
||||
cuando toque hacer ajustes a las funcionalidades o componentes menos acoplados. |
||||
|
||||
Para resumir, las ventajas de este enfoque son las siguientes: |
||||
|
||||
- Le mantiene centrado en una sola cosa en cada momento, lo que resulta en una mejor planificación e implementación. |
||||
- Resulta en más funcionalidades cubiertas por tests, y en mayor detalle. Es decir, si se superan los tests, lo más problable es que no haya nada roto. |
||||
|
||||
A largo plazo normalmente tiene como efecto un buen ahorro de tiempo. |
||||
|
||||
## Qué y cómo probar |
||||
|
||||
Aunque el enfoque de primero los tests descrito arriba tiene sentido para el largo plazo |
||||
y proyectos relativamente complejos, sería excesivo para proyectos más simples. |
||||
Hay algunas indicaciones de cuándo es apropiado: |
||||
|
||||
- El proyecto ya es grande y complejo. |
||||
- Los requisitos del proyecto están empezando a hacerse complejos. El proyecto crece constantemente. |
||||
- El proyecto pretende a ser a largo plazo. |
||||
- El coste de fallar es demasiado alto. |
||||
|
||||
No hay nada malo en crear tests que cubran el comportamiento de una implementación existente. |
||||
|
||||
- Es un proyecto legado que se va a renovar gradualmente. |
||||
- Le han dado un proyecto sobre el que trabajar y no tiene tests. |
||||
|
||||
En algunos casos cualquier forma de testo automatizado sería exagerada: |
||||
|
||||
- El proyecto es sencillo y no se va a volver más complejo. |
||||
- Es un proyecto puntual en el que no se seguirá trabajando. |
||||
|
||||
De todas formas, si dispone de tiempo, es bueno automatizar las pruebas también en esos casos. |
||||
|
||||
## Más lecturas |
||||
|
||||
- Test Driven Development: By Example / Kent Beck. ISBN: 0321146530. |
||||
@ -1,25 +1,25 @@
|
||||
Tests de Unidad |
||||
=============== |
||||
Pruebas unitarias |
||||
================= |
||||
|
||||
> Note: Esta sección se encuentra en desarrollo. |
||||
Un test unitario se encarga de verificar que una unidad simple de código funcione como se espera. |
||||
Esto decir, dados diferentes parámetros de entrada, el test verifica que el método |
||||
de la clase devuelve el resultado esperado. |
||||
Normalmente los tests unitarios son desarrollados por la persona que escribe las clases testeadas. |
||||
|
||||
Un test de unidad se encarga de verificar que una unidad simple de código funcione como se espera. En la programación orientada a objetos, |
||||
la unidad de código más básica es una clase. Por lo tanto, un test de unidad necesita verificar que cada método de la interfaz de la clase funciona apropiadamente. |
||||
Esto quiere decir que, dando diferentes parámetros de entrada, el test verifica que el método devuelve el resultado esperado. |
||||
Los tests de unidad son normalmente desarrollados por la persona que escribe las clases siendo testeadas. |
||||
Los tests unitarios en Yii están construidos en base a PHPUnit y, opcionalmente, Codeception, por lo que se recomienda consultar su respectiva documentación: |
||||
|
||||
Los tests de unidad en Yii están construidos en base a PHPUnit y opcionalmente, Codeception, por lo que se recomineda consultar su respectiva documentación: |
||||
- [Codeception para el _framework_ Yii](http://codeception.com/for/yii) |
||||
- [Tests unitarios con Codeception](http://codeception.com/docs/05-UnitTests) |
||||
- [Documentación de PHPUnit, empezando por el capítulo 2](http://phpunit.de/manual/current/en/writing-tests-for-phpunit.html) |
||||
|
||||
- [Documentación de PHPUnit comienza en el capítulo 2](http://phpunit.de/manual/current/en/writing-tests-for-phpunit.html). |
||||
- [Tests de Unidad con Codeception](http://codeception.com/docs/05-UnitTests). |
||||
## Ejecución de tests en las plantillas básica y avanzada |
||||
|
||||
Ejecutar test de unidad de templates básicos y avanzados |
||||
-------------------------------------------------------- |
||||
Si ha empezado con la plantilla avanzada, consulte la [guía de testeo](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide/start-testing.md) |
||||
para más detalles sobre la ejecución de tests. |
||||
|
||||
Por favor consulta las instrucciones provistas en `apps/advanced/tests/README.md` y `apps/basic/tests/README.md`. |
||||
Si ha empezado con la plantilla básica, consulte la [sección sobre testeo de su README](https://github.com/yiisoft/yii2-app-basic/blob/master/README.md#testing). |
||||
|
||||
Test de unidad del Framework |
||||
---------------------------- |
||||
##Tests unitarios del framework |
||||
|
||||
Si quieres ejecutar tests de unidad para Yii en sí, consulta |
||||
"[Comenzando a desarrollar con Yii 2](https://github.com/yiisoft/yii2/blob/master/docs/internals/getting-started.md)". |
||||
Si desea ejecutar tests unitarios para el framework Yii en sí, consulte |
||||
«[Comenzando con el desarrollo de Yii 2](https://github.com/yiisoft/yii2/blob/master/docs/internals/getting-started.md)». |
||||
|
||||
Loading…
Reference in new issue