Запустите часть модульных тестов Python на удаленной машине Linux с хоста Windows.

Моя ситуация выглядит следующим образом:

  • У меня есть серверная программа на базе Windows и клиент на базе Linux.
  • У меня есть много тестов для клиентов Linux, которые запускаются и необходимы для запуска на локальных машинах Linux.
  • Мне нужно запустить некоторый код с сервера Windows, который будет отправлять сообщения клиентам Linux. Затем на клиентских машинах Linux должен быть выполнен тест, который проверяет действие этих сообщений.

Таким образом, типичный тестовый пример будет выглядеть так, работая на хосте Windows:

test_example_message(self):
    # has to be executed locally on windows server
    send_message(EXAMPLE, hosts)
    # has to be executed locally on linux clients
    for host in hosts:
        verify_message_effect(EXAMPLE, host)

Я обнаружил, что pytest-xdist каким-то образом может это сделать.

У меня есть хороший учебник или пример кода о том, как его использовать?


person vladosaurus    schedule 19.08.2015    source источник
comment
некоторые ресурсы, которые я уже нашел: xdist & django ;;; введение в py.test   -  person vladosaurus    schedule 20.08.2015
comment
другой (на чешском языке): [horejsek.blog] (blog.horejsek .com/co-se-mi-libi-na-pytestu)   -  person vladosaurus    schedule 20.08.2015
comment
это кажется довольно неприятным! Я лично считаю, что вы должны издеваться над связью между хостами в своих юнит-тестах, но если вы действительно хотите это сделать, вы также можете просто выполнить свой скрипт проверки на своем Linux-боксе, используя ssh <user_with_ssh_key>@<remotehost> python execute_verification.py, затем захватить вывод этого с помощью check_output и проверить возвращаемое значение. на вашем хосте Windows.   -  person flazzarini    schedule 21.08.2015
comment
@flazzarini да, я наконец решил написать свой собственный «стек», используя ssh, выполняемый в нескольких потоках/процессах. (распараллеливание имеет решающее значение в моем случае). после некоторых исследований я обнаружил, что мне все равно нужно будет сделать это с помощью xdist (то есть написать стек удаленного выполнения).   -  person vladosaurus    schedule 24.08.2015
comment
Хорошо, так что вы можете ответить на свой вопрос здесь.   -  person flazzarini    schedule 24.08.2015
comment
при этом я не могу использовать «ткань» для этой цели, потому что она падает при попытке запуска в параллельном режиме в Windows (в Linux она работает отлично).   -  person vladosaurus    schedule 24.08.2015


Ответы (2)


Мой окончательный проект использует ssh и многопроцессорность вместо xdist (в функции execute_tc()):

import multiprocessing
import test_functions

def test_example_message(self):
"""Example test case"""
    # to get IPs, usernames, passwords, other required data
    config = get_test_config('example_message')
    # will take care of threading and executing parts
    result_dict = execute_tc(config)
    # to fail or not to fail. take care of proper reporting
    process_results(result_dict)

def execute_tc(config):
"""Execute test code in parallel"""
    # create shared results dictionary
    manager = multiprocessing.Manager()
    result_dict = manager.dict({})
    # create processes
    processes = []
    for func, platform, args in config:
        function = getattr(test_functions, func)
        worker = multiprocessing.Process(target=function, args=[result_dict, platform, args])
        worker.daemon = True
        worker.start()
        processes.append(worker)

    for process in processes:
        process.join()

    return result_dict
person vladosaurus    schedule 24.08.2015
comment
и я нашел этот пример особенно полезным при работе с ssh: sebastiandahlgren.se/2012/10/11/ - person vladosaurus; 25.08.2015
comment
Я всегда нахожу интеграционные тесты распределенных/SSH интересными (и не очень хорошо задокументированными или опубликованными в блогах). Спасибо за обновление. - person Scott Prive; 12.06.2017
comment
Я использую для этого SSH (Paramiko). Я тестирую БОЛЬШУЮ систему, слишком большую, чтобы ее можно было имитировать, и слишком большую, чтобы раскручивать, запускать, тестировать и уничтожать. (Вместо имитации у нас есть сценарии, которые постоянно проверяют или откатывают лабораторию до известного состояния). Я использую Paramiko (SSH) для работы на сервере A, жду, а затем проверяю состояние на сервере B (который потребляет нисходящие данные от A). Если бы я начинал с нуля, я бы предпочел Spur.py вместо Paramiko. - person Scott Prive; 12.06.2017

def execute_tc(config):
"""Execute test code in parallel"""
    # create shared results dictionary
    manager = multiprocessing.Manager()
    result_dict = manager.dict({})
    # create processes
    processes = []
    for func, platform, args in config:
        function = getattr(test_functions, func)
        worker = multiprocessing.Process(target=function, args=[result_dict, platform, args])
        worker.daemon = True
        worker.start()
        processes.append(worker)

    for process in processes:
        process.join()

    return result_dict

Я думаю, вы изменили метод выполнения тестового примера для выполнения определенных тестовых случаев.

person Venkat    schedule 25.08.2015
comment
«функция» заботится о том, что именно должно быть выполнено, в зависимости от параметра «платформа». def test_function(result_dict, platform,[server,...]): if platform == 'windows': result_dict['windows'] = do_sth_locally() else: result_dict[platform] = ssh_execute('remote_func', server) - person vladosaurus; 25.08.2015