Nodejs Тестирование. Как избежать условий гонки?

Question

В настоящее время я пишу движок игры в nodejs.

В моей игре несколько штатов. Назовем их StateA, StateB, StateC. Поток последовательности - StateA => StateB => StateC.

Я хотел бы проверить состояние моего двигателя в конце каждого состояния. Я в настоящее время имеют такую ​​структуру:

function attachEventListeners = function(instance) { 
    instance.on('START_STATE_A', stateA); 
    instance.on('START_STATE_B', stateB); 
    instance.on('START_STATE_C', stateC); 
} 

var stateACallBack = function() {}; 
var stateBCallBack = function() {}; 
var stateCCallBack = function() {}; 

function stateA() { 
    // Do something... 
    stateACallBack(); 
    setTimeout(function() { this.emit('START_STATE_B'); }, 3000) 
} 

function stateB() { 
    // Do something... 
    stateBCallBack(); 
    setTimeout(function() { this.emit('START_STATE_C'); }, 3000) 
} 

function stateC() { 
    // Do something... 
    stateCCallBack(); 
    setTimeout(function() { this.emit('START_STATE_A'); }, 3000) 
} 

Так что мой нынешний подход подразумевает наличие моих тестовых примеров переопределения stateXCallback и выполнение логики тестирования в этих функций.

Однако, я вижу состояние гонки, когда stateB уволен до stateACallBack закончил выполнение. В результате stateACallback видит состояния, которые должны быть вычислены с помощью stateBCallback.

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

Может кто-нибудь, пожалуйста, просветит меня лучший подход к этой проблеме?

Answer 1

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

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

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