Почему делают я должен знать, сколько тестов я буду запускать с Тестом::Еще?
Вы можете передавать данные в ответ, но вы не можете динамически обновлять шаблон так, как вы описываете. Шаблон создается один раз на стороне сервера, а затем отправляется клиенту. Вам нужно будет использовать JavaScript для чтения потокового ответа и вывода данных на стороне клиента.
Используйте XMLHttpRequest, чтобы сделать запрос к конечной точке, которая будет передавать данные. Затем периодически читайте поток, пока он не будет выполнен.
В этом примере используется очень простой формат сообщения: одна строка данных, за которой следует новая строка. Конечно, вы можете так же усложниться в разборе, сколько хотите, пока есть способ идентифицировать каждое сообщение. Например, вы можете вернуть объект JSON и декодировать его на клиенте.
from time import sleep
from flask import Flask, render_template
from math import sqrt
app = Flask(__name__)
@app.route('/')
def index():
# render the template (below) that will use JavaScript to read the stream
return render_template('index.html')
@app.route('/stream_sqrt')
def stream():
def generate():
for i in range(500):
yield '{}\n'.format(sqrt(i))
sleep(1)
return app.response_class(generate(), mimetype='text/plain')
app.run()
<p>This is the latest output: <span id="latest"></span></p>
<p>This is all the output:</p>
<ul id="output"></ul>
<script>
var latest = document.getElementById('latest');
var output = document.getElementById('output');
var xhr = new XMLHttpRequest();
xhr.open('GET', '{{ url_for('stream') }}');
xhr.send();
var position = 0;
function handleNewData() {
// the response text include the entire response so far
// split the messages, then take the messages that haven't been handled yet
// position tracks how many messages have been handled
// messages end with a newline, so split will always show one extra empty message at the end
var messages = xhr.responseText.split('\n');
messages.slice(position, -1).forEach(function(value) {
latest.textContent = value; // update the latest value in place
// build and append a new item to a list to log all output
var item = document.createElement('li');
item.textContent = value;
output.appendChild(item);
});
position = messages.length - 1;
}
var timer;
timer = setInterval(function() {
// check the response for new data
handleNewData();
// stop checking once the response has ended
if (xhr.readyState == XMLHttpRequest.DONE) {
clearInterval(timer);
latest.textContent = 'Done';
}
}, 1000);
</script>
8 ответов
Какова причина требования плана тестирования по умолчанию?
ответ ysth связывается с большим обсуждением этой проблемы, которая включает комментарии Michael Schwern и Ovid, которые являются Test::More и Test::Most специалисты по обслуживанию соответственно. По-видимому, это подходит время от времени в perl-быстродействующем списке и является чем-то вроде спорного вопроса. Вот выделения:
Причины не использовать план тестирования
- Его раздражение и занимает время.
- Не стоящий времени, потому что сценарии тестирования не умрут без тестовой обвязки, замечающей кроме некоторых редких случаев.
Test::Moreможет считать тесты, как они происходят- Если Вы используете план тестирования и потребность пропустить тесты, то Вы страдаете от дополнительной боли необходимости a
SKIP{}блок.
Причины использовать план тестирования
- Только требуется несколько секунд, чтобы сделать. Если это занимает больше времени, Ваша тестовая логика слишком сложна.
- Если будет выход (0) в коде где-нибудь, то Ваш тест завершится успешно, не выполняя остающиеся тестовые сценарии. Соблюдающий человек может заметить, что экранный вывод не выглядит правильным, но в автоматизированном наборе тестов он мог остаться незамеченным.
- Разработчик мог бы случайно записать тестовую логику так, чтобы некоторые тесты никогда не работали.
- У Вас не может действительно быть индикатора выполнения, не зная заранее, сколько тестов будет запущено. Это трудно сделать через один только самоанализ.
Альтернатива
Test::Simple, Test::More, и Test::Most имейте a done_testing() метод, который нужно назвать в конце сценария тестирования. Это - подход, который я в настоящее время проявляю.
Это решает проблему, где код имеет exit(0) в нем. Это не решает проблему логики, которая неумышленно пропускает тесты все же.
Короче говоря, ее более безопасное для использования плана, но возможностей этого, на самом деле спасание положение является низким, если наборы тестов не являются сложными (и они не должны быть сложными).
Так использование done_testing() второй план. Вероятно, не огромное соглашение вообще Ваше предпочтение.
Эта функция была полезна для кого-либо в реальном мире?
Несколько человек упоминают, что эта функция была полезна для них в реальном слове. Это включает Larry Wall. Michael Schwern говорит, что функция происходит с Larry больше чем 20 лет назад.
Другие языки имеют эту функцию?
Ни один из xUnit комплектов сертификационного испытания не имеет функцию плана тестирования. Я не столкнулся ни с какими примерами этой функции, используемой ни на каком другом языке программирования.
Любое тестирование лучше, чем отсутствие тестирования, но тестирование должно быть преднамеренным. Указание ожидаемого количества тестов дает вам возможность увидеть, есть ли ошибка в тестовом скрипте, которая не позволяет выполнить тест (или выполнить слишком много раз). Если вы не запускаете тесты при определенных условиях, вы можете использовать функцию пропуска, чтобы объявить это:
SKIP: {
skip $why, $how_many if $condition;
...normal testing code goes here...
}
Меня это тоже раздражает, и я обычно игнорирую число в самом начале, пока набор тестов не стабилизируется. Тогда я просто обновляю их вручную. Мне очень нравится идея узнать, сколько всего тестов существует в виде секунд, как своего рода индикатор прогресса.
Чтобы упростить подсчет, я ставлю перед каждым тестом следующее:
#----- load non-existant record -----
....
#----- add a new record -----
....
#----- load the new record (by name) -----
....
#----- verify the name -----
etc.
Затем я могу быстро отсканировать файл и легко подсчитать тесты, просто ища строки #-----. Я полагаю, что мог бы даже написать что-нибудь в Emacs, чтобы сделать это для меня, но, честно говоря, это не такая уж и тяжелая работа.
Это боль при выполнении TDD, потому что вы пишете новые тесты оппортунистически. Когда я преподавал TDD, а в магазине использовался Perl, мы решили использовать наш тестовый набор без плана. Я думаю, что мы могли бы изменить с no_plan, чтобы ограничить количество тестов. В то время я видел в этом больше помех, чем помощи.
Я не уверен, что Вы действительно спрашиваете, потому что извлечение документации, кажется, отвечает на это. Я хочу знать, работали ли все мои тесты. Однако я не нахожу это полезным, пока набор тестов не стабилизировался.
При разработке я использую no_plan, потому что я постоянно добавляю к набору тестов. Поскольку вещи стабилизировались, я проверяю количество тестов, которые должны выполнить и обновить план. Некоторые люди упоминают "тестовую обвязку", уже ловя это, но нет такой вещи как "тестовая обвязка". Существует тот, который большинство модулей использует по умолчанию, потому что это что MakeMaker или Модуль:: Сборка указывает, но вывод TAP независим от какого-то конкретного потребителя TAP.
Несколько человек упомянули ситуации, где количество тестов могло бы варьироваться. Я выясняю тесты однако, я должен вычислить число, затем используют это в плане. Это также помогает иметь маленькие тестовые файлы, которые предназначаются для очень определенной функциональности, таким образом, количество тестов будет небольшим.
use vars qw( $tests );
BEGIN {
$tests = ...; # figure it out
use Test::More tests => $tests;
}
Можно также разделить количество от загрузки:
use Test::More; plan tests => $tests;
Последний TAP позволяет Вам поместить план в конец также.
В одном комментарии Вы, кажется, думаете, преждевременно выходя, рассчитает как отказ, так как план не будет произведен в конце, но это не имеет место - план будет произведен, если Вы не завершите с POSIX:: _exit или фатальный сигнал и т.п. В частности, умрите (), и выход () приведет к производимому плану (хотя тестовая обвязка должна обнаружить что-либо кроме выхода (0) как преждевременно завершенный тест).
Можно хотеть посмотреть на Тест:: большинство задержало опцию плана, скоро чтобы быть в Тесте:: Больше (если это уже не).
Также было обсуждение этого в perl-быстродействующем списке недавно. Один поток: http://www.nntp.perl.org/group/perl.qa/2009/03/msg12121.html
Я думаю, что нормально изгибать правила и использовать no_plan, когда человеческая стоимость выяснения плана слишком высока, но эта стоимость является хорошим признаком, что набор тестов не был хорошо разработан.
Другой случай, где полезно иметь test_plan explicitely определенный, - при выполнении этого вида тестов:
$coderef = sub { my $arg = shift; isa_ok $arg, 'MyClass' };
do(@args, $coderef);
и
## hijack our interface to test it's called.
local *MyClass::do = $coderef;
Если Вы не указываете план, легко пропустить тот Ваш проваленный тест и что некоторые утверждения не были выполнены, как Вы ожидали.
Ответ Eric Johnson точно корректен. Я просто хотел добавить это done_testing, намного лучшая замена к no_plan, был выпущен в Простом Тестом 0.87_1 недавно. Это - экспериментальный выпуск, но можно загрузить его непосредственно с предыдущей ссылки.
done_testing позволяет Вам объявлять количество тестов, Вы думаете, что работали в конце своего сценария тестирования, вместо того, чтобы пытаться предположить это, прежде чем Ваш сценарий запустится. Можно прочитать документацию здесь.