Generate Dart "testable" code for Flutter testability

[Hsilgos]

Flutter testing

Flutter unit tests are usually ran on host. Also it's important to disconnect business logic from generated interface to avoid side effects. Following options were investigated.

Dependency injection

There are few external dart libraries which allow to inject dependencies, for example get_it
Unfortunately they require to write or adopt existing code in specific way.

There is no way to replace (inject) package in tests with other package (for example with stubs) like it can be done for Java.

Conditional import

Dart 1.x supported conditional import based on specified compilation flags.
Dart 2.x is not so flexible and supports only limited conditional import based on presence of platform libraries dart.library.xxx, like

import "src/default.dart" 
  if (dart.library.io) "src/io.dart"
  if (dart.library.html) "src/web.dart"
  as impl;

I haven't found a way to use this approach to make conditional imports only for unit tests.

Override lookupFunction

Since all FFI functions are resolved with nativeLibrary.lookupFunction, this lookupFunction (or wrapper around this function) can be overridden and return mocked functions. Such approach could allow to not touch existing code, but provide generated code as extra plugin for testing which replaces __lib.nativeLibrary with overridden version.

The problem here is to return test data from such mocked functions. The functions work with data which is prepared for ffi call, for example Pointer<Void> instead of usual types. This Pointer<Void> must be converted back to the instance of type, perhaps with call to existing generated converter function.

It looks very costly to generate the code which allows to mock functions in convenient way.

TBD

Factory methods

The common approach is to call factory method to select real implementation or mocking runtime. In unit tests those factory methods must be replaced during fixture setup.

abstract class Foo {
    factory Foo(A a, B b, C c) => _factoryMake()

    static void doSomething() => _factoryDoSomething()

    static Foo? get sharedInstance => _factorySharedInstance();

    static Function(A,B,C) _factoryMake = Foo$Impl.make
    static Function() _factoryDoSomething = Foo$Impl.doSomething
    static Function() _factorySharedInstance = Foo$Impl.sharedInstance
}

class Foo$Impl extends __lib.NativeBase implements Foo {
    Foo$Impl.make(A a, B b, C c) {
    }

    static SDKNativeEngine? get sharedInstance {
    }

    static void doSomething() {
    }
...
}

Prototype class

Approach with prototype class looks easier and most convenient.

The requirements after all must be the following.

• The generated code should contain all necessary mechanisms for mocking, no additional flag (i.e. stub) is necessary
• Enums shouldn't be changed
• Structs without calls to ffi also shouldn't be changed
• Classes and structs with methods which are calling ffi must be changes like described below.

Each such class must contain static variable $prototype. This static variable must be initialized with instance of the $Impl class. All calls to constructors, static methods, getters, setters must be performed via $prototype

class Foo {
    factory Foo() => $prototype.make()

    static void doSomething() => $prototype.doSomething()
    static Foo? get sharedInstance => $prototype.sharedInstance;
    set sharedInstance(Foo? value) { $prototype.sharedInstance = value; }

    void someMethod()

    static var $prototype = Foo$Impl()
}

class Foo$Impl extends __lib.NativeBase implements Foo {
    Foo$Impl.make(A a, B b, C c) {
    }

    static SDKNativeEngine? get sharedInstance {
    }

    static void doSomething() {
    }

Example of usage:

Foo.$prototype = MockFoo();

class MockFoo implements Foo$Impl {
  MockFoo();

  @override
  void someMethod() {}
}

[DanielKamkha]

I think that functions that are static in Foo should be non-static in Foo$Impl.

[Hsilgos]

There is a problem with structs with default constructors which may call ffi. The class seems unmockable now. I propose to move constructor to $Impl as well. May be it make sense to do the same for all classes, generated code must look like:

class Foo {
  final Bar bar1;
  final Bar bar2;

  const Foo._(this.bar1, this.bar2);

  factory Foo(Bar bar1, Bar bar2) => $prototype.$init(bar1, bar2);

  static Foo? staticMethod(List<Bar> bars) => $prototype.staticMethod(bars);

  bool nonStaticMethod(Foo foo) {
    /// Call to ffi
  }
}

@visibleForTesting
class Foo$Impl {
  Foo $init(Bar bar1, Bar bar2) {
    return Foo._(bar1, bar2);
  }
  Foo? staticMethod(List<Bar> bars) {
    /// call to ffi
  }
}

[DanielKamkha]

"Custom" constructors are already redirected for structs. Only "field-based" constructors need this additional treatment.

As classes only ever have "custom" ctors, nothing needs to be done for them.