Класс тестирования, который извлекает непредсказуемые данные

Question

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

Вопрос в том, как проверить его правильно?

кажется разумным мне сделать следующие тестовые случаи:

1. Test это работает в целом: Начало цены загрузки на некоторых линеечку, убедитесь, что загрузка начинается
2. Тестовые данные течёт: Начало цены загрузки на каком-то тике, убедитесь, что я получил некоторое количество обновлений.
3. Проверьте, что у меня разумные цены: начните загружать цены на некоторый тикер, убедитесь, что я получил ожидаемую цену (или хотя бы цену в каком-то разумном диапазоне)

К сожалению:

1. Я не могу быть уверен, что некоторые тикер будет существовать вечно.
2. Я не могу быть уверен, что некоторая цена акций будет обновляться на определенное количество раз в период
3. или будет иметь некоторое точное значение (или даже значение в заданном диапазоне с 100% вероятностью)

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

Answer 1

Недетерминированность и модульные испытания не так хорошо сочетаются. Тем не менее, я бы сказал, что единственным детерминизмом, с которым вы сталкиваетесь, являются данные и его формат, которые вы получаете от встроенного загрузчика. Зачем?

Тест работает в целом: Начало цены загрузки на некоторых линеечку, убедитесь, что загрузка начинается

Это должно быть под контролем .NET кода целиком; либо с помощью какого-либо задания или ручного вызова метода. Нет детерминизма.

Тестовые данные течёт: Начало Загрузка цен на некоторые линеечку, убедитесь, что я получил некоторое количество обновлений

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

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

Что такое разумная цена? Диапазон от 0 до Int32.Max? Не пытайтесь протестировать собственный загрузчик. Сделайте предположения о том, как это работает и создайте свой код вокруг этих предположений. Конечно, вы можете проверить форматы данных, диапазоны (например, цены не должны быть отрицательными значениями), но это все.Это приводит нас к фактическому коду, который вы, возможно, захотите применить к модулю test-class, который отображает свои данные - ваши данные (доменные объекты - простой POCO - StockQuotation или TickerData). Builder/mapper/конвертер.

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

В такой установке, если что-то перестает работать, это, как правило, может означать одно из двух:

1. Предположения вы сделали о данных загрузчика изменился (или упускать из вида что-то)
2. Вашего строителя/картограф/конвертера неверно реализованы в отношении допустимых допущений

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