Flutter com TDD e Clean Architecture. Por Silas Brasil
HTML-код
- Опубликовано: 24 окт 2024
- 👋 Sejam bem-vindos ao Flutterando, a maior comunidade de Flutter do Brasil! Aqui, você encontra tudo sobre Flutter, desde tutoriais para iniciantes até dicas avançadas para desenvolvedores experientes.
🚀 Aprenda Flutter com nosso Roadmap: Confira o guia completo para começar sua jornada em Flutter e evoluir suas habilidades.
roadmap.flutte...
💬 Participe da nossa Comunidade no Discord: Junte-se a nossa vibrante comunidade no Discord e troque conhecimentos com outros desenvolvedores.
discord.flutte...
📸 Siga-nos no Instagram: Fique por dentro de atualizações e conteúdos exclusivos seguindo nosso Instagram.
instagram.flut...
📢 Nosso Canal no Telegram: Receba notificações e atualizações importantes diretamente no seu Telegram.
telegram.flutt...
🎓 Masterclass Flutterando: Aprofunde seus conhecimentos em Flutter com nossos cursos detalhados na plataforma Masterclass.
masterclass.fl...
👍 Não esqueça de curtir o vídeo, inscrever-se no canal e ativar o sininho para não perder nenhum conteúdo novo!
#flutter #flutterando #dart
Show de bola. Seria sensacional se fizesse continuação deste projeto implementando todas partes dele. O Silas tem uma organização didática muito boa.
Excelente aula!
Excelente conteúdo. Valeu mesmo.
Muito bom. Obrigado por compartilhar
Qual o tema do seu vscode? Alguém sabe se souber me falar desde já agradeço!
Finalmente um vídeo que realmente trata arquitetura de forma profissional. Parabéns!
FINALMENTE voces olharam pro resocoder
Aula boa, mas fiquei com várias dúvidas:
1. Qual a diferença do models de data para os models de domain? não poderiam ser um só?
2. A mesma coisa com datasources lá em data. Ao meu ver, a implementação do repositório é justamente a fonte de dados.
Abs.
Cara massa sua pergunta, infelizmente não deu tempo para abordar a camada de Data. Vou vou tentar resumir aqui. O datasourse é responsável por pegar os dados nas suas respectivas fontes de dados, pode ser local ou remoto. Já o repositório é o cérebro da camada de Data, ele vai orquestrar se o dada vai ser buscado na base local, por exemplo, shared_prefrerence ou na base remota, como uma API. Na Clean Architecture não o repositório não tem acesso direto a base de dados, que faz isso é o datasource.
@@SilasSWF obrigado por esclarecer. É que sem ter um exemplo realmente é um pouco difícil entender essa abstração do datasource e do repositório. Eu enxergava tudo uma coisa só rs..
No mais, parabéns pelo conteúdo e torço p que tenhamos mais vídeos seus.
Abs.
Sei que isso foi só a pontoa do Iceberg, tomara que tenha continuação.
Também to esperando a continuação, TDD é sensacional.
Silas, ótimo vídeo, obrigado. Fico apenas com uma dúvida, mais relacionada à organização das features do DDD (domain driven design): e se o GetReminders precisasse dos dados do usuário logado (feature relacionada à autenticação) ou de uma informação de um outro domínio dentro da aplicação diferente dos Reminders, como seria essa comunicação? Eu posso, no domain do Reminder, chamar um usecase de um outro domínio? Eu acho que não, mas não sei qual seria a melhor solução para este caso.
Foi top a apresentação deste dia.
Eu gostei. É uma abordagem que vale a pena quando o projeto é crítico e não pode apresentar erros, numa fase mais avançada. Pra Lean Startup que precisa de agilidade complica.
Concordo tbm. Mas uma dica que dou é: não deixe que testar partes que críticas do projeto independente da fase que sua Startup vive. Atualmente, testes são uma parte essencial de qualquer projeto. Independente do tamanho. Talvez, vc tenha se assustado com a estrutura de pastas da Clean Architecture, mas fique a vontade para usar outras estruturas. Em breve vamos fazer outras abordagens. Abraços!
Silas Brasil se deixar, eu fico o dia todo só pensando em arquitetura e testes. Testaria cada hipótese do software. Mas no fim das contas, com ou sem testes, vai pra frente o projeto que entrega, especialmente no começo do empreendimento. Não achei verboso, como os caras estão dizendo, mas tô numa fase muito confusa em que não consigo balancear qualidade de arquitetura X velocidade de entrega. Um amigo meu uma vez disse: "se a arquitetura atrapalha a entrega, tem alguma coisa errada". Tô confuso ainda 😅
Tá certo mano. Mas vamos, com o tempo, esclarecer mais esse assunto.
Nossa, eu tava precisando desse video.
Duvida: Vocês não acham muito precipitado uma empresa incluir clean architecture no teste do processo seletivo? Eu fiz varios bootcamps e cursos em flutter e inclusive ja fiz freela e isso era novo pra mim. Quer dizer, é um ambiente de dev recente, essas coisas ainda não estão maduras. Na minha opinião isso deveria ser um treinamento interno da empresa.
Muito da hora!! Trabalho para uma consultoria e aqui usamos a Clean Architecture e também a Hexagonal para alguns clientes. Faltou só o link do Git do projeto hehe :)
Achei interessante, só que me lembrou muito o padrão DDD, no lugar dos usescases seria os commands.
Não sei qual projeto mobile grande o suficiente para utilizar essa estrutura, trazendo bastante complexidade. Não estou falando não utilizar nenhum padrão !!
Em relação aos testes acho essencial para garantir algumas partes criticas da aplicação.
Obrigado por compartilhar o conhecimento.
Esse Meetup foi Genial!!
Gostaria de saber como o pacote flutter_clean_architecture auxilia em um projeto como esse.
Pessoal, nas novas versões do mockito esse código apresenta falha, nunca retorna o valor da Future do usecase repository. É preciso adicionar o build_runner ao seu projeto e utilizar a sintaxe abaixo para criar a classe de mock:
```@GenerateNiceMocks([MockSpec()])
2. Necessário executar: flutter pub run build_runner build
3. O dart irá gerar(nesse caso) o arquivo get_reminder_test.mocks.dart que deverá ser importado:
import 'get_reminder_test.mocks.dart'; ```
Interessante isso.. mas pro mundo front-end é pavoroso! Hj a comunidade front-end já entende que teste unitário adiciona muita complexidade e cai o rendimento do dev. Não é atoa que libs para testes unitários em front-end estão morrendo para os testes de integração e end-to-end, pois testa somente o que realmente importa pro usuário. Você imagina a trabalheira que vai dar quando ocorrer uma mudança brusca no backend, e o front tiver que refatorar boa parte. Ou imagina se a equipe de UX resolve alterar boa parte da tela.. muita coisa irá quebrar com facilidade (da parte de UI). A produtividade cai demais! O código fica frágil com esses tipos de teste, pois qualquer mudança (o que ocorre muito no front-end) é necessário refazer os testes para adaptar ao cenário atual.
Concordo que, a primeira vista, o teste para front-end é uma complicação, mas, a meu ver, a proposta dos teste e possivelmente do TDD é garantir a integridade das regras de negócio. Ou seja, se vc entregar 100% da camada de domínio testada, lhe garanto que as outras camadas serão beneficiadas.
@@SilasSWF Pensando dessa maneira, qualquer teste que eu fizer, a aplicação será beneficiada de qualquer forma...
@@theuniverse685 Sim, mas qual é a principal parte da aplicação? É a regar de negócio. Por isso, lá tá o o core doa testes.
@@SilasSWF Olha, no meu ponto de vista, não existe a parte principal da aplicação, até porque, se alguma parte da UI parar de funcionar, vai impedir o usuário da mesma forma de executar a ação que ele deseja, sendo um impeditivo mesmo assim.
Isso é muito verboso ! Fico imaginando a produtividade e a curva de aprendizado para um membro novo no time !
Diego Collares acredito q ele vai ter q organizar o código de algum jeito. É melhor aprender algo q é padrão do que criar seu próprio. Isso daria mais problema
@@FlutterandoTV Tem de mostrar a realidade q vai ser vivida, n adianta falar sempre q vai ser conto de fadas! Melhor aprender do início q morrer fazendo bullshit.
concordo!
Parece verboso se não conhecer os conceitos do SOLID, ou não usa adequadamente. E digo mais, quando você trabalha em um app grande, onde a cada uma alteração gera-se dois bugs, você vai querer tudo isso aqui, acredite.
Desenvolver com TDD é umas das melhores maneiras para evitar bugs no futuro , porém achei essa abordagem com tantos pacotes e classe muito verbosa.
Realmente, assusta do cara mas com um pouco de automatização do códigos isso fica suave. Vlw!
@@SilasSWF tem algum material para dar uma olhada?
@@leonardozb3 ruclips.net/video/KjE2IDphA_U/видео.html