ansible/hetzner.hcloud
1
0
Fork 0
mirror of https://github.com/ansible-collections/hetzner.hcloud.git synced 2026-02-04 16:11:49 +00:00
Code Activity
hetzner.hcloud/tests/integration
History
Exact
Jonas L. 826e6a5309
feat: per location server types (#692) 
[Server Types](https://docs.hetzner.cloud/reference/cloud#server-types)
now depend on
[Locations](https://docs.hetzner.cloud/reference/cloud#locations).

- We added a new `locations` property to the [Server
Types](https://docs.hetzner.cloud/reference/cloud#server-types)
resource. The new property defines a list of supported
[Locations](https://docs.hetzner.cloud/reference/cloud#locations) and
additional per
[Locations](https://docs.hetzner.cloud/reference/cloud#locations)
details such as deprecations information.

- We deprecated the `deprecation` property from the [Server
Types](https://docs.hetzner.cloud/reference/cloud#server-types)
resource. The property will gradually be phased out as per
[Locations](https://docs.hetzner.cloud/reference/cloud#locations)
deprecations are being announced. Please use the new per
[Locations](https://docs.hetzner.cloud/reference/cloud#locations)
deprecation information instead.

See our
[changelog](https://docs.hetzner.cloud/changelog#2025-09-24-per-location-server-types)
for more details.

**Upgrading**

```yaml
---
- name: Validate server type
  hosts: localhost
  connection: local
  tasks:
    - name: Fetch server type info
      hetzner.hcloud.server_type_info:
        name: cx22
      register: server_type

    - name: Ensure server type exists
      ansible.builtin.assert:
        fail_msg: server type does not exists
        that:
          - server_type.hcloud_server_type_info | count == 1

    - name: Ensure server type is not deprecated
      ansible.builtin.assert:
        fail_msg: server type is deprecated
        that:
          - server_type.hcloud_server_type_info[0].deprecation is none
```

```yaml
---
- name: Validate server type
  hosts: localhost
  connection: local
  tasks:
    - name: Fetch location info
      hetzner.hcloud.location_info:
        name: fsn1
      register: location

    - name: Fetch server type info
      hetzner.hcloud.server_type_info:
        name: cx22
      register: server_type

    - name: Ensure server type exists
      ansible.builtin.assert:
        fail_msg: server type does not exists
        that:
          - server_type.hcloud_server_type_info | count == 1

    - name: Extract server type location info
      ansible.builtin.set_fact:
        server_type_location: >
          {{
            server_type.hcloud_server_type_info[0].locations
            | selectattr("name", "eq", location.hcloud_location_info[0].name)
            | first
          }}

    - name: Ensure server type is not deprecated
      ansible.builtin.assert:
        fail_msg: server type is deprecated in location
        that:
          - server_type_location.deprecation is none
```
2025-09-26 11:50:05 +02:00
..
common test: use shared network zone variable (#543) 2024-08-06 12:50:58 +02:00
targets feat: per location server types (#692) 2025-09-26 11:50:05 +02:00
cloud-config-hcloud.ini.in chore: add dev target helper (#457) 2024-02-06 14:04:18 +01:00
README.md test: improve *_info modules tests (#299) 2023-08-17 09:44:33 +02:00
requirements.txt test: improve tests using setup_selfsigned_certificate (#286) 2023-08-04 09:01:50 +02:00

README.md

Integration tests

This document provides information to work with the integration tests.

Guidelines

A set of guidelines to follow when writing integrations tests.

Prepare and cleanup

The integration tests use a small testing framework that helps to set up and teardown any resources needed or generated by the tests. This small testing framework is located in the tests/integration/common directory. The files within the common directory are then duplicated and kept in sync in all the integration tests targets (tests/integration/targets/hcloud_*).

  • Use a tasks/prepare.yml file to set up resources needed during the tests.
  • Use a tasks/cleanup.yml file to teardown resources from the tasts/prepare.yml tasks and the resources generated by the tests.
  • Use a tasks/test.yml file to defines your tests.
  • You may explode the tests into multiple tasks/test-*.yml files and import them in the tasks/test.yml file.
  • The tasks/cleanup.yml file cannot use variables present in the tasks/prepare.yml file because cleanup should also run before the prepare tasks.

Naming convention

The integration tests handle a lot of different variables, names, identifier. To reduce this complexity, make sure to use the following naming conventions:

  • Any test resources MUST be registered using the test_<resource> variable name (e.g. test_server or test_floating_ip) and MUST be created and cleaned in the tasks/prepare.yml and tasks/cleanup.yml. The scope of this variable is the entire target.
  • In tasks/prepare.yml, tasks names MUST start with: Create test_<resource> (e.g. Create test_server or Create test_floating_ip)
  • In tasks/cleanup.yml, tasks names MUST start with: Cleanup test_<resource> (e.g. Cleanup test_server or Cleanup test_floating_ip)
  • Any fact starting with _ is scoped to the current file and MUST NOT be used outside of it.
  • Any test result MUST be registered using the result variable name unless it is required in a future test, in that case it MUST use the <resource> variable name as prefix.