# Testing workflow

During blockchain application development, a "local" blockchain (generally consisting of a single node) is used to simulate deployment and interaction with smart contracts. When developing an application that leverages NEBRA UPA, a few extra components are required in order to test the end-to-end workflow in this simulation environment:

* UPA contracts must be deployed to the target chain, AND
* An aggregator must monitor the chain and supply aggregated proofs

The `upa` tool can be used to run a "development" aggregator, which aggregates all submitted proofs, and the UPA contracts can be deployed in a specific configuration which accepts these aggreagtions.

In this way, the complete UPA pipeline is available on the local development chain, and applications can be fully tested.

> **NOTE**: In contrast to the production deployments, the development aggregator accepts and aggregates invalid proofs.  Submission of invalid proofs should be tested against a NEBRA UPA testnet deployment.

## Unit testing using the `dev-aggregator`

## Launch a development node

For example, in a separate terminal, run:

```console
yarn hardhat node
```

> **NOTE**: Unless otherwise specified, the `upa` command will attempt to connect to an RPC node at `http://localhost:8545`. If your development node listens on a different port, use the `--rpc-endpoint` option, or the `RPC_ENDPOINT` env variable (see ./setup.md) to specify the correct endpoint.

### Create a deployer account

In order to deploy the UPA contracts and submit aggregated proofs, a keyfile for a funded account is required. A suitable keyfile can be created using the `upa` tool.

> **NOTE**: This keyfile should only be used on development networks, not on live networks holding tokens of real value.

```console
upa dev ethkeygen --keyfile upa-dev.keyfile
```

The keyfile can be recorded in a .env file for convenience:

```console
echo KEYFILE=upa-dev.keyfile >> .env
echo KEYFILE_PASSWORD= >> .env
```

(Otherwise, it must be specified in subsequent commands)

> **NOTE**: For development chains, the `upa dev fund` command can be used to fund the keyfile from a hosted account.  (See `upa dev fund --help`)

### Deploy a development version of UPA

```console
upa owner deploy \
    --verifier "node_modules/@nebrazkp/upa/test/data/test.bin" \
    --use-test-config
```

This creates a `upa.instance` file in the current directory.

> **NOTE**: The development version of the UPA contracts behave exactly the same as the production versions, except that they accept fake aggregation proofs. All other checks are performed identically. This allows any issues to be caught during local testing.
>
> **NOTE:** The command above deploys a upa contract with a default test config. This can be customized by providing a `upa_config.json` file, and replacing the flag `--use-test-config` with `--config upa_config.json`

### Launch a *development aggregator*

```console
upa dev aggregator
```

> **NOTE**: By default `dev-aggregator` checks for a `upa.instance` file in the current directory. Therefore, if run from the same directory as deployment above, the instance file does not need to be specified. (See `--help` for how to specify the instance file).

### Execute tests

Application tests can then be run against the local node, using `upa.instance` to initialize a `UpaClient`.

For example, if unit tests are written to always initialize a `UpaClient` from a `upa.instance`, they can be executed, pointing at the local node:

```console
yarn hardhat test --network localhost
```

Similarly any CLI or browser client code can now be exercised against the local node.