Unit tests

Why unit tests?

A unit test runs a small piece of code (a function or a class) with known inputs and checks the output. Unit tests are fast (milliseconds), need no device, and catch logic bugs early: a wrong GST calculation, a validator that accepts a 5-digit PIN, a cart that miscounts after removing an item. Flutter projects include the flutter_test package for this.

// lib/cart.dart
class Cart {
  final Map<String, int> _qty = {};
  void add(String item) => _qty[item] = (_qty[item] ?? 0) + 1;
  void remove(String item) {
    final q = _qty[item];
    if (q == null) return;
    if (q <= 1) {
      _qty.remove(item);
    } else {
      _qty[item] = q - 1;
    }
  }
  int get count => _qty.values.fold(0, (a, b) => a + b);
}

// test/cart_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:chai_shop/cart.dart';

void main() {
  group('Cart', () {
    late Cart cart;
    setUp(() => cart = Cart());                     // fresh cart before each test

    test('starts empty', () {
      expect(cart.count, 0);
    });

    test('adding the same item twice counts two', () {
      cart.add('chai');
      cart.add('chai');
      expect(cart.count, equals(2));
    });

    test('removing an item that is not in the cart does nothing', () {
      cart.remove('samosa');
      expect(cart.count, 0);
    });
  });
}

flutter test                        # all tests
flutter test test/cart_test.dart    # one file

A good test name reads like a sentence describing behaviour: "adding the same item twice counts two". When it fails, the name alone tells you what broke. Each test follows the same shape: arrange (set up data), act (call the code), assert (check the result with expect).

What should you test first? The logic that would hurt most if it were wrong: money calculations, validators, discount rules, and state classes such as a ChangeNotifier, Notifier or Cubit. These are plain Dart classes, so they are easy to test without any widgets. Keeping logic out of widgets is what makes this possible.

Matchers

test('rejects a negative amount', () {
  expect(() => Wallet().add(-50), throwsA(isA<ArgumentError>()));
});

test('async functions can be tested too', () async {
  final price = await fetchPriceFake('chai');
  expect(price, 15);
});

Fakes and mocks

Code that talks to the network or a database should not do so in unit tests: slow, flaky and dependent on the internet. Depend on an abstract class (module 2), and in tests pass a fake implementation that returns fixed data. Libraries such as mocktail create mocks whose answers you configure per test and which can verify calls. Start with simple hand-written fakes.

Common mistakes

• Tests that depend on each other's data. Use setUp for a fresh state.
• Comparing doubles with equals: 0.1 + 0.2 is not exactly 0.3. Use closeTo.
• Calling real APIs in unit tests.
• Only testing the happy path; test edges like empty input, zero and maximum values.