Codeception / Codeception/module-doctrine

Proposal: haveInRepository returns the created entity instead of the primary key

Abierto
#11 2 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
PHP
Estrellas
4
Forks
2
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

In many tests i have come across situations like this:
```php
$I->haveInRepository(User::class, [
'name' => 'Jane',
'email' => 'jane_doe@gmail.com',
'password' => '123456',
'enabled' => true
]);
$user = $I->grabEntityFromRepository(User::class, [
'email' => 'jane_doe@gmail.com'
]);
// do assertions with the $user
```
Use `haveInRepository`, and then be forced to use `grabEntityFromRepository` to get the entity i just persisted. If i want to check that an entity listener is working, for example, i always have to execute those two statements.

My point is that this would be more useful:
```php
$user = $I->haveInRepository(User::class, [
'name' => 'Jane',
'email' => 'jane_doe@gmail.com',
'password' => '123456',
'enabled' => true
]);
// do assertions with the $user
```
if i wanted to know the primary key of that entity, i would simply write:
```php
$user->getId();
```
In this context, the ORM is useful for its ability to abstract the details of the persistence process and leave it to me as a programmer to worry more about the data i am working with.

I'm not saying that getting the primary key is not useful, i am saying that it is much more useful to get the entity, where there is more information to work with in my tests, including the persistence identifier.

https://github.com/Codeception/module-doctrine2/blob/1ae32bdcd77abde4a583462f5949fc86b9bda2a2/src/Codeception/Module/Doctrine2.php#L504-L530

Please let me know your opinions about it.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

Comienza con src/Codeception/Module/Doctrine2.php, en la implementación enlazada de haveInRepository alrededor de las líneas 504-530, y compárala con grabEntityFromRepository. Revisa el comportamiento existente del valor de retorno y los usos relacionados antes de decidir el contrato; se considera terminado cuando la propuesta está resuelta con un valor de retorno probado y documentado para haveInRepository.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
php
Área
testing
Tipo de issue
Nueva funcionalidad
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
38/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.