Refactorización y Validación de Código en Pruebas Unitarias
Contenido del curso
Mayra Guadalupe Aceves Higareda
Jhonathan Alfonso
Alessandro Staiano
Michelle Estefanía Arias López
Oscar Stevens Cuartas Bejarano
Hector Rubio
Enrique Gamboa
Paul Cortes
María Sierra
Luis Aguilar Espinoza
Manuel Entrena Jimenez
Ariana Betsaida Sánchez Martínez
Javier Amaya Patricio
Martin Mendez
Manuel Ojeda
Jesús Antonio García Valadez
Jorge Daniel Rincón Luciano
Hiram Abraham Villaraux Ojeda
Jorge Daniel Rincón Luciano
Hiram Abraham Villaraux Ojeda
Daniel Morales
Enrique Gamboa
Juan Camilo Avilés Espinosa
Guillermo Camacho
KEVIN BRAYAN LUNA FIGUEROA
KEVIN BRAYAN LUNA FIGUEROA
Italo Morales Fantone
Profesor
Juan David Rueda Quiroga
Luis Daniel Mendoza Rodríguez
Jean Nuñez
Juan Pablo Gómez López
Sergio Antonio Ordoñez González
Eduardo Rahn
Brazzini OC
Luis Carlos Zapata García
Para aprenderse los Códigos de estado HTTP: HTTP STATUS DOGS
Jjajaj gracias!!!
Hay otros que preferimos los gatos ;) https://www.flickr.com/photos/girliemac/albums/72157628409467125/
Códigos Status 2xx:
no entiendo absolutamente nada en este capitulo, vengo perfecto con el curso pero aqui me estallo el cerebro no entiendo NADA todo el capitulo lo senti como "haga asi, asa asi y asi" pero en cada paso la pregunta es PORQUE? COMO? DONDE? de donde salio?
Te recomiendo que repases, en los cursos anteriores el profesor explica php unit de una forma mas sencilla, tambien te recomiendo documentarte en internet dado que hay veces que hace falta complementar. Suerte!
Como dice el compañero, no es nada que no hayamos visto en cursos anteriores. En el curso de buenas prácticas explican un poco de TDD, quizá te ayude a entender mejor qué está pasando.
Codigos Status 4xx. 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Payload Too Large 414 URI Too Long 415 Unsupported Media Type 416 Requested Range Not Satisfiable 417 Expectation Failed 418 I'm a teapot 421 Misdirected Request 422 Unprocessable Entity (WebDAV) 423 Locked (WebDAV) 424 Failed Dependency (WebDAV) 426 Upgrade Required 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 451 Unavailable For Legal Reasons
Refactorización y validación en Store
public function test_validate_title() { $response = $this->json('POST', '/api/posts', [ 'title' => '' ]); $response->assertStatus(422) ->assertJsonValidationErrors('title'); // Solicitud OK, pero no se pudo concretar }
Explicación de HTTP Status con perros
Explicación de HTTP Status con gatos en flicker
Explicación de HTTP Status con gatos API
En el ejemplo de refactorización, lo que no pude comprender es cómo el constructor del controlador PostController obtiene como argumento la entidad Post? ¿Quién le envía ese argumento?
class PostController extends Controller { protected $post; public function __construct(Post $post) { $this->post = $post; }
Por si ha alguien le sirve, se me paso poner el authorize() a true y no entendia los errores que salian.
Gracias! No entendía cual era mi error!
Aporte de la clase
https://www.evernote.com/l/Ap4Moc1-tr5Id4qaZqvpNqguqJv3eRMRl6E/ :D
Que ventaja se tiene al usar $this->post en lugar de Post:: si es mas corto con Post:: y no hay que agregarlo al constructor?
protected $post; public function __construct(Post $post) { $this->post = $post; }
Mera demostración el uso del constructor, estamos siguiendo los patrones de Programación Orientada a Objetos y lo que estamos haciendo es usar un solo Objeto par realizar las tareas del Controlador.
Bien podemos dejarlo de la manera corta y se entiende al 100%.
Se puede decir que no hay diferencia. Sin embargo, si aplicamos POO, es mejor usarlo como en el código qué hay arriba y no con Post::. Esto porque al usar Post::algo() estás atando a la clase a usar la clase Post, esto es contraproducente a la larga porque, que pasaría si por alguna razón, tuvieras que cambiar la clase Post? Tendrías que cambiarla en todos los lugares donde la estás usando. En cambio, al usar $this->post = $post, solo tendrías que cambiar la instancia de la clase Post, al momento de instanciar la clase donde la vas a utilizar. Por ejemplo, supongamos que tenemos un blog y de repente tenemos que cambiar a wordpress. Nada más tendríamos que hacer un cambio como el siguiente:
$wordpress = new Blog(New WordpressPost());
Siendo la clase WordpressPost una clase que implemente la interfaz Post. Podrías tener una serie de Adapters como WordpressPost, GhostPost, NormalPost, etc. Y cambiarlos en el momento que los necesites sin necesidad de cambiar demasiado código ya que todas las clases AlgoPost al implementar la interfaz Post pueden ser usadas pasándolas en el constructor de la clase.
Sin duda, es más fácil escribir Post::algo() pero, hacerlo de esta forma te dará más flexibilidad.
Alguien sabe donde se pueden encontrar todos los asserts con su documentacion? Estaba viendo la documentacion de laravel, pero no me es muy explicita en cuanto a los parametros que se pueden utilizar con cada uno de ellos
Esa la encuentras en la documentacion oficial de phpunit Documentacion Oficial
Muchas gracias, amigo!
El listado completo de los Asserts:
Documentación oficila de PHPUnit
La refactorizacion de ese _construct(Post) , no comprendo que sentido tiene o como puede ser mejor.
Como dijo un compañero aquí, La ventaja de usar una variable (lo que hicimos al pasarla por el constructor) en lugar de llamar directamente a la clase post es que de esta forma nos facilita el mantenimiento y la escalabilidad, al evitarnos algunos problemas. Imagina que más adelante en el proyecto decidimos cambiar el nombre de la clase post, en ese caso tendríamos que cambiar también el nombre en todos los lugares donde la habíamos llamado directamente, si no lo hacemos correctamente podríamos tener errores y nuestro proyecto dejaría de funcionar correctamente. Al asignar la clase post a una variable, el único lugar donde tendríamos que cambiar el nombre de ese llamado a la clase sería justamente en el constructor. De esta forma es más fácil mantener nuestro código en perfecto funcionamiento y aseguramos escalabilidad. Ya sabes, todo eso a lo que le llaman buenas prácticas.
Todo era perfecto hasta que llegue a Tests, es algo complejo de entender pero muy importante.
Estoy en las mismas compañero.
`There was 1 error:
Me manda ese error, me pueden ayudar, por favor!
Solo puede resolverlo dejando la funcion STORE así:
$post = Post::create($request->all()); return response()->json($post, 201);
Genial, la idea es resolver.
https://www.restapitutorial.com/httpstatuscodes.html esta página me ha ayudado mucho en e uso de apis
Tests: 1 failed, 1 passed
Illuminate\Validation\ValidationException
The given data was invalid.
me sale ese error
refactorizando el codigo sin alterar el resultado
¿Por qué al añadir
$this->withoutExceptionHandling();
al principio de la función test_validate() la prueba falla? Cuando remuevo esta línea el Test pasa. ¿Me podrían aclarar esto por favor? :)
El constructor Post, solo se utiliza en el store? o tambien en el update y demas metodos?
La utilizarías en el Index y en el Store, en los otros métodos la entidad la recibes por parámetro.
Si tuviera más campos que fueran obligatorios, ¿se debería crear un test para cada campo ?
si por que el test debería evaluar todo el programa
