Proposal: haveInRepository returns the created entity instead of the primary key
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 38/100
Direção de pesquisa
Comece por src/Codeception/Module/Doctrine2.php, na implementação vinculada de haveInRepository por volta das linhas 504-530, e compare-a com grabEntityFromRepository. Revise o comportamento existente do valor de retorno e os usos relacionados antes de decidir o contrato; considera-se concluído quando a proposta estiver resolvida com um valor de retorno testado e documentado para haveInRepository.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
In many tests i have come across situations like this:
$I->haveInRepository(User::class, [
'name' => 'Jane',
'email' => '[email protected]',
'password' => '123456',
'enabled' => true
]);
$user = $I->grabEntityFromRepository(User::class, [
'email' => '[email protected]'
]);
// 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:
$user = $I->haveInRepository(User::class, [
'name' => 'Jane',
'email' => '[email protected]',
'password' => '123456',
'enabled' => true
]);
// do assertions with the $user
if i wanted to know the primary key of that entity, i would simply write:
$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.
Please let me know your opinions about it.
- Linguagem predominante
- PHP
- Estrelas
- 4
- Forks
- 2
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de Codeception/module-doctrine
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 38/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 30/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 35/100
Codeception/module-doctrine#2 · 1 comentário · 1 reação ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 42/100
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 64/100
Codeception/module-doctrine#6 · 1 comentário ·
Todas as issues de Codeception/module-doctrine
Issues semelhantes
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
Mantenedores costumam responder em até 1 dia
-
PHP SDK drops the API path prefix when a custom base URL has no trailing slashTalvez já em andamento @Winoren assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
langgenius/dify#44568 · 1 comentário · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
1. to develop bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia