Early load config when integrating tbot into pytest about tbot

[Rahix]

Hey, thanks, this is a very good idea! I think what you're proposing makes a lot of sense. Can you send a PR with a change to the docs and also selftest/conftest.py for it? :)

I have one comment about the example you make:

import pytest
import tbot

def _interfaces():
    with tbot.ctx.request(tbot.role.Board) as b:
        return b.interfaces

@pytest.mark.parametrize("interface", _interfaces())
def test_interface(interface):
    print(interface)

I don't think you should do a request() here for collecting the available interfaces. This will try initializing the board, so potentially power it on only to power it off immediately after. A better way would be to do this:

def _interfaces():
    board_cls = tbot.ctx.get_machine_class(tbot.role.Board)
    return board_cls.interfaces

This will not attempt interacting with a real board instance and just retrive the "cold" data from the class definition.

[mebel-christ]

I am working on the PR. Additionally I did some further testing:

I have one comment about the example you make:

import pytest
import tbot

def _interfaces():
    with tbot.ctx.request(tbot.role.Board) as b:
        return b.interfaces

@pytest.mark.parametrize("interface", _interfaces())
def test_interface(interface):
    print(interface)

I don't think you should do a request() here for collecting the available interfaces. This will try initializing the board, so potentially power it on only to power it off immediately after.

This is a great hint I missed that since I am working on my local machine with the dummy setup and not the real lab.

A better way would be to do this:

def _interfaces():
    board_cls = tbot.ctx.get_machine_class(tbot.role.Board)
    return board_cls.interfaces

This will not attempt interacting with a real board instance and just retrive the "cold" data from the class definition

Your proposed improvement works perfectly well, but it has a slight drawback. I can no longer use/implement the interfaces in the board with @property since properties belong to an instance and not the class itself. But TBH since this is static information anyway I do not really care. So I went with the following instead, but this is rather off-topic:

from typing import Dict, Set

from tbot import role
from tbot.machine import board, connector

class DummyBoard(connector.SubprocessConnector, board.Board):
   
    interfaces: Dict[str, Set[str]] = {
        "interface": {"interface0", "interface1"},
    }

More importantly I moved the config load step for tbot to an even earlier point in time, namely the pytest_configure hook.
This was done to make use of pytest-metadata (+ pytest-html) to read and print metadata from a Board, but the more important point IMO is what the pytest-doc has to say about the hook:

pytest_configure(config)

Allow plugins and conftest files to perform initial configuration.
This hook is called for every plugin and initial conftest file after command line options have been parsed.
After that, the hook is called for other conftest files as they are imported.

To me this sounds like the even more appropriate (and portable?) location (than pytest_sessionstart) for loading a configuration file. @Rahix What do you think?

[Rahix]

Agreed, pytest_configure() sounds better! 👍

[mebel-christ]

@Rahix I forked and added the documentation for this. TBH I am uncertain what to do about selftest/conftest.py now.
I looked at it and as far as I understand the configuration for the testmachines is not loaded in any related way or am I misunderstanding something here?

[Rahix]

Ah, you are right, the selftests do things a bit differently. In that case, ignore what I said, sorry!

[mebel-christ]

Great, in that case I am going to open the PR