**Episode 17:** by Toby Huang in San Francisco, CA (January 2021)  

[Previous episodes](https://developer.chrome.com/docs/chromium/chronicle)

Browser tests are a form of automated testing for chromium code that are more
end-to-end than unit tests. Browser tests create browser instances and test
various UI elements instead of just testing pure input/output functionality
like unit tests do. Integrated automated testing is important for simulating
the user's end-to-end experience. When writing a browser test, you often want
to programmatically perform setup actions that the user could do manually.
To help you do this, **mixins are a suite of tools for performing non-trivial
browser test setup in a reusable way.**

Examples of useful mixins:

- `GuestUserMixin` for testing incognito mode
- `UserPolicyMixin` for mocking user policy from the server
- `FakeGaiaMixin` for mocking responses from the Gaia server

**You can create your own custom mixins** to serve a wide variety of purposes!

The snippet below logs in as a guest user for your test. It is important to
**make sure your feature works in incognito mode.**
Do

```c++
class MyGuestBrowserTestClass : public MixinBasedInProcessBrowserTest {
 private:
  GuestSessionMixin guest_session_mixin_{&mixin_host_};
};
```

`LoggedInUserMixin` is a convenient way to log in as a Family Link user for
your test. If your feature affects anything related to child supervision,
you should **test your feature for supervised users** . A possible bug is
forgetting that child users have incognito mode disabled or can't install
extensions without parent approval. `LoggedInUserMixin` is a compound mixin
composed of other mixins.
Do

```c++
class MyChildBrowserTestClass : public MixinBasedInProcessBrowserTest {
 protected:
  void SetUpOnMainThread() override {
    MixinBasedInProcessBrowserTest::SetUpOnMainThread();
    logged_in_user_mixin_.LogInUser();
  }

 private:
  LoggedInUserMixin logged_in_user_mixin_{&mixin_host_,
                                          LoggedInUserMixin::LogInType::kChild,
                                          embedded_test_server(), this};
};
```

One of the primary benefits of mixins is **using composition instead of
inheritance, and avoiding problems with diamond multiple inheritance** .
Inheriting from more than one test base class leads to the diamond problem,
but you can mix and match mixins while avoiding this issue. Using mixins
doesn't entirely get rid of inheritance because the browser test class still
needs to inherit from `MixinBasedInProcessBrowserTest`, but fortunately that
base class is general-purpose and lightweight.

## Resources

- [User types in Chromium and ChromiumOS](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/login/user_types.md)