Создание теста для асинхронного метода

Question

Итак, я разрабатывал некоторые коды, используя AWS Lambda с NodeJS 6.10. Из-за недостатка знаний в интеграционном тестировании (не волнуйтесь, юнит-тесты выполнены) я не тестировал свой код. Конечно, я пропустил ошибку, которая вызвала две бессонные ночи. Он продолжает работать даже после того, как я вставил

return workerCallback(err);

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

SQSService.deleteMessage

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

Вот код, который работает, как и ожидалось.

function myFoo(currentRequest,event, workCallback){

    var current_ts = moment();
    var req_ts = moment(currentRequest.request_timestamp);

    if (req_ts.diff(current_ts, 'minutes') > 5) {
    SQSService.deleteMessage(event.ReceiptHandle, function(err, data){
        if (err) {
            return workerCallback(err);
        } else {
            return workerCallback(null, "Request stale! Deleting from queue...");
        }
    }); //end of SQS Service
        return; //This line... this line!
    }

    /* Codes below will execute because the code above is asynchronous
       but it should not as the asynchronous code above is a terminator function 
    from a business logic point of view
    */

    //more codes that will run should currentRequest.request_timestamp is 5 minutes past

 }

Может кто-нибудь подсказать мне, как проверить этот код или создать тест, который, по крайней мере, помешал бы мне повторить ту же ошибку? Я хотел бы избежать повторения этих ошибок при тестировании. Спасибо!

Answer 1

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

Ключ в том, чтобы правильно понять асинхронность вашего кода. myFoo кажется асинхронным, поэтому вам нужно решить, будут ли все ошибки или режимы сбоя обрабатываться как ошибки, передаваемые его обработчику обратного вызова, или некоторые типы ошибок должны возвращать синхронные ошибки самому вызывающему myFoo. Мой общий подход заключается в том, что если какие-либо ошибки проходят через обработчик обратного вызова, чтобы все они проходили туда - за небольшим исключением некоторых типов ошибок плохого кодирования (например, передача неправильных типов или передача нулевых аргументов для аргументов). это всегда должно иметь переменные), которые я мог бы throw Error() для. Но если этот тип ошибки (project_ref_no == null) является той ошибкой, которую вы должны корректно обработать, то я, вероятно, передам ее обработчику ошибок. Общая идея заключается в том, что когда вы вызываете myFoo, и он возвращается, все, что вы знаете, это то, что какая-то работа будет выполнена в какой-то момент, но вы не знаете, что произойдет (и не получите результат в ответе) - ответ будет возвращаться позже при вызове обработчика обратного вызова).

Но, что более важно, важно понять, какой код запускается немедленно и какой код находится в обработчике обратного вызова. Вы были сбиты с толку, потому что мысленно представляете, что внутренний обработчик обратного вызова (переданный в SQSService.deleteMessage) запускается, когда вы вызываете myFoo.

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

Typescript помогает в этом немного, потому что вы можете определить тип возвращаемого значения функции, и ваша IDE должна дать вам предупреждение, если у вас есть пути кода, которые не возвращают что-то такого типа (что-то наиболее / все? Набрано) языки дают вам) - и это несколько помогло бы, но не охватило бы все случаи (например, функции, возвращающие void).

Если вы новичок в асинхронных моделях javascript и / или javascript, вы можете проверить следующую ссылку:

https://medium.com/codebuddies/getting-to-know-asynchronous-javascript-callbacks-promises-and-async-await-17e0673281ee