Опираясь на порядок выполнения сценариев, это анти-паттерн и его следует избегать. Участники тестов обычно не предоставляют какого-либо механизма для контроля порядка выполнения по той же причине. Это также противоречило бы концепции исполняемой спецификации: сценарий должен быть понятным (и исполняемым) сам по себе.
В вашем случае данная часть должна подготовить данные для рассматриваемого вычисления, когда следует рассчитать, а затем проверить результат этого единственного вычисления.
Чтобы сократить время выполнения, возможно, вы могли бы попытаться выбрать «важные» сценарии таким образом, чтобы они тестировали различные аспекты. Вероятно, нет необходимости проверять каждый месяц 1-11. У вас может быть один тест для первой месячной заработной платы, один для 2-го месяца, один для закрытия всего года, один для начала нового года и т. Д.
Это также распространенная техника, которая не обязательно должна быть сделана так же, как "настоящее приложение" (с нуля). Иногда вы можете сделать ярлыки в тесте, чтобы обеспечить предварительные условия быстрее и проще. Например. Вы можете указать суммы за предыдущий месяц, если это все, что нужно вашему сценарию для расчета следующего месяца (вместо того, чтобы позволить приложению вычислять все с нуля). Конечно, вы должны знать, что вы делаете, и вы должны учитывать риск, связанный с подделкой некоторых аспектов приложения.