Разумная стратегия для модульного тестирования ожидаемого и непредвиденного поведения взаимоблокировок

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

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

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

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

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

РЕДАКТИРОВАТЬ: Я уверен, что здравый смысл в тестировании был бы неплохим, но я не думаю, что мне это нужно. Я думаю о трех уровнях достоверности тестирования.

  • «Доказано, что фактическое поведение соответствует ожидаемому поведению» тупик не может возникнуть
  • «фактическое поведение соответствует ожидаемому поведению» тупик не возник в N тестах
  • «Фактическое поведение соответствует ожидаемому поведению» N тестов завершено в ожидаемые сроки

Первый, конечно, ценный тест, который нужно пройти, но ответ ShiDoiSi говорит о непрактичности этого. Второй значительно слабее первого, но все же жесткий; Как вы можете установить, что сеть процессов действительно зашла в тупик? Я не уверен, что это легче доказать, чем первое (может быть, намного сложнее)

Последнее больше похоже на то, что я имел в виду.

6
задан SingleNegationElimination 17 June 2011 в 17:39
поделиться