DEV Community: Peter Bryant

How to actually do TDD in Flutter

Peter Bryant — Thu, 04 Aug 2022 08:59:46 +0000

This post is the result of a months-long existential crisis about how to do testing in Flutter apps. There are so many resources, tutorials, and opinions on how this should be done, but most of them give what is, in my opinion, bad advice.

The aim of this post is to put forward a case for a change in direction. The Flutter community is barrelling towards a nightmare of unmaintainable test suites, and development practices which waste more time than they save. We need to look at the practices we're encouraging as a community and ensure that we are promoting good engineering that delivers value to our customers.

A lot of the ideas in this post came from a fantastic talk by Ian Cooper at Devternity 2017 called "TDD: Where did it all go wrong?" It's worth watching that video first before trying to apply the ideas to Flutter. Here's the link: 🚀 TDD, Where Did It All Go Wrong (Ian Cooper)

The problems we're trying to solve

Tests hold us hostage. When we write over-specified tests, we couple them to our implementation details. This means that any changes we make to the implementation are likely to break a bunch of tests. This is extremely frustrating for a development team to have to deal with. It makes things difficult when they're supposed to be easy.
Achieving high coverage is hard. When we test at class level - which most of the advice says we should - we can get fairly good test coverage without too much trouble. But the last 20% or so is usually extremely difficult to cover, and often gets left out. This means that there is loads of untested code in our project.
Writing tests takes too long. We seem to spend most of our time writing fiddly tests to cover things that we know should just work.
Maintaining high coverage is hard. The first three problems combined mean that over time, coverage slowly deteriorates as developers give up covering their changes with appropriate tests.

Some rules for TDD

If we're going to solve the problems above and still have a well-tested app, we need to learn (or re-learn) some important principles. Some of these were totally new to me; some I knew but didn't understand properly.

A unit is not a class. Or a method, or a function. A unit is an encapsulation of functionality, which could be implemented as lots of classes, or a single function, or an entire app. It's a super unhelpful word. I've stopped using the phrase "unit tests"; I call them "developer tests" or "automated tests" now.
Test behaviour, not implementation. You should write tests based on requirements like, "When I type in a valid email and password, then press the login button, I should be taken to the home screen." Don't write tests like this: "When I type in a valid email address and password, then press the login button, the login method on the AuthRepository class should be called with the correct parameters."
UI design is not behaviour. It is totally impractical and unnecessary to test the design of your app using automated testing techniques such as golden testing. It holds your design hostage and means your tests break anytime you want to tweak something visual which doesn't actually change how the app works. The tooling is also horrible. This is precisely the purpose of human QA.
Tests must not drive code design decisions. I've seen some well-respected thought leaders in software engineering say that the design of your code should be informed or even dictated by your tests. But this breaks one of the fundamental rules of TDD, which is that tests should not be coupled to the implementation of the behaviour under test. If your tests require you to design your code in a particular way, you've written your tests wrong.
Don't mock your own code. I've often done this in order to isolate the class I'm testing from its dependencies. It's unnecessary, as we'll discover.
Don't skip the refactoring step. The red-green-refactor cycle is much more important for TDD than most developers realise.

An example

Let's build a very simple password reset screen. It has a field for you to enter a username, which can't be blank, and a button which submits the request. If the request fails, we want to show the error message. Otherwise, we want to go back to the login screen.

In this example, the app uses Firebase Auth. Because this is an external dependency, we're going to use a test double which mimics the behaviour of the real FirebaseAuth implementation. If you were using a different authentication system which worked over HTTP requests, you could use something like http_mock_adapter to fake your API responses.

We're also using Riverpod as our DI solution. These techniques obviously don't require Riverpod, but I've found Riverpod to be the best DI/state management solution, so it's what I use.

Step 1: Write a test (or set of tests) that fails

void main() {
  group('reset password screen', () {
    testWidgets(
      '''goes to the login screen when a valid username is entered and the request succeeds''',
      (tester) async {
        final auth = MockFirebaseAuth(signedIn: false);

        await tester.pumpWidget(
          ProviderScope(
            overrides: [
              firebaseAuthProvider.overrideWithValue(auth),
            ],
            child: MyApp(
              initialRoute: '/login/forgot-password',
            ),
          ),
        );

        await tester.enterText(
          find.byKey(const Key('forgot-password-username-field')),
          'username',
        );

        await tester.tap(
          find.byKey(const Key('forgot-password-submit-button')),
        );

        await tester.pumpAndSettle();

        expect(
          find.byType(LoginWidget),
          findsOneWidget,
        );
      },
    );

    testWidgets(
      '''displays an error message in a snackbar when the user is not found'''
      (tester) async {
        final auth = MockFirebaseAuth(
          signedIn: false,
          authExceptions: AuthExceptions(
            sendPasswordResetEmail: FirebaseAuthException(code: 'auth/user-not-found')
          ),
        );

        await tester.pumpWidget(
          ProviderScope(
            overrides: [
              firebaseAuthProvider.overrideWithValue(auth),
            ],
            child: MyApp(
              initialRoute: '/login/forgot-password',
            ),
          ),
        );

        await tester.enterText(
          find.byKey(const Key('forgot-password-username-field')),
          'username',
        );

        await tester.tap(
          find.byKey(const Key('forgot-password-submit-button')),
        );

        await tester.pumpAndSettle();

        expect(
          find.text('User not found'),
          findsOneWidget,
        );
      },
    );

    testWidgets(
      '''shows a validation error when no username is entered''',
      (tester) async {
        await tester.pumpWidget(
          ProviderScope(
            child: MyApp(
              initialRoute: '/login/forgot-password',
            ),
          ),
        );

        await tester.tap(
          find.byKey(const Key('forgot-password-submit-button')),
        );

        await tester.pumpAndSettle();

        expect(
          find.descendant(
            of: find.byKey(const Key('forgot-password-username-field')),
            matching: find.text('Please enter your username'),
          ),
          findsOneWidget,
        );
      },
    );
  });
}

Some important things to note about this test:

We are running the whole app, rather than only pumping the widget under test. This is so we don't have to bother with any navigation mocking.
We always refer to widgets by keys, not by types. This is to ensure we can change the type of widget without the test breaking (e.g. if an ElevatedButton becomes a TextButton). – The exception to this rule is when we check that the LoginWidget is visible. I think this is fine as the alternative would be wrangling to find the path of the current route or something.
We're not using any mock-style verifications to check that the correct method was called on the FirebaseAuth class. This would couple our test to the implementation details, which we must not do.

Run the tests and, of course, they all fail. Let's make them pass.

Step 2: Make the test pass by making a mess

Here, we just need to write as little code as possible to make sure the test passes.

class ForgotPasswordWidget extends ConsumerStatefulWidget {
  const ForgotPasswordWidget({super.key});

  @override
  ConsumerState<ForgotPasswordWidget> createState() => _ForgotPasswordWidgetState();
}

class _ForgotPasswordWidgetState extends ConsumerState<ForgotPasswordWidget>() {
  final _formKey = GlobalKey<FormState>();
  final _usernameController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Form(
        key: _formKey,
        child: Column(
          children: [
            TextFormField(
              key: const Key('forgot-password-username-field'),
              controller: _usernameController,
              validator: (value) {
                if (value!.isEmpty) {
                  return 'Please enter your username';
                }
                return null;
              },
            ),
            ElevatedButton(
              key: const Key('forgot-password-submit-button'),
              onPressed: () async {
                if (_formKey.currentState!.validate()) {
                  final auth = ref.read(firebaseAuthProvider);

                  try {
                    await auth.sendPasswordResetEmail(
                      email: _emailController.text,
                    );
                  } on FirebaseAuthException catch (e) {
                    if (e.code == 'auth/user-not-found') {
                      ScaffoldMessenger.of(context).showSnackBar(
                        SnackBar(content: Text('User not found')),
                      );
                    }
                  }
                }
              },
              child: Text('Submit')
            ),
          ],
        ),
      ),
    );
  }
}

In a real app, you would also need to ensure you've set your router up correctly.

That's it! This code is sufficient to ensure all our tests pass. A couple things to note:

If we ran this app, it would look terrible. We haven't applied any UI design to it yet. That's okay.
Because it's a very simple example, the code looks okay. In a more complex widget, your code might be horrible and messy. That's okay too.

We can now move on to the final step.

Step 3: Refactor, keeping the tests green all the way

We now come to the most important and useful step of TDD. We have a basic implementation which we can prove is working. Now we can begin refactoring: the process of changing the design of our code and/or the UI without changing the behaviour and causing the tests to fail.

Each time we make a change, we can run the tests again to make sure we haven't broken something.

In terms of refactoring, if you're not sure where you might go from here there is a great resource at refactoring.guru which helps you identify opportunities to improve the design of your code. You could extract methods or classes to separate concerns; you could improve variable naming; you could generalise something to make it reusable. The important thing to remember is that anything you do from here should not change the way the screen behaves, and your tests should pass after every refactoring step.

This is also the moment at which you apply the UI design. Add fancy animations, loading states, pretty pictures, and all the rest. But don't change the functionality required by your tests.

By the end, you should find that you have well-designed code that is 100% covered by tests. If your coverage is below 100%, that must mean that you've written some code that you didn't need to, or introduced new behaviour that isn't tested. Get rid of anything that you haven't written a test for, or write tests for the stuff you know you need.

Of course, any external dependencies you're mocking (like FirebaseAuth in my example) won't be covered by tests. That's okay - if you're using Riverpod you can just exclude the providers from coverage reports:

// coverage:ignore-start
final firebaseAuthProvider = Provider((_) => FirebaseAuth.instance);
// coverage:ignore-end

You've made a deliberate and good decision never to use this dependency in a test, so ignoring it in coverage reports is totally appropriate and justified.

The result

We have a suite of tests which protects the behaviour of our code without locking in its implementation. We can re-implement parts of this code without breaking the tests. We will only need to change the tests if we're changing the behaviour (e.g. if we wanted to disable the Submit button until the user has entered a username).
High code coverage is easy to achieve this way. By not mocking our own code, we cover huge swathes of it with very few tests.
It was fast, and we got meaningful feedback at every step.
The burden of maintaining these tests will be low, and it's easy to keep coverage high.

Adopting this approach allows you to use your tests as a tool rather than a shackle. They give you confidence when refactoring by ensuring nothing more than that the behaviour of your code stays consistent. Tests should never hold you to any particular implementation or design, and our tests don't.

The other important aspect of this approach is that it's astonishingly easy. You write fewer tests, and those tests are a much lower maintenance burden.

All this means you can provide value to your users and customers faster, while still having a well-tested codebase. Truly the best of both worlds.

Approaches to dependency injection in Flutter

Peter Bryant — Fri, 06 May 2022 08:07:23 +0000

Any object-oriented software project worth it's salt should adopt a dependency injection pattern. But when it comes to Flutter apps, there are far too many options. So what do all these options look like, and which is best?

Side-note: on state management

A lot of the packages and techniques we're covering here cross over into the world of State Management. But dependency injection and state management are not the same thing, and shouldn't be considered as such.

State management is strictly to do with the state of your app's user interface. Should this button be enabled? What's the content of this text field? What page are we on right now?

Dependency injection is concerned with providing each class within your app with the dependencies it needs to function e.g. a Bloc class depending on a Repository.

As it happens, there are a lot of Flutter packages which advertise themselves as both state management packages and dependency injection frameworks. They're not wrong, but this can sometimes cause some confusion when developers conflate the two patterns.

What are we trying to achieve?

Dependency injection can be achieved without any special packages or techniques. Consider this class:

class ClassA {
  // Some implementation...
}

class ClassB {
  final objectA = ClassA();

  // Some implementation...
}

Here, we have two classes: ClassA, and ClassB. ClassB includes an instance of ClassA as part of its implementation; in other words, ClassB depends on ClassA.

However, the code above has some problems.

Let's say we change the implementation of ClassA such that its constructor changes. We now have to go through our code and find every instance of ClassA and change its constructor call. That's hugely tedious and will very quickly become impossible to maintain.

Another issue is to do with testing. In our implementation above, ClassB is deciding exactly what version of ClassA it will use. So what about when we want to write unit tests for ClassB? We will also find ourselves testing the implementation of ClassA, which will add lots of complexity to our tests and ultimately make them less useful.

We can solve these problems using the Dependency Injection pattern, which simply involves providing a class's dependencies via its constructor:

class ClassB {
  ClassB(this.objectA);

  final ClassA objectA;
}

Now, we can pass whatever object we want as objectA, including a mocked version of ClassA. It also ensures that if the constructor for ClassA changes, the implementation of ClassB doesn't need to change too. This improves the separation of concerns and makes ClassB independently testable.

We can even take this one step further by extracting ClassA's interface into an abstract version:

class ClassB {
  ClassB(this.objectA);

  final InterfaceA objectA;
}

This ensures that ClassB is entirely independent of the underlying implementation of InterfaceA, which further decreases coupling, and achieves dependency inversion.

We don't actually need frameworks

The obvious conclusion of the definition above is that dependency injection is astonishingly simple. So why are there so many frameworks and packages for it?

The answer is largely about hiding complexity for developers. In large applications, the relationships between classes can become pretty complex. There are a few challenges in particular for Flutter apps:

Environments – how can I make it easy to switch between staging/test dependencies and production ones?
Scopes – how can I control which dependencies should be available to which dependent classes? How do I know whether or not I'm missing a dependency in a given scope?
Lifecycles – how can I understand and control when dependencies should be created, recreated, or destroyed?

A handful of frameworks and patterns exist, and each of them approaches the three concerns above in a slightly different way. I'm going to compare two extremely popular packages which represent the two most common approaches to dependency injection.

Provider

Provider is an extremely popular library/pattern in the Flutter world which takes advantage of Flutter's InheritedWidget to provide dependencies via the widget tree.

This makes it astonishingly simple to manage dependencies. All you have to do is wrap a widget with a Provider:

Provider<ClassA>(
  create: (context) => ClassA(),
  child: MyApp(),
);

Now, any child of the MyApp widget can access the instance of ClassA like this:

context.watch<ClassA>(); // Makes the widget listen to changes in `ClassA` and rebuild
context.read<ClassA>(); // Returns the instance of `ClassA` without listening to it

So how well does Provider address the 3 concerns above?

Environments: Provider doesn't have any built-in mechanism for environment management, which gives you the freedom to manage environment variables however you like. You could have different main.dart files for each environment, or use Dart's fromEnvironment methods to read variables passed in via the flutter build and flutter run commands. It's up to you!
Scopes: You can scope your dependencies using Provider by only wrapping the widgets whose children need access to the given dependency. This makes a lot of sense for Flutter apps! A couple of disadvantages do exist though:
Lifecycles: You get quite a lot of flexibility when it comes to deciding when objects are created by Providers. You can either let the Provider manage creation for you (and you get to decide whether it does lazy instantiation or not), or you can manage the creation of the dependency yourself and use a Provider.value constructor to inject the object into the widget tree. This flexibility covers most requirements you might have when it comes to dependency lifecycle management.

There are some other things to consider when using Provider:

There is a limitation in that you can only have one Provider per type in your Widget tree. If you have more than one Provider<ClassA>, then context.read will just retrieve the closest one. This doesn't usually cause too many problems but is something to be aware of.
Provider's error messaging is really helpful, which is a bonus when it comes to debugging
Provider is the preferred dependency injection solution for the Bloc library, if you like to use that for state management

Overall, I really like the flexibility and simplicity of Provider!

GetIt + Injectable

GetIt describes itself as a service locator for Dart, and when paired with Injectable it becomes a full dependency injection framework, with lots of similarities to Dagger/Hilt from the Android world.

Injectable relies on code generation to automatically write initialization code for GetIt. You can create an “injectable” class by simply annotating it with @injectable (or @singleton).

Instances of dependencies can then be accessed using this syntax: GetIt.I<ClassA>(). Notice that there's no dependency on a BuildContext here; unlike Provider, GetIt dependencies exist outside the widget tree.

How does it handle our three concerns?

Environments: Injectable includes great support for managing environments. You can create a number of Environment objects and use them to annotate your dependencies (e.g. @staging, @production). You then specify which environment you want when initializing GetIt. This is really intuitive!
Scope: Scope is less easy to manage with GetIt. It's all manual so you would need to remember to reset your scopes when required according to events taking place in your app. This is easy to mess up and difficult to test.
Lifecycles: You do get some flexibility when it comes to lifecycles with GetIt/Injectable. You can choose whether dependencies are created fresh each time they're requested (a factory), or whether the same instance is passed on each request (a singleton). You can also choose whether dependencies are initialized lazily or not. You also have some control over when singletons are invalidated and need to be recreated. But the documentation around this isn't very comprehensive.

Overall, I'm not a huge fan of this approach for one reason: having global access to any dependency feels like a bit too much power to put in the hands of your team! It's far too easy to break conventions around the hierarchy of dependencies when you can just pull in whatever dependency you like from anywhere in your app. And while I'm not against code generation in principle, this doesn't feel like a problem that needs to be solved with more code generation.

Lots of other packages exist which are extremely similar to GetIt/Injectable, including Kiwi, Injector, Scope, and Stark. These are all different variations on the same idea of using a “container” to store and provide dependencies from outside the widget tree, and they all have the same advantages and drawbacks.

Packages we haven't talked about

Riverpod, which is not a DI framework but is often mistaken for one.
Bloc. Again, not a DI framework but does include Provider-style dependency injection features. You can use Bloc without using Provider, but I think it works best with the Provider-style approach.

Which approach is better?

Personally, having worked with GetIt/Injectable for a very long time and experimented with Provider more recently, I'm leaning very strongly towards the Provider-style approach to dependency management. It feels much more Flutter-native, and it's much more transparent in terms of how scopes and lifecycles are managed. That said, I can see it getting tedious when a project gets really big, and Injectable's code generation would certainly solve the complexity problem for larger projects.

What do you think? Are there any frameworks or approaches I've missed? Do you agree that Provider is generally the better approach for Flutter apps?

Why Bloc + Freezed is a match made in heaven

Peter Bryant — Sat, 23 Apr 2022 08:06:25 +0000

I'm a big fan of the Bloc library for Flutter apps, and when coupled with the freezed package for creating immutable data classes and sealed unions, I think this pattern really shines.

Sealed whats?

Let's start with some definitions. In other languages (like Kotlin), there are patterns available such as union types, sealed classes, and pattern-matching.

These are all slightly different expressions of the same idea: that you can create a class with a fixed set of subclasses, linking together multiple otherwise separate types under one “umbrella” class.

Shapes are a good example of how this could be used. Here's an example in Kotlin:

sealed class Shape

data class Square(val sideLength: Int): Shape()

data class Rectangle(val length: Int, val width: Int): Shape()

data class Circle(radius: Int): Shape()

Here we are defining 3 classes – Square, Rectangle, and Circle. Each has its distinct properties, but we're able to have them all extend the Shape superclass.

More importantly, because Shape is a sealed class, no other subtypes can be defined outside this file; in other words, we can restrict the subtypes of Shape to the ones we define.

So why would this be helpful when using the Bloc pattern?

Let's consider a simple Counter bloc. It would have two Events: CounterIncremented and CounterDecremented. In pure Dart, we would have to do something like this:

abstract class CounterEvent {}

class CounterIncremented extends CounterEvent {
  CounterIncremented(this.incrementBy);

  final int incrementBy;
}

class CounterDecremented extends CounterEvent {
  CounterDecremented(this.decrementBy);

  final int decrementBy;
}

This is fine, but there are a couple of noteworthy issues:

For Blocs with lots of events, you can see how this approach would become very verbose and cumbersome.
The above snippet doesn't take equality operators into account; that's more boilerplate we'd need to add.
When we eventually implement this Bloc, our code will be full of type-casting and type-checking, which is easy to make a mess with.

If we were writing Kotlin, we could solve these problems by implementing CounterEvent as a sealed class with each event type as a data class extending the base class.

sealed class CounterEvent

data class CounterIncremented(val incrementBy: Int) : CounterEvent()

data class CounterDecremented(val decrementBy: Int) : CounterEvent()

Kotlin's data class construct gives us immutability and equality without boilerplate.

But we're not writing Kotlin, and Dart doesn't have support for sealed classes out-of-the-box. We need to find an alternative!

Freezed Events

The freezed package gives us a couple of important abilities: we can create immutable data classes, and we can create sealed unions. Perfect!

Here's what our Counter events would look like using a freezed union:

import 'package:freezed_annotation/freezed_annotation.dart';

part 'counter_event.freezed.dart';

@freezed
class CounterEvent with _$CounterEvent {
    const factory CounterEvent.incremented(int incrementBy) = CounterIncremented;
    const factory CounterEvent.decremented(int decrementBy) = CounterDecremented;
}

With this implementation, freezed has given us two immutable event types with equality operators. It even generates bonus stuff like copyWith and toString methods. This is a totally battle-ready implementation of our CounterEvent type.

When it comes to actually using instances of CounterEvent, freezed also gives us access to some pattern-matching syntax. Here's how we could implement our event handler:

event.when(
    incremented: (incrementBy) => emit(state + incrementBy),
    decremented: (decrementBy) => emit(state - decrementBy),
);

This syntax is helpful for a couple of reasons. First, forces us to account for every possibility; in pure Dart with type-casting, we could easily forget about or ignore certain event types. Second, it's super easy to read and understand!

Freezed States

Let's look at something more complex: writing a state type using freezed. Let's say we have some data to load: we'll probably want an initial state, an error state, and a success state. We also need a loading indicator to show the user when the data is being refreshed.

Using freezed, we can implement a state class like this:

import 'package:freezed_annotation/freezed_annotation.dart';

part 'data_state.freezed.dart';

@freezed
class DataState with _$DataState {
    const factory DataState.initial(bool isLoading) = DataInitial;
    const factory DataState.error(String message, bool isLoading) = DataError;
    const factory DataState.success(Data data, bool isLoading) = DataSuccess;
}

Then, we can implement a BlocBuilder like this:

BlocBuilder<DataBloc, DataState>(
    builder: (context, state) {
        return Column(
            children: [
                if (state.isLoading) _buildProgressIndicator(),
                state.when(
                    initial: (_) => _buildInitial(),
                    error: (message, _) => _buildError(message),
                    success: (data, _) => _buildSuccess(data),
                ),
            ],
        );
    },
);

There are a couple of things to notice here:

Because every state type has an isLoading property, we can access it without knowing what subtype of state we have. Thanks, freezed!
Again, the pattern-matching syntax provided by freezed is extremely useful here in giving us some super-readable code which forces us to handle all possible states.

Is this the perfect solution?

No.

There is no perfect solution! It could very easily be argued that freezed classes are still pretty verbose, and some developers prefer to not rely on code generation in their apps. And some folks just don't like Bloc at all for some reason. That's all fine – do what works for you!

But, having worked on more than 10 new Flutter projects in the past year or so, I've found that this pattern allows us to build and iterate quickly on our code, and improves my team's ability to understand one another's work easily.

As with lots of software engineering patterns and practices, there's no single right way to do things; the most important thing you can do is to pick one pattern and stick to it consistently.

Liked this? Buy me a coffee.

Find me elsewhere online here.

My testing epiphany

Peter Bryant — Wed, 11 Apr 2018 13:15:12 +0000

I've been making apps for about 2 years, and in that time I never understood the community's obsession with unit testing. I figured that if I can run the app and see it working, what's the point in taking loads of time to write automated tests?

The answer revealed itself to me recently.

You don't write tests to make sure your code works now: you write tests so that you can spot your code breaking in the future.

Here's an example. We've written a file in RotaCloud for Android which contains a bunch of functions for working with time. Here's our method for formatting a timestamp - in seconds - as a 24-hour time:

fun Long.secondsToTime() {
    return SimpleDateFormat("HH:mm", Locale.UK)
        .format(this * 1000)
}

This function is pretty important to our app: if it breaks, suddenly everyone's rotas will be displaying incorrect information.

So what happens when a dev unwittingly changes this function like this?

fun Long.secondsToTime() {
    return SimpleDateFormat("HH:mm", Locale.UK)
        .format(this * 100)
}

This change will not cause a crash in the app, but it will mean that the whole system is pretty useless, and our users will not be happy.

So we wrote a test:

@Test
fun secondsToTimeTest() {
    val timeInSeconds = 1523451825
    val expectedTime = "13:03"
    assertEquals(expectedTime, timeInSeconds.secondsToTime())
}

This is a really simple test, but running it before a new release ensures that this vital functionality keeps working.

We can extend these tests to cover some other requirements too e.g. the hour should always be two digits: 09:30 is correct, but 9:30 isn't.

So that was my testing epiphany. It's pretty easy to manually determine whether or not something works, just by looking at it. What automated tests do, however, is ensure that all the app's functionality continues to work in the future, without you having to manually look through the whole thing.

Testing is also incredibly useful for collaborative development: simply require everyone to run the test suite before submitting a pull request, and you'll find yourself having to deal with a lot fewer broken implementations.