Поблочное тестирование многопоточное приложение?

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

import csv
import pandas as pd

with open('file.csv') as fc:
    creader = csv.reader(fc) # add settings as needed
    rows = [r for r in creader]
# check consistency of rows
print(len(rows))
print(set((len(r) for r in rows)))
print(tuple(((i, r) for i, r in enumerate(rows) if len(r) == bougus_nbr)))
# find bougus lines and modify in memory, or change csv and re-read it.

# assuming there are headers...
columns = list(zip(*rows))
df = pd.DataFrame({k: v for k, *v in columns if k in ['tweet', 'Sentiment']})

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

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

31
задан Marcus King 21 September 2008 в 18:43
поделиться

9 ответов

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

  • Отсутствие воспроизводимости: тесты перестанут работать только время от времени и не будут действительно полезны для точного определения проблем.
  • Ошибочная провальная сборка будет раздражать всех в команде - потому что последняя фиксация будет всегда неправильно подозреваться для того, чтобы то, что он быть причиной провальной сборки.
  • Мертвые блокировки при обнаружении, вероятно, заморозят сборку, пока с тайм-аутом выполнения не встретятся, который может значительно замедлить сборку.
  • среда сборки, вероятно, будет единственной средой ЦП (думайте сборка, выполняемая в VM), где проблем параллелизма никогда не может происходить - неважно, сколько времени сна установлено.
  • Это побеждает так или иначе идею наличия простого, изолировало единицы из проверки кода.
23
ответ дан 27 November 2019 в 21:50
поделиться

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

я видел демонстрацию на этой неделе на шоу - по-видимому, это находится в Alpha (названо Гонщиком)

http://www.typemock.com/Typemock_software_development_tools.html

7
ответ дан 27 November 2019 в 21:50
поделиться

Если необходимо протестировать это, фоновый поток делает что-то, простая техника, которую я нахожу удобными, состоит в том, чтобы быть иметь метод WaitUntilTrue, который выглядит примерно так:

bool WaitUntilTrue(Func<bool> func,
              int timeoutInMillis,
              int timeBetweenChecksMillis)
{
    Stopwatch stopwatch = Stopwatch.StartNew();

    while(stopwatch.ElapsedMilliseconds < timeoutInMillis)
    {
        if (func())
            return true;
        Thread.Sleep(timeBetweenChecksMillis);
    }   
    return false;
}

Используемый как это:

volatile bool backgroundThreadHasFinished = false;
//run your multithreaded test and make sure the thread sets the above variable.

Assert.IsTrue(WaitUntilTrue(x => backgroundThreadHasFinished, 1000, 10));

Этот путь Вы не должны спать свой основной поток тестирования в течение долгого времени для предоставления времени фонового потока для окончания. Если фон не заканчивается за разумное количество времени, тестовые сбои.

10
ответ дан 27 November 2019 в 21:50
поделиться

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

0
ответ дан 27 November 2019 в 21:50
поделиться

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

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

Так, например, позволяет, говорят, что у нас есть что-то действительно простое, многопоточная очередь, которая обрабатывает объекты работы. Вы дразнили бы объект работы. Интерфейс мог бы включать 'Процесс ()' метод, который поток называет, чтобы сделать работу. Вы поместили два события там. Тот, который устанавливает насмешка, когда Процесс () называют и тот, что насмешка ожидает на том, после того, как это установило первое событие. Теперь, в Вашем тесте можно запустить очередь, отправить ложный объект работы и затем ожидать на событии "I am being processed" объекта работы. Если все, что Вы тестируете, - то, что процесс называют затем, можно установить другое событие и позволить потоку продолжиться. Если Вы тестируете что-то более сложное, как то, как очередь обрабатывает, несколько диспетчеризируют или что-то затем, что Вы могли бы сделать другие вещи (как сообщение и ожидать других объектов работы) прежде, чем выпустить поток. Так как можно ожидать с тайм-аутом в тесте, можно удостовериться, что (говорят), что только два объекта работы обрабатываются параллельно, и т.д., и т.д. Ключевая вещь состоит в том, что Вы делаете тесты детерминированными событиями использования, что потоковые блоки кода на том, так, чтобы тест мог управлять, когда они работают.

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

Вот еще некоторая информация о такого рода вещи, хотя она говорит о кодовой базе C++: http://www.lenholgate.com/blog/2004/05/practical-testing.html

28
ответ дан 27 November 2019 в 21:50
поделиться

Важно протестировать многопоточный код многопроцессорной машины. Двухъядерная машина не может быть достаточной. Я видел, что мертвые блокировки происходят на 4 машинах процессора, которые не произошли на двухъядерном единственном процессоре. Затем необходимо создать стресс-тест на основе клиентской программы, которая порождает много потоков и выполняет несколько запросов против целевого приложения. Помогает, является ли клиентская машина многопроцессорной системой также, таким образом, существует больше нагрузки на целевое приложение.

2
ответ дан 27 November 2019 в 21:50
поделиться

Как Поблочное тестирование GUI, это - что-то вроде Ватерлоо для Автоматизированных тестов. Истинные потоки по определению.. непредсказуемый.. они вмешаются способами, которые не могут быть предопределены. Следовательно запись верный тесты является трудной если не невозможный.

Однако у Вас есть некоторая компания с этим... Я предлагаю перерыть архивы группа testdrivendevelopment yahoo. Я помню некоторые сообщения в близости.. Вот один из более новых. (Если кто-то был бы достаточно любезен, чтобы обстрелять и перефразировать.. это было бы большим. Я являюсь слишком сонным.. Нужно к LO ТАК)

0
ответ дан 27 November 2019 в 21:50
поделиться

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

Я перенес библиотеку multithreadedTC с Java на .NET и назвал ее TickingTest . Он позволяет запускать несколько потоков из метода модульного тестирования и координировать их. В нем нет всех функций оригинала, но я нашел его полезным. Самое большое, чего ему не хватает, - это возможность отслеживать потоки, запускаемые во время теста.

2
ответ дан 27 November 2019 в 21:50
поделиться

Я наткнулся на исследовательский продукт, который называется Microsoft Chess . Он специально разработан для недетерминированного тестирования многопоточных приложений. Обратной стороной является то, что он интегрирован в VS.

4
ответ дан 27 November 2019 в 21:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: