1
resposta

[Sugestão] Melhoria na implementação do testes

Gostaria de fazer uma sugestão: no final do projeto, a forma implementada foi utilizar diretamente o método da API do main.dart até chegar ao FutureBuilder() no header.dart.

Sabemos que uma aplicação comercial pode possuir dezenas de APIs e, à medida que o projeto cresce, seria inviável passar cada parâmetro de cima para baixo até os filhos.

Portanto, o que eu fiz foi criar uma classe abstrata BankHttpService e implementá-la apenas na classe BankHttp existente:

@GenerateMocks([BankHttp])
abstract class BankHttpService {
  Future<String> dolarToReal();
}

class BankHttp implements BankHttpService {
  @override
  Future<String> dolarToReal() async {
  ...

E no código main.dart

class MyApp extends StatelessWidget {
  MyApp({Key? key}) : super(key: key);
  final BankHttpService bankHttpService = BankHttp(); //// mudança foi aqui

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: purpleTheme,
      home: BankInherited(
          child: Home(
        bankHttpService: bankHttpService, // mudança foi aqui
      )),
    );
  }
}

Precisamos alterar o home.dart e o header.dart para receber o parâmetro this.bankHttpService em vez de this.api

No header, em FutureBuilder, é onde chamamos o método dolarToReal(), e não no main como antes:

FutureBuilder(
                      // future: widget.api,
                      future: widget.bankHttpService.dolarToReal(),

E, por fim, o teste unitário (home_test.dart) mudou nessa linha:

 home: BankInherited(
        // child: Home(api: httpMock.dolarToReal()),
        child: Home(bankHttpService: httpMock),
      ),

Além disso, eu mudaria o teste unitário 'Testing MockHttp dolarToReal' onde estamos verificando o número fixo de 5 vezes de chamadas do método: Nesse cenário o ideal seria qualquer valor "maior que 0".

verify(httpMock.dolarToReal()).called(greaterThan(0));

Espero poder ter ajudado :)

1 resposta

Oi Leandro, tudo bem?

Muito obrigada por compartilhar sua sugestão conosco. Realmente, é importante pensar em soluções escaláveis para projetos maiores, e sua ideia de criar uma classe abstrata e implementá-la apenas na classe existente é uma boa prática.

Além disso, suas alterações no código main.dart e nos arquivos home.dart e header.dart foram bem pensadas e ajudam a manter o código mais organizado e fácil de entender.

Quanto à sua sugestão de mudança no teste unitário, concordo que é uma boa ideia verificar se o método foi chamado pelo menos uma vez, em vez de um número fixo de vezes.

Parabéns pela sua contribuição e obrigado por compartilhar suas ideias conosco.

Um abraço e bons estudos.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software