Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to flush pending message queue #51

Open
Coteh opened this issue Dec 24, 2020 · 5 comments · May be fixed by #170
Open

Add ability to flush pending message queue #51

Coteh opened this issue Dec 24, 2020 · 5 comments · May be fixed by #170
Assignees
Labels
enhancement New feature or request

Comments

@Coteh
Copy link

Coteh commented Dec 24, 2020

I am currently utilizing this library to mock communication between my frontend app and an IRC gateway called webircgateway for my unit tests, and I wasn't able to find a function that can clear out the pending message queue within a test. I am testing whether my app can send out a message, and I currently have to copy and paste await server.nextMessage so that I can discard the IRC initial communication messages (PASS, NICK, and USER) which I don't care about so that I can then call toReceiveMessage and toHaveReceivedMessages on the PRIVMSG message, which I do care about.

I attempted to make my own makeshift flush function:

async function flushWebSocketMessages(server: WS) {
    while (1) {
        const result = await promiseWithTimeout(server.nextMessage);
        if (result === null) {
            break;
        }
    }
}

function promiseWithTimeout<T>(promise: Promise<T>) {
    return new Promise((resolve, reject) => {
        promise
            .then((val) => resolve(val))
            .catch((err) => reject(err));

        setTimeout(() => {
            resolve(null);
        }, 2000);
    });
}

However, it does not seem to work because once I clear out the queue (which happens when we cannot get any more messages and the 2s timeout returns null) any message I send through the WebSocket is reported by the mock server as undefined:

 expect(WS).toReceiveMessage(expected)

    Expected the next received message to equal:
      "PRIVMSG #mychannel :Hello there"
    Received:
      undefined

    Difference:

      Comparing two different types of values. Expected string but received undefined.

I have decided to work around this for the time being by copy and pasting await server.nextMessage like I mentioned earlier in order to clear out the queue, but I would like to know why this is happening if possible. Also, let me know if flushing the pending message queue is something that can benefit this project, thanks.

@Coteh Coteh changed the title Add ability to flush queue Add ability to flush pending message queue Dec 24, 2020
@romgain
Copy link
Owner

romgain commented Jan 20, 2021

Hi @Coteh !

Thanks for the feedback, that's a good point!

I'm totally up for implementing something like that, but I'm afraid that the best solution would be a breaking change:

  • .toReceiveMesage should be updated to not stop at the next message, but instead wait until it finds a message matching the expected value
  • we should add a toReceiveMessageNext matcher that works like the existing toReceiveMessage

Would that fix your problem?
If so, is that something you'd be interested in working on?

@Coteh
Copy link
Author

Coteh commented Jan 21, 2021 via email

@romgain
Copy link
Owner

romgain commented Jan 21, 2021

Thanks @Coteh !

@romgain romgain added the enhancement New feature or request label Jan 21, 2021
@Coteh
Copy link
Author

Coteh commented Jan 31, 2021

Hey just wondering what you think should happen if .toReceiveMessage is called but the expected message is never received. I am thinking that we can wait until the timeout occurs and if the message doesn't come by that point, then we can confidently say that the message will not arrive. What do you think?

From what I've read of the codebase so far, it doesn't seem to me that would be any timing issues with messages being received much later than they're supposed to, but just want to confirm with you if this is the case. Thanks.

@romgain
Copy link
Owner

romgain commented Jan 31, 2021

Yup, that sounds good 👍

What would also be useful when we hit the timeout, would be to show all the messages we received since the toReceiceMessage call, something similar to the .toHaveBeenCalledWith output.

Maybe something like “Expected message foo was not received within XXXms. Received X Y Z instead.”
With the same green/red colours as in the default toHaveBeenCalledWith output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
2 participants