search

melezhik / swat

Simple Web Application Test
49 stars 12 forks source link

поодержка запуска группы тестов через -t path path2 path3 #13

Closed ivanych closed 8 years ago

ivanych commented 8 years ago

Предлагаю сделать такой интерфейс:

swat [--host host] [name ...]

Где:

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

Кроме того, так лучше работает поиск предыдущей команды в истории командной строки.

melezhik commented 8 years ago

в силу всего выше сказанного я бы предложил так:

swat [--host host] [ --path path ] [/path/to/root] [host]

Что думаешь?

ivanych commented 8 years ago

name - это каталоги с тестами внутри проекта. Пусть будет dir, чтобы не путаться. Обрати внимание - не один каталог, а произвольное количество. Именно поэтому name должны идти в конце всей команды и дополняться tab'ом, как во всех командах, работающих с файлами, типа cp.

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

Но если необходимо - ок, пусть задается опцией --root.

Тогда:

swat [--host host] [--root root] [dir ...]
melezhik commented 8 years ago

Можно принять волевое решение и считать, что корень всегда равен текущему каталогу. Гит же именно так делает, чем сват хуже:)

Михаил, понял тебя. Подумаю над этой идей, тут могут быть плюсы и минусы

melezhik commented 8 years ago

Вот мои мысли. 1) форсировать корень проекта к текущей директории удобно для одних случаев, и не удобно для других, поэтому я бы в этом смыле оставил текущее поведение

2) корень проекта хочется всегда передавать как неименнованный параметр

swat /path/to/root

ну или если он не задан, то считем, что root == cwd

Ввводить отдельно опцию --root я бы не стал, зачем? пока не очень понятно, всегда можно указать путь к руту как есть - /path/to/root , не использую для этого специальную опцию --root

3) кейс с избирательным запуском тестов, заданных поддиректорией мне понятен, насколько тебе критично, что бы таких поддеректорий было несколько? Можешь в двух словах пояснить зачем тебе это? Спрашиваю, потому что в текущей архитектуре скрипта это сложно реализуемо. Swat генерит набор тестовых файлов, складывает в отдельную директорию, а потом запускает prove -r передав ему на вход эту директорию, prove умеет выполнять либо все ( всю директорию ), либо отдельный путь - подкаталог или файл из этой директории, но не может оперировать сразу с несколькими путями или файлами , можно конечно запускать prove для каждого пути, директории выборочного , но это будет означать что фактически запускают сразу несколько разный тестовых наборов и для каждого prove будет генерить свой отчет, что наверное не очень хорошо ....

ivanych commented 8 years ago

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

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

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

ivanych commented 8 years ago

Ну т.е. я могу вызвать оба теста по отдельности, дважды запустив сват, но это неудобно, потому что есть медленные методы, нужно ждать завершения... А так набил tab'ом несколько каталогов - и пошел за кофе:)

melezhik commented 8 years ago

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

т.е. предполагается, что второй метод (тест) не отработает , если перед ним не отработает первый метод ( тест ), так или я неправильно понял?

ivanych commented 8 years ago

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

melezhik commented 8 years ago

А понял.

melezhik commented 8 years ago

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

melezhik commented 8 years ago

Почитал документацию по prove, оказывается от умеет работать с нескольки путями сразу. То, что ты просил реализова, обновись с гитхаба, см. описание новых натсроек https://github.com/melezhik/swat#swat-client. Тепреь есть -t, или --test что бы задавать тестовые наборы, их может быть несколько, --root решил не вводить, оставил старую схему, мне кажется она более интутивно понятная и подходит под большинство сцерариев использования. Да и настройки для prove теперь передаются явно, через --prove, пришлось пойти на это, что бы отделить их от остальных настроек

ivanych commented 8 years ago

Это не то:(

Конечно, возможность задать несколько тестов - это хорошо. Но главная моя идея - тесты должны задаваться в конце, как аргументы, и дополняться tab'ом.

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

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

Может, сделать параллельную утилиту, swat-dev, с "моим" интерфейсом?

ivanych commented 8 years ago

Или во, можно так сформулировать: у меня основной единицей использования является отдельный тест, а не проект целиком. Запуск проекта целиком - это у меня целое событие, мне это надо редко. А вот запуск отдельного теста/тестов - это основной сценарий.

Поэтому мне нужно, чтобы интерфейс команды вертелся вокруг тестов с минимальными телодвижениями, а всё остальное можно было задать как-нибудь, через опции.

melezhik commented 8 years ago

Михаил, я тебя понимаю, но если честно не вижу в чем сложность задавать набор путей через

-t path1 -t path2 -t pathN ?

здесь точно также работает tab дополение, тебе просто нужно на каждый путь набирать один раз -t , это сложно?

При всем при том, если у тебя настроен host файл и ты находишься внутри корневой директории с тестами,все что тебе нужно это запустить:

swat -t path1 -t path2 -t path3

Ни хоста, ни проекта указывать не требуется

Та схема, которую ты предлагаешь удобная тебе но потребует введние дополнительных параметров, если кто-то захочет "обычного" использования swat:

swat project_root host

Так как в этом случае нужно будет вводить параметры --root и возможно --host, что бы отличать эти аргументы от просто набора путей , задающих группы тестов. Мы приходим к тому, что все становится сложнее, пользователи должны будут вседа по-разному указывать хост и корень взависимости от способа запуска тестов ( все целиком или выборочно ), согласись по сравнению, с тем, что ты просто набираешь на два символа в консоле (-t) - это неоправданное усложнение?

То есть я конечно за гибкость, но не в ущерб простоте. Вот что я пытаюсь сказать.

ivanych commented 8 years ago

Но ведь --root и --host, даже если их задавать, нужно написать только один раз. А вот -t придется писать много раз. И стирать тоже много раз.

При этом, я уверен, в большинстве случаев запуск будет делаться из текущего каталога, поэтому --root, скорее всего, писать нужно будет очень редко.

Остается --host. Но даже --host нужно написать только один раз, потому что меняется потом только значение этой опции, а саму опцию писать не надо, она уже есть в хистори.

Поэтому мне кажется, что проще получается именно в случае, когда тесты являются аргументами, а всё остальное - опциями.

Ну и вот ещё такой аргумент:)

Это же классический юникс-стайл, когда аргументами являются файлы. Пример на перле:

 perl -e '@file=<>; print @file' test.txt

Перл по умолчанию считает, что аргумент - файл.

melezhik commented 8 years ago

Ok, а вариант

swat --test-group path1 path2 path3 ...

как компромиссный ?

ivanych commented 8 years ago

Да, это хороший вариант. Теоретически всё-равно неправильно, но практически - полностью решает все мои проблемы:)

А суффикс -group вроде бы и не нужен, пусть просто --test будет.

melezhik commented 8 years ago

Я предложил --test-group , потому что --test или -t задают одиночный path, а --test-group может задавать больше чем один path.

Это особенности реализации, мне так проще будет внедрить эту фичу. А вариант с -t,--test я бы тоже оставил, он хорошо читается

Теоретически всё-равно неправильно

Почему?

ivanych commented 8 years ago

Я предложил --test-group , потому что --test или -t задают одиночный path, а --test-group может задавать больше чем один path.

Можно всегда считать, что в опции указывается список, в том числе список может иметь один элемент. Но если удобнее разделить - ок, не принципиально.

Теоретически всё-равно неправильно Почему?

Потому, что файлы должны быть аргументами:) Юникс-стайл:)

melezhik commented 8 years ago

Потому, что файлы должны быть аргументами:) Юникс-стайл:)

Понял :) учту

melezhik commented 8 years ago

Михаил, приветствую! Опцию --test-group решил не вводить, интерфейс такой:

-t path1 -t path2 -t path3

# или

-t path1 path2 path3

Ушло в релиз, версия 0.1.79 , или ставь из гита и проверяй, все ли так.

ivanych commented 8 years ago

Я что-то потерял нить.. Вроде же были уже -t? Что изменилось?

melezhik commented 8 years ago

они и остались, но теперь их можно использовать несколькими способами, swat теперь поддерживает ( в новой версии ) различные нотации:

-t foo
-t foo -t bar
-t foo bar foo/bar/baz
ivanych commented 8 years ago

А, оке.