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

Regex tests #33

Open
dimpiax opened this issue Mar 11, 2017 · 8 comments
Open

Regex tests #33

dimpiax opened this issue Mar 11, 2017 · 8 comments

Comments

@dimpiax
Copy link
Contributor

dimpiax commented Mar 11, 2017

Need to add regex tests.
Tested expression on validators, it gives strange results.
@developit could you provide expectations?

@tunnckoCore
Copy link
Collaborator

What regex tests?

@dimpiax
Copy link
Contributor Author

dimpiax commented Mar 11, 2017

For /^(.*?):\s*([\s\S]*?)$/gm.
What do we expect for input?

@tunnckoCore
Copy link
Collaborator

I can't get what you're talking about. Where's that? What regexes here?

@dimpiax
Copy link
Contributor Author

dimpiax commented Mar 11, 2017

28 lines.

@tunnckoCore
Copy link
Collaborator

Good moin'. Next time when open an issue describe what you mean as much as possible in your title and first post.

@dimpiax
Copy link
Contributor Author

dimpiax commented Mar 11, 2017

Wonder that you have not understand.
Anyway mention was not for you.

@developit
Copy link
Owner

@dimpiax I had a bunch of tests I was running in a REPL when writing the header parsing, I should have ported them to unit tests but didn't. Happy to merge a PR that does it. Easiest way will be to mock out XMLHttpRequest, stub getAllResponseHeaders() to return any variances we can find, and then invoke onload() manually.

@simonbuerger
Copy link
Contributor

@developit considering the changes to the headers regex in #92 I'm not sure of the best way to test this anymore. The headers regex is now extremely simple and we're leveraging the internals of XMLHttpRequest with getResponseHeader(). You'll see in that PR the headers tests are by no means comprehensive. Stubbing getResponseHeader in this case isn't really a very useful test. Do we just rely on the XMLHttpRequest internals and only test our (very simple) regex then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants