DEV Community: Pejman Yaghmaie

Reuse tests with multiple implementations of a trait in Rust by rstest

Pejman Yaghmaie — Mon, 05 Feb 2024 18:34:49 +0000

Every programming language has its own ways to let us abstract details away, and in Rust it's traits that give us the ability.
Traits in Rust enable lots of flexibilities such as extending functionalities of a data type or dynamic dispatching.
One of them that we'll be focusing on in this article is expressing common behavior of multiple implementations under the interface defined by a trait.

A perfect example of such implementations is a data store. We expect a data store to have the exact same behavior whether it's storing the data in memory or some advanced highly scalable database in the cloud.

On the one hand, we have traits to help us with coordination between the data stores to implement the common interface defined by a trait. On the other hand, while different implementations share the same trait interface, their internal behavior might differ. Therefore, we need to have a good test coverage in order to ensure that all the different implementations behave consistently from the perspective of their dependents.

To effectively achieve such test coverage without duplicating code or writing error prone boilerplate, we need test fixtures which Rust does not support by default. However, we can use rstest which is a great fixture-based test framework for Rust.

In this article we'll practice test driven development and use rstest to accomplish:

Implementing a data store trait in two different ways
Maintaining a good test coverage and ensuring different implementations behave the same
Keeping code and test duplication minimized

TL;DR you can find the code here on GitLab.

Now let's get started by creating a new package.

Getting Started

First of all we need to run a few familiar commands to make a new package for our example and add rstest and rstest_reuse to the dev dependencies.

rstest lets us inject test dependencies (like the data stores we talked about earlier) into different test functions and rstest_reuse makes it possible to apply the same test template on multiple test functions.

$ cargo new rstest_multi_impl_trait 
     Created library `rstest_multi_impl_trait` package
$ cd rstest_multi_impl_trait
$ cargo add rstest rstest_reuse --dev
    Updating crates.io index
      Adding rstest v0.18.2 to dev-dependencies.
             Features:
             + async-timeout
      Adding rstest_reuse v0.6.0 to dev-dependencies.
    Updating crates.io index

Context

Let's say we want to manage some Fruits.

struct Fruit {
    pub id: usize,
    pub name: String,
}

In order to do that, we'll need a FruitStore to add or remove our Fruits for us and also be able to find them. Occasionally, we need to know how many Fruits we have in the store . So, the store should be able to count them.

pub trait FruitStore {
    fn count(&self) -> usize;

    fn add(&mut self, fruit: Fruit) -> Result<(), AddError>;

    fn find(&self, id: usize) -> Option<Fruit>;

    fn remove(&mut self, id: usize) -> Result<(), DeleteError>;
}

Of course, if we add some Fruit twice or try to remove one that doesn't exist, then we expect an error.

enum AddError {
    DuplicateId,
}

enum DeleteError {
    IdNotFound,
}

`VecFruitStore`

We want to keep things simple and that's why we don't want to use a real database or a cloud storage service to implement our FruitStore. Instead we're going to use a Vec<Fruit> as our storage backend.

struct VecFruitStore {
    storage: Vec<Fruit>,
}

impl VecFruitStore {
    fn new() -> Self {
        VecFruitStore {
            storage: Vec::new(),
        }
    }
}

And surely VecFruitStore has to implement FruitStore.

impl FruitStore for VecFruitStore {
    fn count(&self) -> usize {
        todo!()
    }

    fn add(&mut self, fruit: Fruit) -> Result<(), AddError> {
        todo!()
    }

    fn find(&self, id: usize) -> Option<Fruit> {
        todo!()
    }

    fn remove(&mut self, id: usize) -> Result<(), DeleteError> {
        todo!()
    }
}

Empty `VecFruitStore`

It's always a better idea to keep things simple at the start and begin with coding the most simple functions with the most basic inputs. Speaking of data stores, the most simple state of them is surely when they're empty.
Probably the simplest function to test on an empty data store is count since it just needs to return 0. That's where we start then. Needless to say, we're going to write a test before writing any code and follow TDD as mentioned before.

#[cfg(test)]
mod tests {
    #[test]
    fn empty_store_counts_zero() {
        let store = VecFruitStore::new();

        assert_eq!(0, store.count());
    }
}

If we run our new test with cargo test --lib it fails because count is not implemented yet and just includes a placeholder todo!(); So, this is our Red step:

running 1 test
test tests::empty_store_counts_zero ... FAILED

failures:

---- tests::empty_store_counts_zero stdout ----
thread 'tests::empty_store_counts_zero' panicked at src/lib.rs:41:9:
not yet implemented

The easiest change to make the test pass is simply returning 0 from count and that's what we do.

fn count(&self) -> usize {
    0
}

running 1 test
test tests::empty_store_counts_zero ... ok

The next simple thing to test is trying to find a Fruit in an empty store. Certainly, an empty store has nothing to find for you.

#[test]
fn empty_store_finds_none() {
    let store = VecFruitStore::new();
    let fruit = store.find(0);

    assert!(fruit.is_none());
}

And making it pass

fn find(&self, id: usize) -> Option<Fruit> {
    None
}

running 2 tests
test tests::empty_store_counts_zero ... ok
test tests::empty_store_finds_none ... ok

If we remove a Fruit, we should get a delete error.

#[test]
fn empty_store_remove_gives_id_not_found_error() {
    let mut store = VecFruitStore::new();
    let result = store.remove(0);

    assert!(matches!(result, Err(DeleteError::IdNotFound)));
}

fn remove(&mut self, id: usize) -> Result<(), DeleteError> {
    Err(DeleteError::IdNotFound)
}

running 3 tests
test tests::empty_store_finds_none ... ok
test tests::empty_store_remove_gives_id_not_found_error ... ok
test tests::empty_store_counts_zero ... ok

Refactoring tests

In the first line of every test we're creating a new VecFruitStore right now. This is not ideal because:

1) We have duplication
2) How do we reuse our tests if we had another implementation of FruitStore?

To fix these, we need fixture-based tests so it's time for rstest to enter.

#[cfg(test)]
mod tests {
    use rstest::*;
    ...

The next step is to turn our tests from something like:

#[test]
fn empty_store_counts_zero() {
    let store = VecFruitStore::new();

    assert_eq!(0, store.count());
}

#[rstest]
fn empty_store_counts_zero(store: impl FruitStore) {
    assert_eq!(0, store.count());
}

Instead of initializing a new FruitStore in each test case, let's just receive one from somewhere and focus on the testing part. This way we have a test that doesn't care about what exactly is the store that it's evaluating as long is it implements the FruitStore trait.

The next question would be: How the tests receive their store to run?
Well, rstest makes this is easy. All we need to do is throwing in a fixture function.

#[fixture]
fn store() -> impl FruitStore {
    VecFruitStore::new()
}

Applied to all the tests, the result should be the following:

#[cfg(test)]
mod tests {
    use crate::{DeleteError, FruitStore, VecFruitStore};
    use rstest::*;

    #[fixture]
    fn store() -> impl FruitStore {
        VecFruitStore::new()
    }

    #[rstest]
    fn empty_store_counts_zero(store: impl FruitStore) {
        assert_eq!(0, store.count());
    }

    #[rstest]
    fn empty_store_finds_none(store: impl FruitStore) {
        let fruit = store.find(0);

        assert!(fruit.is_none());
    }

    #[rstest]
    fn empty_store_remove_gives_id_not_found_error(mut store: impl FruitStore) {
        let result = store.remove(0);

        assert!(matches!(result, Err(DeleteError::IdNotFound)));
    }
}

running 3 tests
test tests::empty_store_counts_zero ... ok
test tests::empty_store_remove_gives_id_not_found_error ... ok
test tests::empty_store_finds_none ... ok

Get ready to add another `FruitStore`

There's still a catch. If we add another implementation of FruitStore like a HashMapFruitStore which uses a HashMap<usize, Fruit> as storage backend, then how can it be tested by the existing tests? Since the fixture function we wrote earlier only returns a VecFruitStore.

Such situations can easily be handled by rstest_reuse. Just remember that you have to add the following code at the top of the crate (not the module).

#[cfg(test)]
use rstest_reuse;

First we need to get rid of the fixture function and replace it with a template function.

#[template]
#[rstest]
fn fruit_store(store: impl FruitStore) {}

Secondly, we should change the #[rstest] on the tests to #[apply(fruit_store)]. This way rstest can recognize what template has to be applied on which tests.

#[apply(fruit_store)]
fn empty_store_counts_zero(store: impl FruitStore) {
    assert_eq!(0, store.count());
}

Finally, we use case on the template to inject our desired FruitStore.

#[template]
#[rstest]
#[case::vec_fruit_store(VecFruitStore::new())]
fn fruit_store(#[case] store: impl FruitStore) {}

Adding another `FruitStore`

As you have already guessed adding another FruitStore implementation to this test machine is as easy as adding another case on the template like #[case::hashmap_fruit_store(HashMapFruitStore::new())].

#[template]
#[rstest]
#[case::vec_fruit_store(VecFruitStore::new())]
#[case::hashmap_fruit_store(HashMapFruitStore::new())]
fn fruit_store(#[case] store: impl FruitStore) {}

But another problem pops up:

running 6 tests
test tests::empty_store_counts_zero::case_1_vec_fruit_store ... ok
test tests::empty_store_counts_zero::case_2_hashmap_fruit_store ... FAILED
test tests::empty_store_finds_none::case_1_vec_fruit_store ... ok
test tests::empty_store_finds_none::case_2_hashmap_fruit_store ... FAILED
test tests::empty_store_remove_gives_id_not_found_error::case_1_vec_fruit_store ... ok
test tests::empty_store_remove_gives_id_not_found_error::case_2_hashmap_fruit_store ... FAILED

Imagine if we had 100 test cases, then we had to complete the implementation and get all of them passed in order to get a green build. However, the cases also work if on top of the tests. Accordingly, we can add the new case one by one on them until all are covered.

#[apply(fruit_store)]
#[case::hashmap_fruit_store(HashMapFruitStore::new())]
fn empty_store_counts_zero(store: impl FruitStore) {
    assert_eq!(0, store.count());
}

Final words

Nothing can grow our confidence for our work like a great test coverage. Testing should not be something totally separate from our everyday workflow or an afterthought. In this article, we went through an example of implementing a trait of a data store with the same tests with help of rstest. I hope you find it useful.

I'm going to leave the code at the current stage so you'd have something to practice on. So please take a copy of this code from here and start adding more test cases and also continue the implementation.

Development container & Gitlab CI - Build better and faster

Pejman Yaghmaie — Sun, 22 Oct 2023 17:32:08 +0000

One of the benefits of an automated build pipeline is reproducible outcomes. This alone has several other benefits such as more reasonable results, and less surprises. Ideally we want the exact same stuff every time we run the pipeline for a specific version of our code regardless of where we are executing it.

It is encouraged to version control everything that affects the final outcome. Like the code, third party dependencies, all the OS packages required to build our software, the pipeline itself, etc. Additionally, each run has to be isolated to avoid interference of all the side effects caused by the other runs or pipelines.

This approach clearly increases our confidence in the result. But, one of it's biggest caveats is much slower build times. Definitely, it is exhaustive to prepare the environment and commence the build from scratch each time. So, the challenge is to have the predictable outcomes while having it fast.

In this post we want to exercise this challenge using Gitlab CI and Docker.

The build environment

The environment that we run our build is the base layer of all the other operations. The compiler, packaging tools, operating system and all that is installed on it are all examples of what makes that environment. Tools like Docker make it a lot easy to prepare our desired environment as a container. We can put together all the bits and pieces with a Dockerfile, or pick a precooked one (like Node.js 20 on Debian 10) off Docker Hub.

We want to defined our pipeline with Gitlab CI in a way that this container is efficiently created with each check-in and used through the rest of the steps.

Context

To give it a bit of a context, we will write a program in Rust which calls a gRPC API and in the CI pipeline we will build and test it. We are going to start with an empty project and develop it step by step.

You can see the taken steps and resulting pipelines all in Development Container repository. Each commit represents a single step and it's changes. Also take a look at the Pipelines ran during this exercise.

Step 1: Hello, World

First, we create a new project with cargo new grpccaller and we add a small hello world test in main.rs. We add a single stage to run cargo test in our pipeline.

At this point we just want to make sure that our CI server is able to pick up jobs, and we are able to run some unit tests in the pipeline to get feedback on our changes to the code. Keeping the progress in tiny steps helps to catch issues earlier when they are not too complex.

# .gitlab-ci.yml

stages:
  - test

cargo:test:
  stage: test
  image: rust:alpine3.18
  script:
    - cargo test

There is no need to have the Development Container yet. We can use the existing official Rust docker image off the shelf.

Step 2: Add gRPC dependencies

Now we add the dependencies we need for implementing the gRPC client to Cargo.toml then push it so the CI server run tests for us and make sure all is good. But in software development nothing always goes as planned.

# Cargo.toml

[dependencies]
prost = "0.12.1"
tokio = { version = "1.33.0", features = ["macros", "rt-multi-thread"] }
tonic = "0.10.2"

[build-dependencies]
tonic-build = "0.10.2"

Looks like cargo cannot finish the build because of some packages missing from the official Rust docker image.

cannot find crti.o: No such file or directory

Step 3: Install required packages for build

So, as the next step we will easily add some lines to the CI file and fix it.

# .gitlab-ci.yml

stages:
  - test

cargo:test:
  stage: test
  image: rust:alpine3.18
  script:
    - apk add musl-dev
    - apk add protoc
    - cargo test

You may have noticed what we are doing is not the best. Every time the pipeline runs it installs musl-dev and protoc, fetches all the dependencies, and compiles the whole thing from start. It can be a lot more efficient but we rather make it work first then worry about making it right and fast.

Step 4: Call grpcbin SayHello

We want to call the grpcbin hello service to say hello. We will use the instance hosted by k6 at https://grpcbin.test.k6.io/.

We add helloworld.proto, a build.rs, and apply changes to main.rs to make it work.

// main.rs

fn hello_world() -> &'static str {
    "Hello, world"
pub mod hello {
    tonic::include_proto!("hello");
}

fn main() {
    println!("{}", hello_world());
use hello::hello_service_client::HelloServiceClient;
use hello::HelloRequest;

async fn hello_world() -> Result<String, Box<dyn std::error::Error>> {
    let mut client = HelloServiceClient::connect("http://grpcbin.test.k6.io:9000").await?;

    let request = tonic::Request::new(HelloRequest {
        greeting: Some("world".into()),
    });

    let response = client.say_hello(request).await?;

    Ok(response.into_inner().reply)
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    println!("{}", hello_world().await?);

    Ok(())
}

#[cfg(test)]
mod tests {
    use crate::hello_world;

    #[test]
    fn test_hello_world() {
        assert_eq!(hello_world(), "Hello, world");
    #[tokio::test]
    async fn test_hello_world() {
        assert_eq!(hello_world().await.unwrap(), "hello world");
    }
}

Step 5: Cache installed dependencies & compilations

With this setup, cargo has to download all the 3-rd party dependencies and compile them each time we run our pipeline. This is because the runs are isolated and cannot interfere with each other. But unlike code, the dependencies not often change. Therefore, it would be a great win if we could reuse that effort.

We can easily achieve it by utilizing Gitlab CI's cache. The Cargo Book lists the files and directories we can cache to get the most efficient experience while installing dependencies. There is also a build cache (/target directory) which is output of a build and we can safely store it in our CI cache to speed up our compilation time.

There is a limitation with caching in Gitlab CI which is the paths we define to be cached must be within the project directory. It means we cannot save the files in Cargo Home unless we change it's path to somewhere within our project's directory. Thus, we need to set the CARGO_HOME environment variable to something like ${CI_PROJECT_DIR}/.cargo. If you are wondering what ${CI_PROJECT_DIR} is, then you need to take a look at Gitlab CI's predefined variables.

Finally we end up here:

# .gitlab-ci.yml

stages:
  - test

variables:
  CARGO_HOME: ${CI_PROJECT_DIR}/.cargo

cargo:test:
  stage: test
  image: rust:alpine3.18
  cache:
    policy: pull-push
    paths:
      - .cargo/.crates.toml
      - .cargo/.crates2.json
      - .cargo/bin/
      - .cargo/registry/index/
      - .cargo/registry/cache/
      - .cargo/git/db/
      - .cargo/bin
      - target/
    when: on_success
  script:
    - apk add musl-dev
    - apk add protoc
    - cargo test

On the first run after checking in these changes it got longer than 2 minutes for the pipeline to finish. But, the second run took 52 seconds which indicates a build with cache is at least twice faster in this case.

Step 6: Make development container

At this point we have a working feature and we improved caching in our pipeline. But right now, whenever we want to run cargo we have to install OS packages (musl-dev & protoc) first. This is far from ideal since there should be no need to install them each time a job in the pipeline uses cargo. It is not possible to use cache in this case because the installed files are outside project directory and there is no good way to bring them in.

A Development Container can solve this problem for us. Instead of doing our operations in the official rust container, we can make a new image based on it that suits our specific needs.

First thing we need is a Dockerfile. So, we move those two lines out of the test stage and bring them into:

# Development.Dockerfile

FROM rust:alpine3.18

RUN apk add --no-cache musl-dev=1.2.4-r2
RUN apk add --no-cache protoc=3.21.12-r2

More specific package versions are encouraged for more predictable outcomes.

We will build an image from this file and push it to our project's Container Registry at the first stage (prepare) of the pipeline and will use it in the rest of the stages when needed.

You might ask if building a container on every run is wasteful or not? Of course it could be. But, using docker build we can specify external cache sources with --cache-from that makes the process really efficient. Containers' layered architecture makes not just building but also storing them very efficient. You can learn more about how it works here.

We also need to decide on naming and tagging our development containers. Fortunately, Gitlab CI has a variable for the registry image ($CI_REGISTRY_IMAGE) we can use and define new variables:

# .gitlab-ci.yml

---
variables:
  DEVELOPMENT_IMAGE: $CI_REGISTRY_IMAGE/development
  DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG: $DEVELOPMENT_IMAGE:main
  DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG: $DEVELOPMENT_IMAGE:$CI_COMMIT_BRANCH
  DEVELOPMENT_IMAGE_TAG: $DEVELOPMENT_IMAGE:$CI_COMMIT_SHORT_SHA
---

For you to have a better understanding, in my case these can translate into the following:

DEVELOPMENT_IMAGE: registry.gitlab.com/yaghmaie/development-container/development
DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG: registry.gitlab.com/yaghmaie/development-container/development:main
DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG: registry.gitlab.com/yaghmaie/development-container/development:some-other-branch
DEVELOPMENT_IMAGE_TAG: registry.gitlab.com/yaghmaie/development-container/development:7a4f81f0

We want to use DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG and DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG as cache sources to build DEVELOPMENT_IMAGE_TAG and update DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG. We will use DEVELOPMENT_IMAGE_TAG in the rest of the stages of our pipeline.

This is how to build the image the way described:

docker build \
  --cache-from $DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG \
  --cache-from $DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG \
  --build-arg BUILDKIT_INLINE_CACHE=1 \
  --file Development.Dockerfile \
  --tag $DEVELOPMENT_IMAGE_TAG \
  --tag $DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG \

By setting BUILDKIT_INLINE_CACHE build argument, we write cache metadata in the container so it can be used as cache source for later builds.

After the build is done, it is pushed to the container registry:

docker push --all-tags $DEVELOPMENT_IMAGE

The final .gitlab-ci.yml will be:


stages:
  - prepare
  - test

variables:
  CARGO_HOME: ${CI_PROJECT_DIR}/.cargo
  DEVELOPMENT_IMAGE: $CI_REGISTRY_IMAGE/development
  DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG: $DEVELOPMENT_IMAGE:main
  DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG: $DEVELOPMENT_IMAGE:$CI_COMMIT_BRANCH
  DEVELOPMENT_IMAGE_TAG: $DEVELOPMENT_IMAGE:$CI_COMMIT_SHORT_SHA

docker:build:development:
  stage: prepare
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - |
      docker build \
        --cache-from $DEVELOPMENT_IMAGE_MAIN_BRANCH_TAG \
        --cache-from $DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG \
        --build-arg BUILDKIT_INLINE_CACHE=1 \
        --file Development.Dockerfile \
        --tag $DEVELOPMENT_IMAGE_TAG \
        --tag $DEVELOPMENT_IMAGE_CURRENT_BRANCH_TAG \
        .
    - docker push --all-tags $DEVELOPMENT_IMAGE

cargo:test:
  stage: test
  image: $DEVELOPMENT_IMAGE_TAG
  cache:
    policy: pull-push
    paths:
      - .cargo/.crates.toml
      - .cargo/.crates2.json
      - .cargo/bin/
      - .cargo/registry/index/
      - .cargo/registry/cache/
      - .cargo/git/db/
      - .cargo/bin
      - target/
    when: on_success
  script:
    - cargo test

If you want more details about this last change, please go ahead and take a look at it's commit.

Conclusion

Despite all the advancement with development tools, keeping a CI pipeline fast while reliable can be challenging. Working on a CI pipeline without tests and builds is sort of meaningless. So, in this post we started with a "hello, world" rust project and progressed into calling a gRPC API, then making development container for builds and tests in the CI. All the files and related date for this exercise can be found at Development Container repository.

Skip Polkit prompt when authorizing SSH key access with 1Password

Pejman Yaghmaie — Tue, 10 Oct 2023 10:54:18 +0000

If you use 1Password's SSH Agent to manage access to a lot of SSH keys on GNU/Linux, then you probably go through this process multiple times a day:

Connecting to a host via SSH (when using ssh command, or git, etc.):
1Password asking to authorize access:
Polkit prompting to unlock 1Password (System authentication):

Visiting two different dialogs followed by entering a l*************ng password may not be the most fun experience you can get. So, how to make it better?

Skip Polkit prompt by adding a rule

You can add a Polkit authorization rule to unlock 1Password without being asked for authentication. A Polkit rule is basically a JavaScript function that overrules the default settings.

These rules can be found in the following two places:

/usr/share/polkit-1/rules.d: Used by packages to add their rules
/etc/polkit-1/rules.d: Used for local configuration

So, we'll create a new file at /etc/polkit-1/rules.d/00-1password-noauth.rules. Then we add:

polkit.addRule(function (action, subject) {
    if (
        (
            action.id == "com.1password.1Password.unlock" ||
            action.id == "com.1password.1Password.authorizeSshAgent"
        ) &&
        subject.isInGroup("wheel")
    ) {
        return polkit.Result.YES;
    }
});

There is no need to reboot system or restart any service after saving the rule file. Polkit will detect and apply changes immediately.

Here we check if the action's id match the ones defined by 1Password. You can find these ids at /usr/share/polkit-1/actions/com.1password.1Password.policy installed by 1Password for use with system authentication. We also check if the user is in wheel group.

You might ask why we name our rule file 00-1password-noauth.rules and not 1password-noauth.rules? Because the rules are read and processed by Polkit in a certain order and this is how it's determined. Rules with smaller numbers are processed first.

1Password makes it much easier and safer to keep and manage SSH keys. However, with some Linux setups such as mine, you'd have to enter system's password multiple times a day which is very annoying... and meaningless since the vault and the systems is already unlocked!

DEV Community: Pejman Yaghmaie

Reuse tests with multiple implementations of a trait in Rust by rstest

Getting Started

Context

VecFruitStore

Empty VecFruitStore

Refactoring tests

Get ready to add another FruitStore

Adding another FruitStore

Final words

Development container & Gitlab CI - Build better and faster

The build environment

Context

Step 1: Hello, World

Step 2: Add gRPC dependencies

Step 3: Install required packages for build

Step 4: Call grpcbin SayHello

Step 5: Cache installed dependencies & compilations

Step 6: Make development container

Conclusion

Skip Polkit prompt when authorizing SSH key access with 1Password

Skip Polkit prompt by adding a rule

`VecFruitStore`

Empty `VecFruitStore`

Get ready to add another `FruitStore`

Adding another `FruitStore`