Forem: Daniel Cardona Rojas

SwiftMocking: Rethinking Test Doubles with Modern Swift

Daniel Cardona Rojas — Mon, 20 Oct 2025 05:24:18 +0000

The Swift testing ecosystem has long been dominated by traditional mocking frameworks that rely on runtime magic and type erasure. SwiftMocking takes a fundamentally different approach, leveraging Swift's most advanced language features to create something genuinely novel—a mocking library where type safety isn't an afterthought, but the foundation.

The Architecture Behind the Magic

What makes SwiftMocking unique isn't just its API, but its architectural foundation. Built on Swift 5.9's parameter packs, phantom types, and macros, it represents a complete rethinking of how test doubles should work in a type-safe language.

Parameter Packs: The Game Changer

At the heart of SwiftMocking lies an elegant use of parameter packs that enables something previously impossible—perfect type preservation across any function signature (aka arity):

class Spy<each Input, Effects: Effect, Output> {
    // Can represent ANY function signature while maintaining complete type safety
}

// These spies capture the exact shape of their target functions:
let simpleSpy = Spy<String, None, Int>()              // (String) -> Int
let asyncSpy = Spy<String, Async, Data>()             // (String) async -> Data
let throwingSpy = Spy<String, Int, Throws, Bool>()    // (String, Int) throws -> Bool
let asyncThrowsSpy = Spy<String, Int, Bool, AsyncThrows, [User]>() // (String, Int, Bool) async throws -> [User]

This approach eliminates the fundamental compromise that has plagued mocking frameworks: the choice between type safety and expressiveness. With SwiftMocking, you get both.

Effects as Phantom Types

Another characteristic of SwiftMocking's is how it models Swift's effects (async, throws). It does this by threading a phantom type through all the library types to ensure that only the correct tests can be written.

// The effect types thread through all library APIs
let spy = Spy<String, AsyncThrows, Data>()

when(spy(.any)).thenReturn { input in
    // Compiler enforces that this closure must be async throws
    await someAsyncOperation(input)
}

// This verification is also effect-aware
try await until(spy("test"))  // Can only be called on async spies

The Self-Managing Mock Infrastructure

The Mock base class represents another architectural innovation. Using @dynamicMemberLookup, it automatically creates and manages spy instances on demand:

@dynamicMemberLookup
open class Mock: DefaultProvider {
    subscript<each Input, Eff: Effect, Output>(
        dynamicMember member: String
    ) -> Spy<repeat each Input, Eff, Output> {
        // Lazily creates typed spies for protocol requirements
    }
}

This design keeps generated code minimal while providing unlimited flexibility. Each mock is essentially a spy factory that creates exactly the right spy type for each method signature.

Macro-Free Testing

While the @Mockable macro provides convenience, the core library is designed to work without it. This enables powerful closure-based testing patterns, for example:

// Test systems that use dependency injection with closures
struct APIClient {
    let fetchUser: (String) async throws -> User
    let updateUser: (User) async throws -> User
}

func testAPIFlow() async throws {
    let fetchSpy = Spy<String, AsyncThrows, User>()
    let updateSpy = Spy<User, AsyncThrows, User>()

    when(fetchSpy(.any)).thenReturn(User(id: "123", name: "Test"))
    when(updateSpy(.any)).thenReturn { user in
        // Dynamic behavior with perfect type safety
        User(id: user.id, name: user.name.uppercased())
    }

    let client = APIClient(
        fetchUser: adapt(fetchSpy),    // Convert spy to closure
        updateUser: adapt(updateSpy)
    )

    let result = try await client.updateUser(User(id: "456", name: "test"))
    verify(updateSpy(.any)).called()
}

Dynamic Stubbing with Type Safety

Traditional mocking frameworks force you to work with Any parameters in dynamic stubs. SwiftMocking preserves exact types:

@Mockable
protocol Calculator {
    func calculate(a: Int, b: Int) -> Int
}

when(calculator.compute(a: .even(), b: .even())).thenReturn { a, b in
    a + b
}

when(calculator.compute(a: .odd(), b: .odd())).thenReturn { a, b in
    a * b
}

Sophisticated Argument Matching

The argument matching system leverages Swift's literal protocols and range syntax for natural expressions:

// Swift ranges work naturally
verify(mock.setVolume(.in(0...100))).called()
verify(mock.processItems(.hasCount(in: 5...))).called()

// Literal values work without explicit matchers
verify(mock.authenticate("user@example.com")).called()
verify(mock.setFlag(true)).called(.greaterThan(2))
verify(mock.calculatePrice(199.99)).called()

Compact Code Generation

The macro generates remarkably clean code. For a simple protocol:

@Mockable
protocol PricingService {
    func price(for item: String) throws -> Int
}

The entire generated mock is just:

#if DEBUG
class MockPricingService: Mock, PricingService {
    func price(for item: ArgMatcher<String>) -> Interaction<String, Throws, Int> {
        Interaction(item, spy: super.price)
    }
    func price(for item: String) throws -> Int {
        return try adaptThrowing(super.price, item)
    }
}
#endif

Two methods: one for the fluent testing API, one for protocol conformance. No bloat, no generated noise.

Practical Benefits

Test Isolation by Design

SwiftMocking leverages Swift's TaskLocal values to enable testing protocols with static requirements which would be impossible without this feature.

In a similar manner the library provides TestScoping fallback values for unstubbed methods through suite and test traits, when using the Testing framework.

Framework Integration

The library works seamlessly with both XCTest and Swift Testing, all though it may be more convenient in when using the Testing framework:

// Swift Testing with automatic test isolation
@Test(.mocking)
func testConcurrentExecution() {
    // Each test gets isolated spy state
}

// XCTest with isolation through inheritance
class MyTests: MockingTestCase {
    // Automatic spy isolation per test method
}

Fallback Value System

A sophisticated default value system prevents fatalError for unstubbed methods:

// Built-in defaults for common types
let mock = MockUserService()
let name = mock.getUserName()  // Returns ""
let age = mock.getUserAge()    // Returns 0

// Custom types can participate
struct User: DefaultProvidable {
    static var defaultValue: User { User(id: "", name: "") }
}

SwiftMocking is available on GitHub with comprehensive documentation, real-world examples, and integration guides for both XCTest and Swift Testing.

Easy dialog management in Flutter

Daniel Cardona Rojas — Fri, 03 Sep 2021 16:53:31 +0000

Having worked with dialogs for a while I have encountered multiple scenarios where I wish I could control dialogs programatically through a controller, similar to how other standard widgets like textfields or scrollviews can be controlled.

It would be cool if we could toggle the visibility of a dialog or group of dialogs through some kind of dialog controller.

Having this would allow to define and manage dialogs in a centralized place and hook statemangement to perform the side effect of displaying dialogs.

Solution

Since we can't modify the API of standard widgets like Alert and creating subclasses for all types of alerts would be cumbersome.

The solution proposed here won't look identical to the API you would get with TextField where you can set a controller property on Widget itself.

So let's start by laying out some the characteristics that our dialog controller should have, here are the main ones:

Don't disable normal dialog interactions like closing from buttons.
Can return data from dialog through the controller or by popping with value
Can show and hide multiple times
Showing a new dialog will hide the previous

Brief overview

I'll just mention briefly the classes involved and what they do before showing the code.

DialogController: Registers a single dialog and gives the ability to toggle its visibility.
StyledDialogController<Style>: Registers a multiple dialogs associated with some style type (typically an enum)

Note: Only one dialog can be shown at a time which is what you normally want

Usage

Suppose we have some status property in our state management that we will use to show different types of dialogs.

We might want to display a dialog if this property changes to some especific values.

enum Status { loading, error, success, iddle }

Lets start by creating a styled controller and registering some dialogs in a stateful widget page:

@override
void initState() {
  // ....

  styledDialogController = StyledDialogController<Status>();

  styledDialogController.registerDialogOf(
    style: Status.error,
    builder: showErrorDialog,
  );

  styledDialogController.registerDialogOf(
    style: Status.success,
    builder: showSuccessDialog,
  );

  styledDialogController.registerDialogOf(
    style: Status.loading,
    builder: showLoadingDialog,
  );

  //...
}

These builders are just functions that display a dialog:

Future<void> showLoadingDialog() {
  return showDialog(
    context: context,
    builder: (context) => AlertDialog(
        content: SizedBox(
      height: 32,
      child: Center(child: CircularProgressIndicator()),
    )),
  );
}

With this in place you can now present and hide dialogs with which ever mechanism you wish:

styledDialogController.showDialogWithStyle(Status.error);

or close the dialog with:

styledDialogController.closeVisibleDialog();
// or
styledDialogController.closeVisibleDialog('some return value');

For example hook up state management to show some of these dialogs automatically like this:

// Using mobx
void initState() {
  //...

  mobx.reaction<Status>((_) => _store.status, (newValue) {
    if (newValue == Status.iddle) {
      closeVisibleDialog();
    } else {
      showDialogWithStyle(newValue);
    }
  });

}

How it works

The main idea behind this is to use the normal future returned by showDialog from Flutter in combination with a hidden Completer in a coordinated manner.

This is the most important part:

Future<T?> show<T>() {
  final completer = Completer<T>();

  _dialogCompleter = completer;

  _showDialog().then((value) {
    if (completer.isCompleted) return;
    completer.complete(value);
  });

  return completer.future;
}

void close<T>([T? value]) {
  if (_dialogCompleter?.isCompleted ?? true) return;

  _dialogCompleter?.complete(value);
  _closeDialog();
  _dialogCompleter = null;
}

If a dialogs is dismissed normally its associated future will terminate the completer and with this we respect the normal behavior or dialogs.

If a dialog has not been dismissed since we don't await it and instead return completer future, we remain in a waiting state until the close function is called which will resolve the completer and possibly return a value.

DialogController

import 'dart:async';

typedef DialogShowHandler<T> = Future<T> Function();

class DialogController {
  late DialogShowHandler _showDialog;
  late Function _closeDialog;
  Completer? _dialogCompleter;

  /// Registers the showing and closing functions
  void configureDialog({
    required DialogShowHandler show,
    required Function close,
  }) {
    if (_dialogCompleter != null && !_dialogCompleter!.isCompleted) {
      _closeDialog();
    }
    _showDialog = show;
    _closeDialog = close;
  }

  Future<T?> show<T>() {
    final completer = Completer<T>();

    _dialogCompleter = completer;

    _showDialog().then((value) {
      if (completer.isCompleted) return;
      completer.complete(value);
    });

    return completer.future;
  }

  void close<T>([T? value]) {
    if (_dialogCompleter?.isCompleted ?? true) return;

    _dialogCompleter?.complete(value);
    _closeDialog();
    _dialogCompleter = null;
  }
}

StyledDialogController

StyledDialogController just wraps a DialogController and records different dialog showing functions for each style.

class StyledDialogController<S> {
  Map<String, DialogShowHandler> _styleBuilders = {};

  S? visibleDialogStyle;

  DialogController _dialogController = DialogController();

  void registerDialogOf(
      {required S style, required DialogShowHandler builder}) {
    final styleIdentifier = style.toString();
    _styleBuilders[styleIdentifier] = builder;
  }

  Future<T?> showDialogWithStyle<T>(
    S style, {
    required Function closingFunction,
  }) {
    visibleDialogStyle = style;
    final styleIdentifier = style.toString();
    final builder = _styleBuilders[styleIdentifier];

    if (builder == null) return Future.value(null);

    _dialogController.configureDialog(
      show: builder,
      close: closingFunction,
    );
    return _dialogController.show();
  }

  void closeVisibleDialog<T>([T? value]) {
    visibleDialogStyle = null;
    _dialogController.close(value);
  }
}

Some other features can be built upon this base setup like:

preregistering dialog styles on a specialized StyledDialogController and using it through out many pages
having a base page type that already includes this ability
creating a mixin so multiple pages can show a set of dialogs

Hope you liked this post. Let me know your thoughts on this or if you have other ideas improving this setup.

Better Bloc and Cubit Unit Testing

Daniel Cardona Rojas — Fri, 16 Jul 2021 18:12:05 +0000

Similar to a previous article, in this one I would like to address some pain points I've encountered while working with the bloc package, specifically related to testing.

As you might have seen in the official bloc documentation, it promotes bloc_test package to facilitate writing unit tests.

After playing around with this package and the main testing facility it exposes, I couldn't write the kind of unit tests I was looking for.

So what's the deal 🤷🏽‍♂️

The problem is trying to assert that a certain state has being emitted independently of how current state has been built up or what its concrete value is.

blocTest does seem to have an option to skip a number of previously emitted values and to seed the current state and start from there. But this is a bit annoying in my opinion since you might not now how many emissions have been sent for a particular state to be reached
and using seed might be error prone and difficult to build the correct seed.

I love using the matchers package to do more flexible assertions, but to my surprise matchers didn't play around very nicely with blocTest function (I might be missing something, leave a comment if you know a workaround)

With blocTest you have to explicitly say what previous states have been (or skip them).

blocTest(
    'emits [-1] when CounterEvent.decrement is added',
    build: () => counterBloc,
    act: (bloc) => bloc.add(CounterEvent.decrement),
    expect: () => [-1], // the history of all emitted states up until now :(
);

I tried using matchers in the expect parameter but did not work.

Solution 🏆

Much like the solution proposed in the previous article about mobx testing but this time wrapped in custom testing method.

This a what you get:

cubitTest('Emits loaded state when registration service succeeds',
    build: () => sut,
    stateField: (RegistrationState state) => state.status,
    arrange: () {
      when(
        () => mockRegistrationService.register(
            email: any(named: 'email'), password: any(named: 'password')),
      ).thenAnswer((_) async {
        return;
      });

      sut.updateEmail('daniel@gmail.com');
      sut.updatePassword('12345678');
    },
    act: (RegistrationCubit cubit) => cubit.register(),
    assertions: (MockCallable<Status> updatesStatusWith) {
      verify(() => updatesStatusWith(Status.loaded));
    });

This example can work perfectly with either:

verify(() => updatesStatusWith(Status.loaded)),

// OR

verifyInOrder([
  () => updatesStatusWith(Status.loading),
  () => updatesStatusWith(Status.loaded),
]);

This is exactly what I want, I can do an assertion on particular property and don't need to reason about what the previous states have to be and how to get there.

Note in this example I'm using mocktail instead of mockito but either could be used. Same goes for cubit or bloc

Brief explanation

Very similar to blocTest this also gives the same feel for arrange, act, assert structure but with some key differences, here is a short explanation of critical parameters:

stateField is interesting because it allows selecting a the particular state property you're interested in.
assertions is a closure with a single parameter of type MockCallable where T will be whatever you selected with stateField

Note that stateField could be the identity function in which case you could do assertions over the entire state

Also you might think build should return new instances of the bloc or cubit but I actually reuse the same instance for all tests so I can use the setup method and benefit from that as well.

And here is the implementation of the test wrapper:
github gist.

abstract class Callable<T> {
  void call([T? arg]) {}
}

class MockCallable<T> extends Mock implements Callable<T> {}

@isTest
void cubitTest<P, S, B extends BlocBase<S>>(
  String description, {
  required B Function() build,
  required FutureOr Function(B) act,
  required P Function(S) stateField,
  Function? arrange,
  Function(P)? inspect,
  required void Function(MockCallable<P> updatesWith) assertions,
}) async {
  test(description, () async {
    final expectation = MockCallable<P>();
    arrange?.call();
    final bloc = build();
    bloc.stream.listen((S state) {
      final focusedProperty = stateField(state);
      inspect?.call(focusedProperty);
      expectation(focusedProperty);
    });

    await act(bloc);
    await bloc.close();

    assertions(expectation);
  });
}

Hope you liked this and found it helpful in some way!

Until next time...

Testing Mobx stores in Flutter

Daniel Cardona Rojas — Fri, 30 Apr 2021 02:33:53 +0000

I've been using mobx in a couple of projects and have enjoyed its pragmatic and boilerplate free approach to state management.

Having said that when it came to testing I did not find a good way to write the kind of tests I wanted, although the documentation for mobx in Flutter is great https://mobx.netlify.app/ I found it lacking when trying to figure out how write robust unit tests. Luckily I found quite a nice approach that I'd like to share in this post.

The main requirement I had was to be able to test multiple state changes within a single action in a store.

Let me give a common example that motivates this requirement. Lets suppose we have a store that fetches items of a feed.

Most of the time we want to have some state property that reflects if the feed is in the loading, has failed to fetch items or has finally received the items from a service

The problem

In mobx stores an action can mutate an observable property multiple times

For example:

@observable
Status status = Iddle();

@observable
List<Item> items = [];

@action
Future<void> getItems() async {
  status = Loading();
  items = await _service.getItems();
  status = Loaded();
}

Since state management in mobx unlike bloc is not stream based. Its not obvious how to check intermediate mutations of an observable property within the action. If you await the action you will only be able to inspect the final value of the inspected property.

test('store emits status values for loading, loaded when fetching items', () async {
  // arrangement code

  assert(store.status == Iddle());
  await store.getItems();

  // Check that status passed through Loading value

  assert(store.status == Loading()); // Will fail!!!
  assert(store.status == Loaded());

});

Reactions 🧪 to the rescue 🎉

The solution comes down to using a mobx reaction to observe mutations of a property within the store.

I'll introduce an extra class that is required for this approach

import 'package:mockito/mockito.dart';

abstract class Callable<T> {
  void call([T arg]) {}
}

class MockCallable<T> extends Mock implements Callable<T> {}

So going back to our example this is how the test could be written:

test('store emits status values for loading, loaded when fetching items', () async {
    final statusChanged = MockCallable<Status>();

    when(mockService.getItems())
        .thenAnswer((_) async => fakeItems);

    mobx.reaction<Status>(
        (_) => store.status, (newValue) => statusChanged(newValue));

    await store.getComments();

    verifyInOrder([
      statusChanged(Loading()),
      statusChanged(Loaded()),
    ]);

});

This actually turns out to be easier to test then BLOC in my opinion, since bloc tests require you to specifically state the exact value for all emitted states. In mobx using this approach you can opt in to this by testing a single mutation or a sequence of mutations ocurring in an action using any of the matchers that are provided out of the box by mockito.

Here are some other examples assertions that could be made in other test that showcase the flexibility you get with different types of matchers.

// Or
verify(statusChanged(any)).called(2);

// Or
verify(
  statusChanged(argThat(allOf(Loaded(), Loading())))
);

// Or
verify(
  statusChanged(argThat(anyOf(Loaded(), Loading())))
);

Edit: As a bonus here is a simple wrapper that can help get rid of some of the boilerplate setup:

@isTest
void mobxTest<S extends Store, P>(
  String description, {
  @required S Function() build,
  @required FutureOr Function(S) act,
  @required P Function(S) stateField,
  Function arrange,
  Function(P) inspect,
  @required void Function(MockCallable<P> updatesWith) assertions,
}) async {
  test(description, () async {
    final expectation = MockCallable<P>();

    arrange?.call();

    final store = build();
    reaction<P>((_) => stateField.call(store), (P newValue) {
      inspect?.call(newValue);
      expectation.call(newValue);
    });

    await act?.call(store);

    assertions(expectation);
  });
}

I suggest looking into the matchers package to see all the cool matchers.

Personally like anyOf matchers which allows to check that a particular value has been emitted without having to check previous or future values.

I hope you liked this post, let me know your opinions, cheers!

Easy field masking in Swift

Daniel Cardona Rojas — Sun, 16 Aug 2020 00:27:18 +0000

When working with forms its is very likely that you will need to do field masking.

In this short article I want to present a small and flexible library called Veil that allows us to do this very easily.

Veil is a pure swift library that is available through Swift Package Manager, it does not depend on UIKit and instead
is a pure string processing utility, so use on any platform with UIKit or SwiftUI.

If you're a iOS developer its very likely that you might have stumbled with this problem and might have tried solving this by implementing UITextFieldDelegate
shouldReplaceCharacters:in range method. This is usually a painful experience as dealing with ranges is all around not that comfortable.

Veil offers a very simple solution to masking which does not require the developer to implement UITextFieldDelegate, instead can be easily
used with target action pattern.

Examples

Referring the documentation of the official repository, we can see a common example of formatting date input
into mm/yy

let dateMask = Veil(pattern: "## / ##")
let result = dateMask.mask(input: "234")
// result = "23 / 4"

So first we need to supply some masking pattern, Veil uses a default configuration (which can be replaced)
where # represent digits while * any character. Anything else within the pattern will be
inserted automatically into the resulting string, so typing "234" will yield "23 / 4" (including spaces).

Usage with UITextField

let dateMask = Veil(pattern: "## / ##")

@objc func textDidChange(_ sender: UITextField) {
    guard let currentText = sender.text else  {
        return
    }

    sender.text = dateMask.mask(input: currentText, exhaustive: false)
}

How it works

Internally Veil parses the pattern string into an array of tokens where a Token is

enum Token {
    case digit, any
    case symbol(Character)
}

So a pattern like "## / ##" will result in the array of tokens:

[.digit, .digit, .symbol(" "), .symbol("/"), .symbol(" "), .digit, .digit]

It will walk through input string matching against the token pattern until either is exhausted.
This also implies you get automatic input blocking.

I encourage everyone to give this a try, and let me know you're thoughts.

Thanks!

Form validations with Bloc + Verify

Daniel Cardona Rojas — Mon, 06 Apr 2020 13:21:25 +0000

Not too long ago I published a Dart package to pub.dev called verify,
Its a package to do validations. In this post I want to overview some of its
capabilities and explain some approaches on how this could be used in a real
world application.

Verify overview

Verify defines a Validator as any function with the following signature:
This type of ideas arise naturally in function programming languages.

typedef Validator<S, T> = Either<List<ValidationError>, T> Function(S subject);

As can be observed the Validator is generic over the input and output type of the function
and has a contract on what errors through an abstract class ValidationError.

For those who are familiar to these abstractions can already see how definitions of map, flatMap etc... can easily be derived.

Everything else boils down to creating different ways to combine these functions into more complex validators and having good ergonomics for developers to easily create custom validators.

Check the official API for more details.

Let build something

I won't get to theoretical with Verify instead jump straight into an example.
I will demonstrate how a sign up form page could be built and validated with
bloc and verify packages.

Are form will be real simple with an email, password and password confirmation input fields.
If you want to see the full source for this checkout out the examples
folder of the package repository.

Bloc setup

As you probably already know when building a reactive UI with Bloc, first thing is modeling state, and events.

For this we will use the freezed package to have value equality and some other goodies.

Events

Lets start out with modeling out events. We will need to be able to modify our states email, password and password confirmation fields. We usually would have submit event too. But lets keep it simple since we won't be connecting to service in this example.

@freezed
abstract class SignUpEvent with _$SignUpEvent {
  const factory SignUpEvent.setEmail(String email) = SignUpSetEmail;
  const factory SignUpEvent.setPassword(String password) = SignUpSetPassword;
  const factory SignUpEvent.setPasswordConfirmation(String password) =
      SignUpSetPasswordConfirmation;
}

State

Lets start modeling our state. We now we have to track the email, password and password
confirmation field so we put all those in our state. We will also need to display validation errors this seems logical to track with a Map that contains errors grouped by
input field type, so that we can easily get the errors for an specific field.

enum SignUpFormField {
  email,
  password,
  passwordConfirmation,
}

@freezed
abstract class SignUpState with _$SignUpState {
  const factory SignUpState(
      {String email,
      String password,
      String confirmation,
      Map<SignUpFormField, List<String>> errors}) = _SignUpState;

  factory SignUpState.initial() {
    return SignUpState(errors: {
      SignUpFormField.email: [],
      SignUpFormField.password: [],
      SignUpFormField.passwordConfirmation: [],
    });
  }
}

the base bloc implementation should be pretty straight forward.

Stream<SignUpState> mapEventToState(SignUpEvent event) async* {
    final newState = event.when(
        setEmail: (str) => state.copyWith(email: str),
        setPassword: (str) => state.copyWith(password: str),
        setPasswordConfirmation: (str) => state.copyWith(confirmation: str),
    );
    yield newstate;

}

Integrate validations with Verify

To start out with verify, you first must define some error type and implement
ValidationError. To do this we will equip our error type with the field it references.

class SignUpError implements ValidationError {
  final SignUpFormField field;
  final String message;

  SignUpError({@required this.field, @required this.message});

  @override
  String get errorDescription => message; // ValidationError requirement
}

Now that we have our error type in place. Let's define a validator.
I will show one way of doing this, but the same result could be achieved using the
provided verify combinators in different ways. Checkout out the docs to see
all available options.

Notice how we can bypass validators for some conditions. For instance we want to
have matching password and confirmation, but also want to ignore these checks if the confirmation field is null or perhaps empty.

final Validator_<SignUpState> signUpValidation = Verify.all<SignUpState>([
  Verify.subject<SignUpState>().checkField(
      (state) => state.password,
      Verify.property((s) => s.length > 4,
          error: SignUpError(
            field: SignUpFormField.password,
            message: 'incorrect length',
          ))),
  Verify.subject<SignUpState>().checkField(
      (state) => state.email,
      Verify.property((s) => s.contains('@'),
          error: SignUpError(
            field: SignUpFormField.email,
            message: 'invalid format',
          ))),
  Verify.property((SignUpState state) => state.confirmation == state.password,
      error: SignUpError(
        field: SignUpFormField.passwordConfirmation,
        message: 'not match',
      )).ignoreWhen((state) => state.confirmation == null),
]);

Bloc integration

Finally lets update our bloc to validate the state after input updates:

Stream<SignUpState> mapEventToState(SignUpEvent event) async* {
    final newState = event.when(
        setEmail: (str) => state.copyWith(email: str),
        setPassword: (str) => state.copyWith(password: str),
        setPasswordConfirmation: (str) => state.copyWith(confirmation: str),
    );

    final errors = signUpValidation
        .verify<SignUpError>(newState)
        .groupedErrorsBy((error) => error.field)
        .messages;

    yield newState.copyWith(errors: errors);

}

The UI should be straightforward so I won't discuss that. If you want to see the complete example
head over to the examples folder of the repository.

DanielCardonaRojas / verify

A Dart validation DSL to validate your flutter app models.

Validations made simple

A fp inspired validation DSL. For Dart and Flutter projects.

Features

Completely extensible (create your own combinators, validator primitives, etc)
Flexible Verify is an extension based API (There is not single class created its all pure functions)
Customizable (Define you own error types if required) organize validators how ever you want
Bloc friendly (See examples for a concrete implementation)
Null safe (as a prerelease)

Usage

Creating validators

A Validator is just a simple function alias:

// One of 2 variats depending on wether the validated subject will be transformed into another type or not
typedef ValidatorT<S, T> = Either<List<dynamic>, T> Function(S subject);
typedef Validator<S> = Either<List<dynamic>, S> Function(S subject);

So you can create your own validator by just specifying a function for…

View on GitHub