aherman
/
boundary
mirror of https://github.com/hashicorp/boundary
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '321953093b'
${ noResults }
boundary/internal/tests/cli
History
Andrew Gaffney d24ad6c2e2
feat(cli): Support RDP target 		6 months ago
..
boundary feat(cli): Support RDP target 6 months ago
Makefile feat(cli): Add vault ssh certificate credential library 3 years ago
README.md chore(cli): Run bats tests against boundary dev in CI 3 years ago
test.sh [COMPLIANCE] License changes (#3567) 3 years ago

README.md

Boundary CLI Tests

This directory contains bats tests for testing the Boundary CLI against arbitrary Boundary deployments. The tests are meant to mimic common workflows such as creating resources, and connecting to targets. Currently, the tests rely heavily on generated resources when running Boundary in dev mode. In the future, we hope to remove this dependency and generate all resources through the Boundary CLI from the outset.

The tests are designed to be idempotent.

Getting Started

Dependencies

Running Tests

  1. Start boundary in dev mode
boundary dev

or direct the tests towards an existing install by setting

export BOUNDARY_ADDR=<your_install>
  1. Run the tests
# for an untagged non-version of boundary
bats -p boundary/

# for an official boundary version
IS_VERSION=true bats -p boundary/

Running Tests Against Other Deployments

You can run this suite against an arbitrary cluster by overriding the following env vars:

DEFAULT_LOGIN=<my_login> \
DEFAULT_PASSWORD=<my_password> \
BOUNDARY_ADDR=http://boundary-test-controller-salmon-b70f2710539143b4.elb.us-east-1.amazonaws.com:9200 \
bats boundary/

~> Note that these tests currently expect generated resources to exist. Failure to run against a Boundary deployment that does not have generated resources will result in a lot of test failures. Future work includes breaking thses tests out in a way that makes them not dependent on generated resources.