тестирование утилит командной строки - PullRequest
11 голосов
/ 22 июня 2010

Я ищу способ запуска тестов утилит командной строки, написанных на 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, потому что есть много информации об утилитах, которые запускают тесты, что является своего рода противоположностью того, что я ищу.

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

Ответы [ 4 ]

13 голосов
/ 22 июня 2010

Оформить 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

Это также достаточно удобно для использования.

1 голос
/ 28 января 2015

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

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

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

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()

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

1 голос
/ 22 июня 2010

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

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

0 голосов
/ 22 июня 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...