Abordagem de recapitulação e teste

Agora criamos este pequeno aplicativo legal que nos permite fazer login com a Apple.

No entanto, você pode estar sentindo que fizemos um pequeno desvio para fazer as coisas funcionarem com o TCA. Certamente poderíamos ter alcançado a mesma coisa com muito menos código no SwiftUI vanilla.

Também criamos vários tipos personalizados (como o AppleAuthenticationResponsetipo) para transportar informações que, de outra forma, são transportadas por tipos internos da AuthenticationServicesestrutura.

Então , por que passamos pelo incômodo de abstrair tudo com o TCA?

Bem, com o TCA temos o poder de escrever facilmente testes para praticamente qualquer lógica que definimos em nosso aplicativo. Como estamos usando tipos personalizados, poderemos facilmente simular interações com dependências. Também não teremos que nos preocupar com nossas visualizações, já que essa lógica é quase totalmente dissociada da interface do usuário.

Método de teste

Em testes de unidade regulares do iOS, afirmaríamos as alterações usando XCTAssert. Para testar o código TCA, teremos que usar TestStore, um objeto que pode nos ajudar a simular o comportamento em nossos recursos TCA.

Estaremos usando a send()função para acionar ações de nossa escolha e
a receive()função para verificar se outras ações do TCA são recebidas, bem como verificar quaisquer alterações que ocorram no estado do aplicativo.

Root TestStore

Em todos os testes que escreveremos, usaremos o estado/redutor raiz , pois é o recurso que gerencia as alterações de estado no nível do aplicativo.

let store = TestStore(
     initialState: Root.State(),
     reducer: Root()
)

Se dividirmos nosso aplicativo em eventos que acionam mudanças no estado de nosso aplicativo (por exemplo, comportamentos), três desses eventos vêm à mente;

• Login bem-sucedido com a Apple por meio do botão SIWA
• Terminar sessão na aplicação através do botão “Sair”
• Verificando o status de autenticação do usuário na inicialização

Teste de login bem-sucedido

Como nossa interface do usuário é orientada por estado, podemos testar uma entrada bem-sucedida verificando se o estado do aplicativo muda para o estado principal depois que o botão SIWA é tocado.

Gatilho de evento

• Primeiro, podemos criar uma simulação AppleAuthenticationResponse(uma vez que ela é gerada quando o usuário faz login).
• Em seguida, para replicar o que acontece com um login bem-sucedido, podemos usar store.send()para enviar a .signInWithAppleButtonTappedação com nossa resposta simulada.

• A loja deve receber e então .didSignIndelegar a ação do recurso SignIn . Podemos verificar isso usando TCA's store.receive().
• O estado do aplicativo deve mudar para .main(Main.State()). Podemos verificar isso no encerramento que é passado para a store.receive()chamada.

$0 = .main(Main.State())
    
       

Gatilho de evento

• Para replicar o que acontece depois que ocorre uma saída, podemos enviar a .signOutButtonTappedação.

• A loja deve então receber a .didSignOutação delegada.
• O estado do aplicativo deve mudar para .signIn(SignIn.State()).

Os testes que escrevemos para verificar se nossa verificação de autenticação funciona serão um pouco diferentes dos testes que já escrevemos, pois a verificação de autenticação depende da AuthenticationClientdependência.

Isso significa que precisaremos usar a unimplementedversão do AuthenticationClient(que configuramos na parte 1 do artigo), que nos permitirá zombar das respostas do cliente.

Após configurar um mock, iremos sobrescrever os TestStore's authenticationClientdiretamente com nosso unimplementedcliente através da dependenciespropriedade.

var authenticationClient = AuthenticationClient.unimplemented
        
authenticationClient.checkAppleAuthenticationStatus = { _ in
    .signedIn
}
        
store.dependencies.authenticationClient = authenticationClient

Para testar como o aplicativo se comporta quando o usuário já está conectado na inicialização, podemos simular um .signedInstatus retornado da verificação de autenticação.

Gatilho de evento

• Primeiramente, precisaremos passar o .signedInstatus para a checkAppleAuthenticationStatuspropriedade do nosso unimplementedcliente.
• Em seguida, podemos enviar a ._onAppearação, pois isso inicia a verificação de autenticação (conforme configuramos na parte 2 do artigo).

• A loja deve então receber a ._checkAuthenticationStatusResponseação com o .signedInstatus que passamos para o unimplementedcliente.
• O estado do aplicativo deve mudar para .main(Main.State()).

Para testar o cenário em que o usuário é desconectado na inicialização, quase podemos reutilizar o teste que acabamos de escrever, com apenas algumas pequenas alterações.

Gatilho de evento

• Desta vez, passamos o .signedOutstatus para a checkAppleAuthenticationStatuspropriedade.
• Em seguida, podemos enviar a ._onAppearação novamente para iniciar a verificação de autenticação.

• A loja deve então receber a ._checkAuthenticationStatusResponseação com o .signedOutstatus desta vez.
• E não deve haver alteração no estado, pois o estado padrão na inicialização é o estado SignIn — portanto, nenhuma alteração seria detectada (mesmo quando o estado SignIn for atribuído).

Com isso, cobrimos a configuração, a interface do usuário e uma abordagem de teste para implementar o Login com a Apple usando o TCA. Se você achou este artigo útil ou útil, entre em contato no Twitter ou no Mastodon. Tenha um bom dia!