Testes automatizados e CI

No fim desta aula consegues

• Desenhar a pirâmide de testes e dizer o custo e a velocidade de cada nível.
• Escolher o que testar numa app móvel (parsing, lógica de estado, estados de UI) e o que não compensa.
• Substituir um repository por um fake ou por um mock com mocktail e testar um notifier sem rede.
• Escrever um teste de widget com pumpWidget, find, tap e pumpAndSettle.
• Configurar o GitHub Actions para correr flutter analyze e flutter test em cada PR e proteger o main.

A pirâmide de testes

• Os unitários apanham a maioria dos bugs de lógica. Os de widget apanham "o botão desapareceu". Os E2E apanham "a app não arranca no Android 12".
• Uma pirâmide invertida (só E2E) é o erro clássico: cada teste demora minutos, falha por razões alheias ao código, e ninguém o corre.

Para os testes: muitos unitários, alguns de widget, poucos de integração; quanto mais alto na pirâmide, mais lento e mais caro.

O que testar em mobile

• Parsing: fromJson com JSON real da API, com campos em falta, com null, com tipos errados. É onde a app crasha em produção quando o backend muda.
• Lógica de estado: o notifier passa de Loading para Dados; para Erro quando o repository falha; para Vazio com lista vazia. Sem UI, sem rede.
• Estados de UI: o ecrã mostra o spinner, a mensagem de erro, o botão "Tentar de novo", a lista. Um teste de widget por estado.
• Regras de negócio: amplitude térmica, cor do aviso, "atualizado há 12 min", conversão °C/°F.

Para os testes: em mobile testa-se primeiro o parsing e a lógica de estado, porque é o que falha quando a API muda ou a rede cai.

Mocks e fakes: testar sem rede

• O notifier depende de um PrevisaoRepository. No teste, injetas outra implementação. Foi para isto que fizemos a interface na aula 13.
• Fake: uma classe tua que implementa a interface com lógica simples (devolve uma lista fixa, ou lança). Legível, sem package, chega para a maioria dos casos.
• Mock com mocktail: class MockRepo extends Mock implements PrevisaoRepository {}; programas respostas com when(() => repo.previsao(any())).thenAnswer(...) e verificas chamadas com verify.
• Mocktail não precisa de geração de código (ao contrário do mockito com build_runner). Por isso o usamos.
• Nunca deixes um teste bater na API do curso: é lento, depende da rede, e enche a telemetria do grupo com pedidos de teste.

Para os testes: um fake é uma implementação simplificada escrita à mão; um mock é programado no próprio teste e regista as chamadas.

Golden tests

• Um golden test renderiza um widget e compara os pixels com uma imagem de referência guardada no repo (matchesGoldenFile('previsao_card.png')).
• Apanha regressões visuais que nenhum find.text apanha: padding que mudou, cor errada no tema escuro, texto cortado com letra grande.
• Quando usam: design systems, componentes reutilizados em muitos ecrãs, apps onde o aspeto é produto. O Flutter usa-os para os próprios widgets Material.
• Quando incomodam: a renderização de fontes difere entre macOS, Linux e o CI, e cada mudança legítima de UI obriga a regenerar as imagens (flutter test --update-goldens). Sem revisão, as imagens de referência são atualizadas sem verificação.

Para os testes: golden tests comparam pixels com uma imagem de referência; são valiosos para componentes visuais e frágeis entre máquinas diferentes.

Integração contínua

• CI: um servidor corre flutter analyze e flutter test em cada push e em cada PR. Se falha, o PR fica vermelho e não pode entrar em main.
• O badge verde no README é a definição de pronto tornada visível: "corre no telemóvel, sem avisos, PR revisto" passa a incluir "CI verde".
• GitHub Actions é grátis para repos públicos e para os do Classroom; usa subosito/flutter-action para instalar o Flutter no runner.
• Builds de iOS precisam de macOS: no Actions, runs-on: macos-latest custa 10 vezes mais minutos. Alternativas feitas para mobile: Codemagic e Bitrise, com máquinas Mac, assinatura e upload às lojas incluídos.
• Regra: o CI corre o que corres localmente. Se o flutter analyze avisa no teu portátil, avisa no CI.

Para os testes: CI corre analyze e test em cada PR; builds iOS exigem um runner macOS, que o GitHub cobra mais caro e o Codemagic inclui.

Prática: testes e CI no Tempo Açores

git clone https://github.com/pdm-daw-2026/pdm-aula-25.git
cd pdm-aula-25/starter
flutter pub get
flutter run

O starter/ tem a app da aula 14 (estados de UI com sealed class) com TODOs numerados e uma pasta test/ com testes a falhar. O solucao/ tem o estado final, incluindo o workflow do Actions. Corre flutter test agora e conta os vermelhos: são os teus objetivos.

Quatro blocos: teste unitário do modelo, teste do notifier com fake e com mock, teste de widget, e CI.

1. Teste unitário do modelo

import 'dart:convert';
import 'package:flutter_test/flutter_test.dart';
import 'package:tempo_acores/models/previsao.dart';

const amostra = '''
{"locationId": "3420300", "forecastDate": "2026-11-16",
 "tMin": 14.2, "tMax": 19.8, "weatherType": "rain", "precipProb": 65}
''';

void main() {
  group('Previsao.fromJson', () {
    test('lê os campos do JSON v1 da API', () {
      final p = Previsao.fromJson(jsonDecode(amostra) as Map<String, dynamic>);
      expect(p.localidadeId, '3420300');
      expect(p.dia, DateTime(2026, 11, 16));
      expect(p.tipo, TipoTempo.chuva);
    });

    test('calcula a amplitude térmica', () {
      final p = Previsao.fromJson(jsonDecode(amostra) as Map<String, dynamic>);
      expect(p.amplitude, closeTo(5.6, 0.001));
    });
  });
}

1. Teste unitário: o que interessa

• Um ficheiro em test/ que termina em _test.dart, com um main(). flutter test encontra-os todos; flutter test test/models corre só uma pasta.
• group agrupa, test é um caso, expect(valor, matcher) verifica. Matchers úteis: equals, isA<T>(), closeTo, isNull, throwsA, contains.
• Nunca compares double com ==: 19.8 - 14.2 não é exatamente 5.6. Usa closeTo.
• Um teste, uma razão para falhar. Se o nome do teste tem "e", provavelmente são dois.
• O JSON de teste vem da API real: copia uma resposta do Swagger para uma constante, não inventes campos.

2. Teste do notifier com um fake (1 de 2)

import 'package:flutter_test/flutter_test.dart';
import 'package:tempo_acores/data/previsao_repository.dart';
import 'package:tempo_acores/models/previsao.dart';
import 'package:tempo_acores/state/previsao_notifier.dart';

class FakePrevisaoRepository implements PrevisaoRepository {
  FakePrevisaoRepository({this.resposta = const [], this.erro});
  final List<Previsao> resposta;
  final Object? erro;

  @override
  Future<List<Previsao>> previsao(String localidadeId) async {
    if (erro != null) throw erro!;
    return resposta;
  }
}

final previsaoTeste = Previsao(
  localidadeId: '3420300', dia: DateTime(2026, 11, 16),
  tMin: 14.2, tMax: 19.8, tipo: TipoTempo.chuva,
);

2. Teste do notifier com um fake (2 de 2)

void main() {
  test('loading → dados quando o repository responde', () async {
    final notifier = PrevisaoNotifier(FakePrevisaoRepository(resposta: [previsaoTeste]));
    final estados = <PrevisaoEstado>[];
    notifier.addListener(() => estados.add(notifier.estado));

    await notifier.carregar('3420300');

    expect(estados.first, isA<Loading>());
    expect(estados.last, isA<Dados>());
    expect((estados.last as Dados).lista, hasLength(1));
  });

  test('loading → vazio quando a lista vem vazia', () async {
    final notifier = PrevisaoNotifier(FakePrevisaoRepository());
    await notifier.carregar('3420300');
    expect(notifier.estado, isA<Vazio>());
  });
}

2. O mesmo com mocktail: loading → erro

import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:tempo_acores/data/api_exception.dart';
import 'package:tempo_acores/data/previsao_repository.dart';
import 'package:tempo_acores/state/previsao_notifier.dart';

class MockPrevisaoRepository extends Mock implements PrevisaoRepository {}

void main() {
  late MockPrevisaoRepository repo;
  late PrevisaoNotifier notifier;

  setUp(() {
    repo = MockPrevisaoRepository();
    notifier = PrevisaoNotifier(repo);
  });

  test('loading → erro quando a API falha', () async {
    when(() => repo.previsao(any()))
        .thenAnswer((_) async => throw ApiException('Sem ligação', podeRepetir: true));
    await notifier.carregar('3420300');
    expect(notifier.estado, isA<Erro>().having((e) => e.mensagem, 'mensagem', 'Sem ligação'));
    verify(() => repo.previsao('3420300')).called(1);
  });
}

2. Notifier: o que interessa

• O teste não sabe de HTTP, de JSON nem de Flutter. Só existe porque o notifier recebe o repository pelo construtor.
• Registar os estados com addListener deixa-te afirmar a sequência (primeiro Loading, depois Dados), não só o fim.
• when(...).thenAnswer((_) async => ...) para métodos assíncronos; thenThrow lança de forma síncrona e pode fugir ao teu try. any() aceita qualquer argumento.
• verify(...).called(1) apanha o notifier a chamar a API duas vezes por engano. verifyNever apanha o contrário.
• Fake para cenários simples e legíveis; mock quando queres verificar chamadas ou variar respostas dentro do mesmo teste.

3. Teste de widget (1 de 2)

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:provider/provider.dart';
import 'package:tempo_acores/state/previsao_notifier.dart';
import 'package:tempo_acores/ui/previsao_screen.dart';
import 'package:tempo_acores/ui/widgets/previsao_card.dart';
import '../helpers.dart'; // MockPrevisaoRepository, previsaoTeste, ApiException

Widget appDeTeste(MockPrevisaoRepository repo) => ChangeNotifierProvider(
      create: (_) => PrevisaoNotifier(repo)..carregar('3420300'),
      child: const MaterialApp(home: PrevisaoScreen(localidadeId: '3420300')),
    );

void main() {
  testWidgets('mostra a mensagem de erro e o botão Tentar de novo', (tester) async {
    final repo = MockPrevisaoRepository();
    when(() => repo.previsao(any()))
        .thenAnswer((_) async => throw ApiException('Sem ligação', podeRepetir: true));
    await tester.pumpWidget(appDeTeste(repo));
    await tester.pumpAndSettle();
    expect(find.text('Sem ligação'), findsOneWidget);
    expect(find.widgetWithText(FilledButton, 'Tentar de novo'), findsOneWidget);
  });
}

3. Teste de widget (2 de 2): o tap

  testWidgets('Tentar de novo volta a carregar e mostra a lista', (tester) async {
    final repo = MockPrevisaoRepository();
    when(() => repo.previsao(any()))
        .thenAnswer((_) async => throw ApiException('Sem ligação', podeRepetir: true));
    await tester.pumpWidget(appDeTeste(repo));
    await tester.pumpAndSettle();

    // A partir daqui a API "recupera"
    when(() => repo.previsao(any())).thenAnswer((_) async => [previsaoTeste]);

    await tester.tap(find.text('Tentar de novo'));
    await tester.pumpAndSettle();              // até não haver mais frames agendados

    expect(find.text('Sem ligação'), findsNothing);
    expect(find.byType(PrevisaoCard), findsOneWidget);
    verify(() => repo.previsao('3420300')).called(2);
  });

3. Teste de widget: o que interessa

• pumpWidget monta a árvore; precisa de um MaterialApp à volta, senão não há tema, direção de texto nem Navigator.
• O Provider entra no teste como na app: o ecrã não sabe que o repository é um mock.
• pump() avança um frame; pumpAndSettle() avança até a árvore estabilizar. Se o ecrã tem uma animação infinita (o spinner) e o estado nunca muda, pumpAndSettle falha por timeout: usa pump(const Duration(seconds: 1)).
• find.text, find.byType, find.byKey, find.widgetWithText. Para elementos repetidos, dá-lhes uma Key.
• Para testar o estado Loading, faz o mock devolver um Completer<List<Previsao>>().future que nunca completas, dá um pump() e procura o CircularProgressIndicator. Se deixasses o mock responder logo, o loading passava entre dois frames e não o apanhavas.
• O mock e o previsaoTeste vivem em test/helpers.dart, partilhados por todos os testes. Um teste de widget corre no portátil, sem emulador, em décimos de segundo.

4. GitHub Actions: o workflow

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  verificar:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          channel: stable
          cache: true

      - run: flutter --version
      - run: flutter pub get
      - run: dart format --output=none --set-exit-if-changed lib test
      - run: flutter analyze --fatal-infos
      - run: flutter test --reporter expanded

4. CI: proteger o main e mostrar o badge

1. Commit do workflow num branch, abre o PR. No separador Checks vês o job verificar a correr; a primeira execução demora 3 a 4 minutos (depois a cache acelera).
2. Settings → Branches → Add branch ruleset para main: liga "Require a pull request before merging" e "Require status checks to pass", e escolhe o check verificar. A partir daqui um PR vermelho não tem botão de merge.
3. Badge no README:

   ![CI](https://github.com/pdm-daw-2026/tempo-acores-grupo-01/actions/workflows/ci.yml/badge.svg)

   Substitui pelo nome do vosso repo. Verde no README é a definição de pronto visível a quem passa.
4. Parte-o de propósito: comenta uma linha do fromJson, faz push, vê o PR ficar vermelho, repõe. Agora sabes o que o CI faz por ti.

Exercício final: um teste por estado

A app do projeto tem quatro estados em cada ecrã (aula 14). Cada estado merece um teste de widget que prova que a UI faz o que o design diz.

Até quarta