Тестирование командной строки

Я ищу способ запуска тестов в утилитах командной строки, написанных на bash, или на любом другом языке.

Я бы хотел найти структуру тестирования, которая бы имела такие выражения, как

setup:
    command = 'do_awesome_thing'
    filename = 'testfile'
    args = ['--with', 'extra_win', '--file', filename]
    run_command command args

test_output_was_correct
    assert_output_was 'Creating awesome file "' + filename + '" with extra win.'

test_file_contains_extra_win
    assert_file_contains filename 'extra win'

Предположительно, базовый тестовый пример установит временную директорию, в которой будут выполняться эти команды, и удалите ее при разрыве.

Я бы предпочел использовать что-то в Python, так как я гораздо более знаком с ним, чем с другими правдоподобными языками.

Я предполагаю, что может быть что-то, использующее DSL, что сделает его эффективно языковым агностиком (или собственным языком, в зависимости от того, как вы на него смотрите); однако это может быть менее идеальным, так как мои методы тестирования обычно включают в себя код записи, который генерирует тесты.

Это немного сложно для Google, так как есть много информации об утилитах, которые запускают тесты, что является своего рода обращением к тому, что я ищу.

Поддержка доктрин, встроенных в вывод command --help, будет дополнительным бонусом:)

ОТВЕТЫ

Ответ 1

Отъезд ScriptTest:

from scripttest import TestFileEnvironment

env = TestFileEnvironment('./scratch')

def test_script():
    env.reset()
    result = env.run('do_awesome_thing testfile --with extra_win --file %s' % filename)
    # or use a list like ['do_awesome_thing', 'testfile', ...]
    assert result.stdout.startswith('Creating awesome file')
    assert filename in result.files_created

Это разумно подходит и для использования в доктрине.

Ответ 2

Ну... Что мы обычно делаем (и одно из чудес O.O.) - это написать все компоненты приложения, прежде чем делать приложение. Каждый компонент может иметь автономный способ выполнения для целей тестирования (обычно в командной строке), что также позволяет вам мыслить в них как полные программы по каждому из них и использовать их в будущих проектах. Если вы хотите проверить целостность существующей программы... ну, я думаю, что лучший способ - глубоко изучить, как это работает, или даже глубже: прочитать источник. Или еще глубже: развить бота, чтобы проверить его: 3

Извините, что у меня есть.-.

Ответ 3

Я знаю, что этот вопрос старый, но так как я искал ответ, я решил, что добавлю его для кого-то еще, кто будет рядом.

Полное выражение об отказе от ответственности: проект, о котором я упоминаю, является моим собственным, но он полностью бесплатный и с открытым исходным кодом.

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

from CLITest import CLITest, TestSuite
from subprocess import CalledProcessError


class TestEchoPrintsToScreen(CLITest):
    '''Tests whether the string passed in is the string
    passed out'''

    def test_output_contains_input(self):
        self.assertNotIsInstance(self.output, CalledProcessError)
        self.assertIn("test", self.output)

    def test_ouput_equals_input(self):
        self.assertNotIsInstance(self.output, CalledProcessError)
        self.assertEqual("test", self.output)

suite = TestSuite()

suite.add_test(TestEchoPrintsToScreen("echo test"))

suite.run_tests()

Это работало достаточно хорошо, чтобы помочь мне в решении моих проблем, но я знаю, что он мог бы использовать еще одну работу, чтобы сделать ее максимально надежной (тестовое обнаружение приходит в голову). Это может помочь, и я всегда люблю хороший запрос на тягу.

Ответ 4

за пределами любой предварительно упакованной структуры тестирования, которая может существовать, но я не знаю, я бы просто отметил, что ожидание - это удивительный и настолько недоиспользуемый инструмент для такого рода автоматизации, особенно если вы хотите поддерживать многоэтапное взаимодействие, скажем, не просто отправить команду и проверить выход, а ответить на вывод с большим количеством ввода. Если вы завершаете создание собственной системы, стоит посмотреть.

Существует также повторная реализация python ожидаемого имени pexpect. Возможно, есть и некоторые прямые интерфейсы для библиотеки ожидающих. Я не парень-питон, поэтому я не мог рассказать вам о них.