{"id":40893656,"url":"https://github.com/bgrewell/dart","last_synced_at":"2026-01-22T02:14:25.555Z","repository":{"id":276857909,"uuid":"815951739","full_name":"bgrewell/dart","owner":"bgrewell","description":"Dynamic Assessment \u0026 Regression Toolkit (DART) is a testing framework for integration testing in bare-metal, docker and lxd container/virtual machine environments. It uses YAML-defined workflows to automate the setup, execution, and teardown of complex tests.","archived":false,"fork":false,"pushed_at":"2025-12-18T14:29:06.000Z","size":20163,"stargazers_count":0,"open_issues_count":5,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-12-20T12:23:23.649Z","etag":null,"topics":["automated-testing","automation","end-to-end","end-to-end-testing","framework","regression","testing"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bgrewell.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-06-16T16:21:17.000Z","updated_at":"2025-12-18T14:10:01.000Z","dependencies_parsed_at":"2025-12-12T04:09:36.548Z","dependency_job_id":null,"html_url":"https://github.com/bgrewell/dart","commit_stats":null,"previous_names":["bgrewell/dart"],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/bgrewell/dart","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgrewell%2Fdart","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgrewell%2Fdart/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgrewell%2Fdart/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgrewell%2Fdart/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bgrewell","download_url":"https://codeload.github.com/bgrewell/dart/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgrewell%2Fdart/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28651050,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-22T01:17:37.254Z","status":"online","status_checked_at":"2026-01-22T02:00:07.137Z","response_time":144,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["automated-testing","automation","end-to-end","end-to-end-testing","framework","regression","testing"],"created_at":"2026-01-22T02:14:24.800Z","updated_at":"2026-01-22T02:14:25.537Z","avatar_url":"https://github.com/bgrewell.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DART - Dynamic Assessment \u0026 Regression Toolkit\n\n\u003e **Notice:** This project is in an early development phase and may not yet be fully stable or feature complete. As it evolves, you may encounter significant changes to the API, behavior, and overall functionality.\n\nDART is a testing framework built to simplify the creation of complex, repeatable test scenarios across a variety of environments. Whether you're validating a single service or coordinating distributed systems, DART empowers you to automate environment setup, execution, and cleanup with minimal effort. Moreover, it integrates effortlessly into existing projects, enabling developers to include test definitions directly within their repositories so that upon cloning, they can immediately verify that all components are functioning as intended.\n\n---\n\n## Table of Contents\n\n1. [Overview](#overview)  \n2. [Key Features](#key-features)  \n3. [Node Types](#node-types)  \n4. [Setup and Teardown Tasks](#setup-and-teardown-tasks)  \n5. [Installation](#installation)  \n6. [Usage](#usage)  \n   - [Command Line Reference](#command-line-reference)  \n   - [Exit Codes](#exit-codes)  \n7. [Example Test Execution](#example-test-execution)  \n8. [Example Test Definition](#example-test-definition)  \n9. [License](#license)  \n\n---\n \n## Overview\n\nDART addresses the challenges of distributed systems testing by structuring workflows into **nodes**, **setup steps**, **tests**, and **teardown steps**. It supports various node types—from local processes and SSH remotes to Docker/LXD containers and virtual machines—while automating the configuration and testing processes. Its declarative YAML configuration allows you to embed test definitions directly within your project, so when you clone a repository, you can instantly run the tests to verify that your local environment is configured correctly.\n\n---\n\n## Key Features\n\n- **Multiple Node Types**  \n  Operates with localhost, remote SSH systems, containers (Docker/LXD), and virtual machines.\n\n- **Automated Environment Preparation**  \n  Provisions and configures nodes automatically, enabling on-demand creation of containers and virtual machines.\n\n- **Declarative YAML Configuration**  \n  Define your test suites in clear, maintainable YAML files that cover node configuration, setup, execution, and teardown.\n\n- **Seamless Integration**  \n  Easily embed test definitions within your existing projects so that a simple clone can yield a fully testable environment.\n\n- **Setup and Teardown Hooks**  \n  Run pre- and post-test operations to maintain a predictable and stable testing state.\n\n- **Human-Readable Output**  \n  Provides clear, color-coded test feedback, making it easy to see results at a glance.\n\n- **DevOps Friendly**  \n  Returns an exit code that reflects the outcome of the tests, integrating smoothly with CI/CD pipelines.\n\n---\n\n## Node Types\n\nDART supports several types of nodes that can be used as test targets:\n\n- **Local Node (`local`)**  \n  Execute tests on the local machine where DART is running.\n\n- **Docker Node (`docker`)**  \n  Run tests inside Docker containers, with support for custom networks and privileged mode. Supports both local and remote Docker hosts.\n\n- **Docker Compose Node (`docker-compose`)**  \n  Manage and test services defined in Docker Compose files. Multiple nodes can target different services in the same compose stack.\n\n- **LXD Node (`lxd`)**  \n  Execute tests in LXD containers or virtual machines, with automatic provisioning and cleanup. Supports both local Unix socket connections and remote HTTPS connections with certificate-based authentication.\n\n- **SSH Node (`ssh`)**  \n  Run tests on remote machines via SSH, supporting both password and key-based authentication.\n\nEach node type can be configured with specific options in your YAML configuration file. For example:\n\n```yaml\nnodes:\n  - name: localhost\n    type: local\n    options:\n      shell: /bin/bash\n  \n  - name: remote-server\n    type: ssh\n    options:\n      host: example.com\n      port: 22\n      user: testuser\n      key: ~/.ssh/id_rsa\n\n  - name: test-container\n    type: docker\n    options:\n      image: ubuntu:latest\n      networks:\n        - name: test-net\n          subnet: \"172.20.0.0/16\"\n          ip: \"172.20.0.2\"\n  \n  # Docker Compose nodes - target specific services\n  - name: web-service\n    type: docker-compose\n    options:\n      compose_file: docker-compose.yml\n      project_name: my-stack\n      service: web\n  \n  - name: db-service\n    type: docker-compose\n    options:\n      compose_file: docker-compose.yml\n      project_name: my-stack\n      service: db\n  \n  # Remote LXD node with certificate authentication\n  - name: remote-lxd\n    type: lxd\n    options:\n      remote_addr: https://10.0.0.1:8443\n      client_cert: ~/.config/lxc/client.crt\n      client_key: ~/.config/lxc/client.key\n      image: ubuntu:24.04\n      instance_type: container\n```\n\n### Remote Docker Support\n\nDocker nodes can connect to remote Docker hosts using standard Docker environment variables:\n\n- **DOCKER_HOST**: URL to the Docker server (e.g., `tcp://remote-host:2376` or `ssh://user@host`)\n- **DOCKER_TLS_VERIFY**: Enable TLS verification (set to `1`)\n- **DOCKER_CERT_PATH**: Path to directory containing TLS certificates (`ca.pem`, `cert.pem`, `key.pem`)\n\nExample:\n```bash\nexport DOCKER_HOST=tcp://10.0.0.1:2376\nexport DOCKER_TLS_VERIFY=1\nexport DOCKER_CERT_PATH=/path/to/certs\ndart -c config.yaml\n```\n\nFor SSH-based connections (no Docker daemon configuration needed):\n```bash\nexport DOCKER_HOST=ssh://user@remote-host\ndart -c config.yaml\n```\n\nSee `examples/docker/docker-remote.yaml` for a complete example.\n\n### Remote LXD Support\n\nLXD nodes support remote connections using modern trust token authentication or traditional certificate-based authentication.\n\n**Trust Token Authentication (Recommended):**\n\nConfigure the remote LXD server and generate a trust token:\n\n```bash\n# On the remote LXD server\nlxc config set core.https_address \"[::]:8443\"\nlxc config trust add dart-client\n# Copy the generated token\n```\n\nUse the token in your DART configuration:\n\n```yaml\nnodes:\n  - name: remote-container\n    type: lxd\n    options:\n      remote_addr: https://10.0.0.1:8443\n      trust_token: eyJjbGllbnRfbmFtZSI6ImRhcnQtY2xpZW50...\n      image: ubuntu:24.04\n      instance_type: container\n```\n\n**Certificate-Based Authentication (Traditional):**\n\nGenerate client certificates:\n```bash\n# Add remote server and generate certificates\nlxc remote add myremote https://remote-server-ip:8443\n```\n\nUse the generated certificates in your DART configuration:\n\n```yaml\nnodes:\n  - name: remote-container\n    type: lxd\n    options:\n      remote_addr: https://10.0.0.1:8443\n      client_cert: ~/.config/lxc/client.crt\n      client_key: ~/.config/lxc/client.key\n      # Optional: server_cert for custom CA\n      # Optional: skip_verify: true (not recommended for production)\n      image: ubuntu:24.04\n      instance_type: container\n```\n\nSee `examples/lxd/lxd-remote.yaml` for a complete example.\n\n### LXD/Incus Auto-Detection\n\nDART automatically detects whether the host system has LXD or Incus installed and configures the appropriate socket path. This allows test configurations to be portable across systems without modification.\n\n**Detection Priority:**\n1. `/var/lib/incus/unix.socket` (Incus)\n2. `/var/snap/lxd/common/lxd/unix.socket` (LXD snap)\n3. `/var/lib/lxd/unix.socket` (LXD native)\n\n**Image Name Translation:**\n\nWhen Incus is detected, DART automatically translates LXD-style image references:\n- `ubuntu:24.04` becomes `images:ubuntu/24.04`\n- `images:debian/12` remains unchanged\n\n**Limitations:**\n\nThis auto-detection provides basic compatibility but has limitations. For production use or complex scenarios, we recommend configuring your test definitions explicitly for your target virtualization platform:\n\n```yaml\n# Explicit socket configuration (recommended for production)\nlxd:\n  socket: /var/lib/incus/unix.socket\n\nnodes:\n  - name: test-container\n    type: lxd\n    options:\n      image: images:ubuntu/24.04  # Use Incus-native format\n      instance_type: container\n```\n\n### LXD Project Support\n\nLXD projects provide resource isolation and organization within LXD. DART supports creating and managing LXD projects, automatically copying the default profile, and organizing instances, networks, and profiles within projects.\n\n**Benefits of Using Projects:**\n- **Resource Isolation**: Separate test environments without conflicts\n- **Organization**: Group related resources together\n- **Easy Cleanup**: Delete all resources by removing the project\n- **Multi-tenancy**: Run multiple test suites in parallel\n\n**Configuring a Project:**\n\n```yaml\nlxd:\n  project:\n    name: dart-test-project\n    description: Test project for integration tests\n    config:\n      features.images: \"true\"\n      features.profiles: \"true\"\n      features.networks: \"true\"\n      features.storage.volumes: \"true\"\n  \n  # Networks are created within the project\n  networks:\n    - name: test-network\n      type: bridge\n      subnet: 10.100.0.0/24\n      gateway: 10.100.0.1\n  \n  # Profiles are created within the project\n  # The default profile is automatically copied\n  profiles:\n    - name: custom-profile\n      description: Custom profile for tests\n      config:\n        limits.cpu: \"2\"\n        limits.memory: \"2GB\"\n\nnodes:\n  - name: test-container\n    type: lxd\n    options:\n      # Will use the project defined in lxd.project\n      image: ubuntu:24.04\n      instance_type: container\n      # Or explicitly specify a project\n      # project: dart-test-project\n```\n\n**Important Notes:**\n- The default profile is automatically copied to new projects\n- All resources (instances, networks, profiles) are automatically cleaned up when the project is deleted\n- Projects are created during setup and deleted during teardown\n\nSee `examples/lxd/lxd-project.yaml` for a complete example.\n\n\n## Setup and Teardown Tasks\n\nSetup and teardown tasks in DART are specialized operations designed to prepare and clean up test environments. Unlike tests, which validate functionality and return pass/fail results, these tasks focus on environment management and are considered successful if they complete without errors.\n\n### Purpose and Execution Flow\n\n1. **Setup Tasks**\n   - Run before any tests begin\n   - Prepare the test environment (e.g., installing dependencies, configuring services)\n   - Must complete successfully for tests to begin\n   - Run in sequence to ensure proper initialization\n\n2. **Teardown Tasks**\n   - Run after all tests complete (or after a critical failure)\n   - Clean up resources and restore system state\n   - Execute even if tests fail (ensuring proper cleanup)\n   - Run in sequence to ensure proper cleanup order\n\n### Key Differences from Tests\n\n- **Success Criteria**: Tasks succeed/fail based on completion, while tests evaluate specific conditions\n- **Evaluation**: Tasks don't have evaluation criteria like `match` or `contains`\n- **Error Handling**: Task failures stop the entire suite, while test failures can be configured to continue\n- **Scope**: Tasks affect the environment, while tests validate functionality\n- **Timing**: Tasks run before/after all tests, while tests run in the middle phase\n\n### Available Task Types\n\n#### Execute Task (`execute`)\nRun shell commands on the target node. Ideal for custom setup operations.\n\n```yaml\n- name: configure database\n  node: db-server\n  step:\n    type: execute\n    options:\n      command: |\n        mysql -u root -e \"CREATE DATABASE testdb;\"\n        mysql -u root -e \"GRANT ALL ON testdb.* TO 'testuser'@'%';\"\n```\n\n#### APT Package Management (`apt`)\nManage system packages on Debian-based systems. Handles updates and dependencies automatically.\n\n```yaml\n- name: install system dependencies\n  node: test-container\n  step:\n    type: apt\n    options:\n      packages:\n        - nginx\n        - postgresql\n        - redis-server\n```\n\n#### Simulated Task (`simulated`)\nAdd controlled delays in the setup/teardown process. Useful for:\n- Waiting for services to initialize\n- Simulating network delays\n- Testing timing-dependent scenarios\n\n```yaml\n- name: wait for service initialization\n  node: app-server\n  step:\n    type: simulated\n    options:\n      time: 5  # Wait for 5 seconds before proceeding\n```\n\n### Best Practices\n\n1. **Environment Isolation**\n   - Use setup tasks to create isolated test environments\n   - Ensure teardown tasks clean up ALL created resources\n   - Avoid leaving behind test artifacts\n\n2. **Idempotency**\n   - Design tasks to be repeatable\n   - Handle cases where resources may already exist\n   - Ensure clean state regardless of previous runs\n\n3. **Error Handling**\n   - Include error checking in setup tasks\n   - Implement proper cleanup in teardown tasks\n   - Log relevant information for debugging\n\n4. **Resource Management**\n   ```yaml\n   setup:\n     - name: create test directory\n       node: test-server\n       step:\n         type: execute\n         options:\n           command: \"mkdir -p /tmp/test-data\"\n   \n   teardown:\n     - name: cleanup test directory\n       node: test-server\n       step:\n         type: execute\n         options:\n           command: \"rm -rf /tmp/test-data\"\n   ```\n\n### Planned Future Task Types\n\nDART is actively developing additional task types to enhance environment management:\n\n- **SNAP Package Management**\n  - Install/remove snap packages\n  - Configure snap services\n\n- **Git Operations**\n  - Clone repositories\n  - Checkout specific branches/tags\n  - Apply patches\n\n- **File System Operations**\n  - Create/modify configuration files\n  - Set up directory structures\n  - Manage permissions\n\n- **Network Configuration**\n  - Configure network interfaces\n  - Set up routing rules\n  - Manage firewall settings\n\n- **Service Management**\n  - Start/stop system services\n  - Configure service parameters\n  - Manage service dependencies\n\n---\n\n## Installation\n\nInstallation methods vary depending on your environment. Generally, you can:\n\n- Clone the DART repository.\n- Build from source or install via any officially supported package distribution.\n\n*(Please refer to the official documentation for detailed installation instructions.)*\n\n---\n\n## Usage\n\n### Command Line Reference\n\n```bash\nUsage: dart [OPTIONS] [ARGUMENTS]\n\nVersion: dev\nDate: dev\nCodebase: dev (dev)\n\nDescription: DART is a distributed systems testing framework\n  designed to make it easy to perform automation and\n  integration testing on a wide variety of distributed\n  systems.\n\nOptions:\n  Default: Default Options\n    -c        --config          config.yaml  The path to the configuration file\n    -v        --verbose         false        Enable verbose output\n    -p        --pause-on-error  false        Pause on error\n    -s        --stop-on-error   false        Stop on error\n    -setup    --setup-only      false        Only run the setup steps\n    -teardown --teardown-only   false        Only run the teardown steps\n```\n\n### Exit Codes\n\n- **0**: All tests passed successfully.\n- **Non-zero**: One or more tests failed or an unexpected error occurred.\n\nThese exit codes allow DART to integrate with automated DevOps workflows, ensuring that issues are immediately flagged during continuous integration and deployment processes.\n\n---\n\n## Example Test Execution\n\nBelow is a simplified example of how DART logs its operations during a test run. The actual output includes color coding and more detailed formatting for clarity:\n\n```bash\n[+] Running test setup\n  running setup ...................... done \n  running setup ...................... done \n  ensure sshpass is installed ........ done \n  ensure dns is working .............. done \n  install locker ..................... done \n  create user bob .................... done \n  create user jim .................... done \n  create user tom .................... done \n  ensure password login is allowed ... done \n  restart ssh ........................ done \n\n[+] Running tests\n  00001: verify locker is installed .................. passed\n  00002: ssh to locker-test as bob ................... passed\n  00003: ssh to locker-test as jim ................... passed\n  00004: lock system as jim .......................... passed\n  00005: ssh to locker-test as disallowed user bob ... passed\n  00006: ssh to locker-test as allowed user tom ...... passed\n  00007: unlock system as jim ........................ passed\n  00008: verify bob can again access the system ...... passed\n\n[+] Running test teardown\n  running teardown ................... done \n  running teardown ................... done \n\n[+] Results\n  Pass: 00008\n  Fail: 00000\n```\n\n---\n\n## Example Test Definition\n\nThe YAML configuration below demonstrates how to define nodes, setup steps, tests, and teardown operations. This example provisions and tests a tool called `locker` in an LXD container:\n\n```yaml\n---\nsuite: Locker End-to-End Tests\nnodes:\n  - name: localhost\n    type: local\n    options:\n      shell: /bin/bash\n  - name: locker-test\n    type: lxd\n    options:\n      image: ubuntu:24.04\n      type: container\n\nsetup:\n  - name: ensure sshpass is installed\n    node: localhost\n    step:\n      type: apt\n      options:\n        packages:\n          - sshpass\n\n  - name: ensure dns is working\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: 'until nslookup github.com \u0026\u003e/dev/null; do sleep 1; done'\n\n  - name: install locker\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"bash -o pipefail -c 'curl -fSL https://bgrewell.github.io/locker/install.sh | bash'\"\n\n  - name: create user bob\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"useradd -m -s /bin/bash bob \u0026\u0026 echo 'bob:password123' | chpasswd\"\n\n  - name: create user jim\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"useradd -m -s /bin/bash jim \u0026\u0026 echo 'jim:password123' | chpasswd\"\n\n  - name: create user tom\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"useradd -m -s /bin/bash tom \u0026\u0026 echo 'tom:password123' | chpasswd\"\n\n  - name: ensure password login is allowed\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"rm /etc/ssh/sshd_config.d/60-cloudimg-settings.conf\"\n\n  - name: restart ssh\n    node: locker-test\n    step:\n      type: execute\n      options:\n        command: \"systemctl restart ssh\"\n\ntests:\n  - name: verify locker is installed\n    node: locker-test\n    type: execute\n    options:\n      command: \"locker -h\"\n      evaluate:\n        exit_code: 0\n\n  - name: test\n    node: localhost\n    type: execute\n    options:\n      command: \"whoami\"\n      evaluate:\n        match: \"ben\"\n\n  - name: ssh to locker-test as bob\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no bob@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') whoami\"\n      evaluate:\n        match: \"bob\"\n        exit_code: 0\n\n  - name: ssh to locker-test as jim\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no jim@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') whoami\"\n      evaluate:\n        match: \"jim\"\n        exit_code: 0\n\n  - name: lock system as jim\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no jim@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') locker -r test -u tom lock\"\n      evaluate:\n        contains: \"Lock acquired\"\n        exit_code: 0\n\n  - name: ssh to locker-test as disallowed user bob\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no bob@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') echo test\"\n      evaluate:\n        exit_code: 255\n\n  - name: ssh to locker-test as allowed user tom\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no tom@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') echo test\"\n      evaluate:\n        match: test\n        exit_code: 0\n\n  - name: unlock system as jim\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no jim@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') unlock\"\n      evaluate:\n        contains: \"Lock released\"\n        exit_code: 0\n\n  - name: verify bob can again access the system\n    node: localhost\n    type: execute\n    options:\n      command: \"sshpass -p 'password123' ssh -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=yes -o PubkeyAuthentication=no bob@$(lxc list --project default locker-test --format csv -c4 | awk '{print $1}') echo test\"\n      evaluate:\n        match: test\n        exit_code: 0\n```\n\n---\n\n## License\n\nThis project is distributed under an open-source or commercial license, as specified in the repository's [LICENSE](LICENSE) file.\n\n---\n\n*Thank you for exploring DART! Your contributions and feedback are welcome as we strive to make testing in distributed environments as seamless as possible.*\n\n---\n\nOld todo list that needs to be migrated and cleaned up\n\n## Task Types\n\n- [ ] APT Package Management\n- [ ] SNAP Package Management\n- [ ] git clone\n- [ ] command execution\n\n## Next Tasks\n- [ ] Flags\n  - [ ] Verbose\n  - [ ] Pause on fail\n  - [ ] Stop on fail\n  - [ ] Setup only\n  - [ ] Teardown only\n  - [ ] Skip teardown\n  - [ ] Skip setup\n- [ ] Support multiple nodes for tests\n- [ ] More details on setup/docker steps when verbose is enabled\n  \n[x] - Summary of the test results\n- Verbose output\n- Failed test details\n- General cleanup of formatter and controller\n- Ability to load a series of tests from recursive folders of yaml files\n- Ability to do something like monitor cpu usage over the test then evaluate at the end of the test what the avg cpu usage was\n## Requirements\n\n1. Execute test command/script and get results\n2. Run results against a test function\n3. Setup command(s) to prepare the system(s) for the test\n4. Teardown command(s) to clean up the system(s) after the test\n5. Load all tests from a directory\n6. AI test evaluator\n\n\n### Types of tests\n\n- [x] Command Execution\n- [ ] File Read\n- [ ] File Write\n- [ ] File Exist\n- [ ] TCP Socket\n- [ ] UDP Socket\n- [ ] ICMP Socket\n- [ ] Unix Socket\n- [ ] HTTP Request\n- [ ] HTTPS Request\n- [ ] gRPC Request\n- [ ] DNS Request\n- [ ] (Plugins)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbgrewell%2Fdart","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbgrewell%2Fdart","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbgrewell%2Fdart/lists"}