Melhorias de legibilidade nas aulas 04 e 05

aulas/04.md

@@ -461,7 +461,7 @@ def test_create_user(session, mock_db_time):
 ```
 
 1. Inicia o gerenciador de contexto `mock_db_time` usando o modelo `User` como base.
-2. Converte o user em um dicionário para simplificar a validação no teste.
+2. Converte o `user` em um dicionário para simplificar a validação no teste.
 3. Usa o time gerado por `mock_db_time` para validar o campo `created_at`.
 
 O teste permanece praticamente igual, com a diferença de que todas as operações envolvendo a criação de `User` no banco de dados acontecem no escopo de `mock_db_time`.
@@ -484,7 +484,7 @@ Para simplificar a comparação de todos os campos, como nossos objetos de model
 
 Como o tempo agora é determinístico e contido no nosso gerenciador de contexto, podemos fazer a comparação exata entre todos os campos. Inclusive `created_at`.
 
-Desta forma, nossos modelos e testes de banco de dados agora em ordem, estamos prontos para avançar para a próxima fase de configuração de nosso banco de dados e gerenciamento de migrações.
+Desta forma, com nossos modelos e testes de banco de dados em ordem, estamos prontos para avançar para a próxima fase de configuração de nosso banco de dados e gerenciamento de migrações.
 
 
 ## Configuração do ambiente do banco de dados

aulas/05.md

@@ -484,10 +484,10 @@ Found 1 error.
 Would fix 1 error.
 ```
 
-Isso ocorre porque a rota PUT era a única que estava utilizando UserDB, e agora que modificamos esta rota, podemos remover UserDB dos nossos imports e também excluir sua definição no arquivo `schemas.py`
+Isso ocorre porque a rota PUT era a única que estava utilizando UserDB, e agora que modificamos esta rota, podemos remover UserDB dos nossos imports e também excluir sua definição no arquivo `fast_zero/schemas.py`
 
-??? note "Sobre o arquivo `schemas.py`"
-    Caso fique em dúvida sobre o que remover, seu arquivo `schemas.py` deve estar parecido com isso, após a remoção de `UserDB`:
+??? note "Sobre o arquivo `fast_zero/schemas.py`"
+    Caso fique em dúvida sobre o que remover, seu arquivo `fast_zero/schemas.py` deve estar parecido com isso, após a remoção de `UserDB`:
 
 	```python title="schemas.py" linenums="1"
 	from pydantic import BaseModel, ConfigDict, EmailStr
@@ -496,6 +496,7 @@ Isso ocorre porque a rota PUT era a única que estava utilizando UserDB, e agora
     class Message(BaseModel):
         message: str
 
+
     class UserSchema(BaseModel):
         username: str
         email: EmailStr
@@ -518,7 +519,7 @@ Isso ocorre porque a rota PUT era a única que estava utilizando UserDB, e agora
 Também precisamos alterar o teste para o endpoint de PUT, para que exista um usuário na base para ser alterado:
 
 ```python title="tests/test_app.py" hl_lines="1"
-def test_update_user(client, user):
+def test_update_user(client, user): #(1)!
     response = client.put(
         '/users/1',
         json={
@@ -535,20 +536,22 @@ def test_update_user(client, user):
     }
 ```
 
+1. Adicionaremos a fixture `user` que já efetua a criação de um registro no banco de dados.
+
 ### O caso do conflito
 
-Embora pareça que está tudo certo, o teste está sendo executado com sucesso. Porém, existe um caso que não foi pensado nesse update. Alguns dados no nosso modelo (`username` e `email`) estão marcados como `unique` na base de dados. O que pode ocasionar um erro em potencial, caso alguém altere esses valores para um valor já existente.
+Embora pareça que está tudo certo e o teste esteja sendo executado com sucesso. Existe, porém,  um caso que não foi pensado nesse update. Alguns dados no nosso modelo (`username` e `email`) estão marcados como `unique` na base de dados. O que pode ocasionar um erro em potencial, caso alguém altere esses valores para um valor já existente.
 
 Por exemplo, imagine que duas pessoas se cadastraram na nossa aplicação. Uma com `#!py {'username': 'faustino'}` e outra com `#!py {'username': 'dunossauro'}`. Até esse momento, não teríamos nenhum problema.
 
-Mas o que aconteceria se fausto fizesse um update e quisesse se chamar dunossauro?
+Mas o que aconteceria se "faustino" fizesse um update e quisesse se chamar "dunossauro"?
 
 Vamos iniciar a escrita de um cenário de testes que contemple isso para ficar mais claro:
 
 ```python title="tests/test_app.py" hl_lines="1"
 def test_update_integrity_error(client, user):
-    # Inserindo fausto
-    client.post(
+    # Criando um registro para "fausto"
+    client.post( #(1)!
         '/users',
         json={
             'username': 'fausto',
@@ -557,8 +560,8 @@ def test_update_integrity_error(client, user):
         },
     )
 
-    # Alterando o user das fixture para fausto
-    response_update = client.put(
+    # Alterando o user.username das fixture para fausto
+    response_update = client.put( #(2)!
         f'/users/{user.id}',
         json={
             'username': 'fausto',
@@ -568,8 +571,10 @@ def test_update_integrity_error(client, user):
     )
 ```
 
-Mesmo sem escrever nenhum `#!py assert` nesse teste, se executarmos o código, ele falhará:
+1. Criando um user com o `username` sendo "fausto"
+2. Alterando o user existente no banco para usar o mesmo usarname de "fausto"
 
+Mesmo sem escrever nenhum `#!py assert` nesse teste, se executarmos os testes, ele falhará:
 
 ```shell title="$ Execução no terminal!" hl_lines="12 13"
 task test