Test Suite for Blueprints

Feature Requests
1

I am a software developer and just started using homeassistant. (I had used a selfmade solution before, that integrated with homekit, but now wanted to get rid of homekit as a automation hub and get all sensors in a central place, thus switched to Home Assistant).

I am writing some blueprints right now that should do quite some complex tasks (e.g. Automation of my light scenes based on presence, ambient light levels, state of other lights, time of day, events in the calendar, etc.).

From developing software, I am used to write the interface first, then write tests for the interface and then develop the core functionality until the tests are successful. I am missing that kind of functionality in Home Assistant.

What I would love to see is a e.g. commandline tool, that I can provide my blueprint, then feed some simulated sensors into its inputs and then run the test bench (which might e.g. be written using jest or whatever is the python equivalent).

One example would be:


describe("my-blueprint.yml", (blueprint) => {
  it('triggers away scene if presence just changed to away', () => {
    // given
    const presence = new BinarySensor()
    const awayScene = new Scene('away')
    presence.set('on')

    // UUT
    blueprint.inputs({
      presence_sensor: presence,
      scene_away: awayScene
    })

    // when
    presence.set('off')

    // then
    expect(awayScene).toBeTriggered()

    // Or something like:
    expect(blueprint).toHaveTriggered({service: 'scene.turn_on', entity_id: 'scene.away'})
  }
})

is there already such a project or feature?

Would be awesome to have something like this. It might also provide syntax errors in the blueprints if something is wrong.

Alternatively it could be built into the blueprints itself, so that they have a “test” key wit the test suites and when you load a blueprint it runs the tests first to see if it is doing what it is supposed to. e.g.:

blueprint:
  name: My Cool Blueprint
  author: Tobisk
  domain: automation

  inputs:
    - name: my_input
      ...

variables: ...
triggers: ...
conditions: ...
actions: ...

tests:
  - name: My Test
    input:
      my_input: ...
    given:
      device1:
        state: on
      ...
    when:
      device1:
        state: off
    then:
      - action_contains:
          - action: scene.turn_on
            entity_id: scene.my_scene
            data: ...
2

This is why you write the automation or the script first, get that working, and add the conversion to a blueprint as the docs recommend.
The only tool to help with writing automations or scripts is the ui editor, and there is nothing to help with BP conversion.
Get what you want working, then make the blueprint out of that by adding the !inputs and variables and such.

There are generally 2 reasons to make a blueprint.

  1. because you want to do the same thing multiple times, like my script blueprint to talk to my broadlink and program buttons to turn on and off my AV equipment. I have re-used that script blueprint about a dozen times in my config.
  2. You are doing something you think is cool and you want to share it with others.

If you are doing something only once, the blueprint only complicates things for you.

3

Well, that’s why I opened a Feature Request.

I cannot really test some of the automations except for either creating a bunch of dummy devices or actually running around my home. That’s why I prefer a proper test suite.

1 Like