Как создать модульные тесты для алгоритма справедливого распределения? - PullRequest
1 голос
/ 29 мая 2011

У меня есть следующий алгоритм:
Учитывая список учетных записей , я должен разделить их справедливо между пользователями системы .
Теперь, чтобы облегчитьнагрузка на пользователей, я должен разделить их по дням.
Таким образом, если в учетной записи есть заказов на обслуживание , они должны быть включены в список, который будет распределяться в течение 547 дней (полтора года),Если в учетной записи нет заказов на обслуживание , они должны быть включены в список, который будет распространяться в течение 45 дней (полтора месяца).
Я использую следующее расширение LINQ из aвопрос, который я задавал ранее :

public static IEnumerable<IGrouping<TBucket, TSource>> DistributeBy<TSource, TBucket>(
this IEnumerable<TSource> source, IList<TBucket> buckets)
{
    var tagged = source.Select((item,i) => new {item, tag = i % buckets.Count});
    var grouped = from t in tagged
                  group t.item by buckets[t.tag];
    return grouped;
}

, и я могу гарантировать, что он работает.
Моя проблема в том, что я не знаю, как выполнить модульное тестирование во всех этих случаях.
Iможет иметь 5 пользователей и 2 учетные записи, которых может быть недостаточно для разделения на полтора года или даже полтора месяца.
У меня может быть ровно 547 учетных записей и 547 системных пользователей, поэтому каждая учетная запись будет обрабатываться каждойсистемный пользователь каждый день.
По сути, я не знаю, какие типы данных мне следует создавать, потому что кажется, что вариантов слишком много, и что я должен утверждать, потому что я понятия не имею, каким будет распределение.

Ответы [ 2 ]

2 голосов
/ 29 мая 2011

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

Дляпример:

  • Как ведет себя метод при наличии нулевых учетных записей?
  • Ноль пользователей?
  • Ровно одна учетная запись и пользователь
  • 547 учетных записейи 547 пользователей

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

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

0 голосов
/ 30 мая 2011

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

public interface IAllocator
{ IAllocation Solve(IEnumerable<User> users, IEnumerable<Account> accounts); }

и пишите тесты, которые проверяют не конкретную реализацию учетных записей для пользователей, а то, что распределение является справедливым, чтобы быть определенным - что-то вроде «каждому пользователю должно быть назначено одинаковое количество учетных записей, плюс или минус одна». Определение того, что является справедливым или какова точная цель вашего алгоритма, должно помочь вам определить наиболее интересные случаи. Отработка цели более высокого уровня (распределение должно быть справедливым, а не конкретным распределением) должно позволить вам легко менять реализации и проверять, выполняет ли распределитель свою работу.

...