Jeffrey Phillips Freeman
f7d2f63ab8
CI / lint (pull_request) Successful in 15s
CI / typecheck (pull_request) Successful in 28s
CI / security (pull_request) Successful in 23s
CI / quality (pull_request) Successful in 15s
CI / integration_tests (pull_request) Successful in 5m11s
CI / build (pull_request) Successful in 16s
CI / unit_tests (pull_request) Successful in 14m31s
CI / docker (pull_request) Successful in 40s
CI / coverage (pull_request) Successful in 8m18s
CI / lint (push) Successful in 13s
CI / typecheck (push) Successful in 28s
CI / security (push) Successful in 23s
CI / quality (push) Successful in 16s
CI / integration_tests (push) Successful in 4m58s
CI / build (push) Successful in 15s
CI / unit_tests (push) Successful in 15m30s
CI / coverage (push) Has been cancelled
CI / docker (push) Has been cancelled
180 lines
8.8 KiB
Gherkin
180 lines
8.8 KiB
Gherkin
Feature: Resource registry and project services
|
|
As a developer
|
|
I want resource registry and project services
|
|
So that I can manage resource types, resources, and project-resource links
|
|
|
|
Background:
|
|
Given a resource service in-memory database is initialized
|
|
|
|
# ---------- Resource Type Bootstrap ----------
|
|
|
|
Scenario: Bootstrap registers built-in types idempotently
|
|
When I bootstrap built-in resource types
|
|
Then the bootstrap should register "git-checkout"
|
|
And the bootstrap should register "fs-directory"
|
|
When I bootstrap built-in resource types again
|
|
Then the second bootstrap should register 0 new types
|
|
|
|
Scenario: List built-in types after bootstrap
|
|
Given built-in resource types are bootstrapped
|
|
When I list all resource types via the service
|
|
Then the type list should contain at least 2 types
|
|
And the type list should include "git-checkout"
|
|
And the type list should include "fs-directory"
|
|
|
|
Scenario: Show a built-in type by name
|
|
Given built-in resource types are bootstrapped
|
|
When I show the resource type "git-checkout" via the service
|
|
Then the shown type name should be "git-checkout"
|
|
And the shown type resource kind should be "physical"
|
|
And the shown type sandbox strategy should be "git_worktree"
|
|
|
|
Scenario: Show a non-existent type raises ResourceNotFoundError
|
|
Given built-in resource types are bootstrapped
|
|
When I show the resource type "no-such-type" via the service expecting an error
|
|
Then the service error should be "ResourceNotFoundError"
|
|
|
|
# ---------- Custom Resource Type Registration ----------
|
|
|
|
Scenario: Register a custom resource type from YAML
|
|
Given a custom resource type YAML file for "myorg/custom-db"
|
|
When I register the custom resource type via the service
|
|
Then the registered type name should be "myorg/custom-db"
|
|
|
|
Scenario: Register a duplicate type raises ValidationError
|
|
Given a custom resource type YAML file for "myorg/dup-type"
|
|
And I register the custom resource type via the service
|
|
When I register the same custom type again expecting an error
|
|
Then the service error should be "ValidationError"
|
|
|
|
Scenario: Register type from non-existent path raises ValidationError
|
|
When I register a type from path "/nonexistent/path.yaml" expecting an error
|
|
Then the service error should be "ValidationError"
|
|
|
|
# ---------- Resource Registration ----------
|
|
|
|
Scenario: Register a resource of a built-in type
|
|
Given built-in resource types are bootstrapped
|
|
When I register a resource of type "git-checkout" named "local/my-repo" with location "/tmp/repo"
|
|
Then the registered resource name should be "local/my-repo"
|
|
And the registered resource type should be "git-checkout"
|
|
And the registered resource classification should be "physical"
|
|
|
|
Scenario: Register a resource with non-existent type raises ResourceNotFoundError
|
|
When I register a resource of type "no-type" named "local/bad" expecting an error
|
|
Then the service error should be "ResourceNotFoundError"
|
|
|
|
Scenario: List resources returns all registered resources
|
|
Given built-in resource types are bootstrapped
|
|
And a resource of type "git-checkout" named "local/repo-a" is registered
|
|
And a resource of type "git-checkout" named "local/repo-b" is registered
|
|
When I list all resources via the service
|
|
Then the resource list should contain 2 resources
|
|
|
|
Scenario: List resources filtered by type
|
|
Given built-in resource types are bootstrapped
|
|
And a resource of type "git-checkout" named "local/repo-c" is registered
|
|
And a resource of type "fs-directory" named "local/dir-a" is registered
|
|
When I list resources of type "git-checkout" via the service
|
|
Then the resource list should contain 1 resources
|
|
|
|
Scenario: Show a resource by name
|
|
Given built-in resource types are bootstrapped
|
|
And a resource of type "git-checkout" named "local/show-repo" is registered
|
|
When I show the resource "local/show-repo" via the service
|
|
Then the shown resource name should be "local/show-repo"
|
|
|
|
Scenario: Show a resource by ULID
|
|
Given built-in resource types are bootstrapped
|
|
And a resource of type "git-checkout" named "local/ulid-repo" is registered
|
|
When I show the resource by its ULID via the service
|
|
Then the shown resource name should be "local/ulid-repo"
|
|
|
|
Scenario: Show a non-existent resource raises ResourceNotFoundError
|
|
When I show the resource "no-such-resource" via the service expecting an error
|
|
Then the service error should be "ResourceNotFoundError"
|
|
|
|
# ---------- Project Service Reworked ----------
|
|
|
|
Scenario: Create a namespaced project via service
|
|
When I create a namespaced project "local/svc-project" via the project service
|
|
Then the service project "local/svc-project" should exist
|
|
|
|
Scenario: Create a duplicate project raises error
|
|
Given a namespaced project "local/dup-project" exists via the service
|
|
When I create a namespaced project "local/dup-project" via the project service expecting an error
|
|
Then the project service error should be a database error
|
|
|
|
Scenario: List projects via service
|
|
Given a namespaced project "local/list-a" exists via the service
|
|
And a namespaced project "local/list-b" exists via the service
|
|
When I list all projects via the project service
|
|
Then the project service list should contain 2 projects
|
|
|
|
Scenario: Get project by namespaced name via service
|
|
Given a namespaced project "local/get-svc" exists via the service
|
|
When I get the project "local/get-svc" via the project service
|
|
Then the project service returned name should be "get-svc"
|
|
|
|
Scenario: Delete project via service
|
|
Given a namespaced project "local/del-svc" exists via the service
|
|
When I delete the project "local/del-svc" via the project service
|
|
Then the project "local/del-svc" should not exist via the service
|
|
|
|
Scenario: Link a resource to a project via service
|
|
Given built-in resource types are bootstrapped
|
|
And a namespaced project "local/link-project" exists via the service
|
|
And a resource of type "git-checkout" named "local/link-repo" is registered
|
|
When I link the resource "local/link-repo" to project "local/link-project" via the service
|
|
Then the project "local/link-project" should have 1 linked resource
|
|
|
|
Scenario: Unlink a resource from a project via service
|
|
Given built-in resource types are bootstrapped
|
|
And a namespaced project "local/unlink-project" exists via the service
|
|
And a resource of type "git-checkout" named "local/unlink-repo" is registered
|
|
And the resource "local/unlink-repo" is linked to project "local/unlink-project"
|
|
When I unlink the resource from project "local/unlink-project" via the service
|
|
Then the project "local/unlink-project" should have 0 linked resources
|
|
|
|
Scenario: List linked resources for a project
|
|
Given built-in resource types are bootstrapped
|
|
And a namespaced project "local/links-project" exists via the service
|
|
And a resource of type "git-checkout" named "local/links-repo-a" is registered
|
|
And a resource of type "fs-directory" named "local/links-dir-a" is registered
|
|
And the resource "local/links-repo-a" is linked to project "local/links-project"
|
|
And the resource "local/links-dir-a" is linked to project "local/links-project"
|
|
When I list linked resources for project "local/links-project" via the service
|
|
Then the linked resources list should contain 2 items
|
|
|
|
# ---------- Additional Coverage Scenarios ----------
|
|
|
|
Scenario: List types filtered by namespace
|
|
Given built-in resource types are bootstrapped
|
|
When I list resource types with namespace "builtin" via the service
|
|
Then the type list should contain at least 2 types
|
|
|
|
Scenario: Register a resource with properties
|
|
Given built-in resource types are bootstrapped
|
|
When I register a resource of type "git-checkout" named "local/props-repo" with location "/tmp/r" and properties
|
|
Then the registered resource name should be "local/props-repo"
|
|
|
|
Scenario: Register a resource with no namespace in name
|
|
Given built-in resource types are bootstrapped
|
|
When I register a resource of type "git-checkout" named "bare-name" with location "/tmp/b"
|
|
Then the registered resource name should be "bare-name"
|
|
|
|
Scenario: Register a resource with no name
|
|
Given built-in resource types are bootstrapped
|
|
When I register a resource of type "git-checkout" with no name but location "/tmp/nn"
|
|
Then the registered resource should have a ULID id
|
|
|
|
# ---------- DI Container Wiring ----------
|
|
|
|
Scenario: DI container provides resource registry service
|
|
When I get the resource registry service from the DI container
|
|
Then the resource registry service should not be None
|
|
|
|
Scenario: DI container provides reworked project service
|
|
When I get the namespaced project service from the DI container
|
|
Then the namespaced project service should not be None
|