Skip to content
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.

Improve request tests. #48

Closed
wants to merge 12 commits into from
Closed

Conversation

maier49
Copy link
Contributor

@maier49 maier49 commented Jul 7, 2015

Refs #34

Now provides an echo server on port 9001 that proxies most
calls to the intern server, except for requests to /__echo/.

Calls to /__echo/ return a JSON response that contains the
parsed query string, headers, and payload from the request.

If a responseType query parameter is specified, a response
in the format requested will be returned if available.
Currently, 'html', 'document', 'xml', 'json', and 'gif'
are acceptable values for responseType. If any format other
than JSON is requested the response body will not contain
the payload, query or headers from the request.

The X-Requested-With header is no longer being used for
testing custom headers because IE 11 was modifying the
value before sending to the server.

Added tests for different content types and to improve
coverage.

@maier49
Copy link
Contributor Author

maier49 commented Jul 8, 2015

Currently two three of these tests fail because request/xhr is not handling the query property from XhrRequestOptions. Once that is fixed those tests should start passing.

@eheasley eheasley added this to the Milestone 2 milestone Jul 10, 2015
@kfranqueiro
Copy link
Member

We're reassigning this to @maier49 so that he can test #49 when addressing that too.

Matt Wistrand and others added 2 commits July 16, 2015 15:13
* Add `request/util` module with `generateRequestUrl` method.
* Append query string to end of request URL.
* Update `RequesOptions#query` to accept either a string or `ParamList` from `UrlSearchParams`.
Refs dojo#34

Now provides an echo server on port 9001 that proxies most
calls to the intern server, except for requests to /__echo/.

Calls to /__echo/ return a JSON response that contains the
parsed query string, headers, and payload from the request.

If a responseType query parameter is specified, a response
in the format requested will be returned if available.
Currently, 'html', 'document', 'xml', 'json', and 'gif'
are acceptable values for responseType. If any format other
than JSON is requested the response body will not contain
the payload, query or headers from the request.

The X-Requested-With header is no longer being used for
testing custom headers because IE 11 was modifying the
value before sending to the server.

Added tests for different content types and to improve
coverage.
@maier49
Copy link
Contributor Author

maier49 commented Jul 16, 2015

This now includes @mwistrand 's code for handling the query and cacheBust options, as well as test cases for those changes, so it should resolve #34 and #49.

@bryanforbes bryanforbes assigned bryanforbes and unassigned maier49 Jul 20, 2015
query += query ? '&' + cacheBust : cacheBust;
}

const separator = url.indexOf('?') > -1 ? '&' : '?';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we're doing all of this logic here and on line 19 when we have it in UrlSearchParams?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the redundant logic at the beginning of the function, but I wasn't sure how line 19 could also be removed, since UrlSearchParams doesn't deal with the presence or absence of '?'.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, URLSearchParams will take a full URL and return a full URL. This is the wrong behavior according to the spec (which I just checked), so I thought we could use that to our advantage. Leave this line. Nice work on removing the redundant logic :).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aaaaaaaaaand ignore me on UrlSearchParams being wrong. I'm on a roll today.

* Used deepEqual instead of multiple assertions
* Removed redundant logic and delegated to UrlSearchParams
* Added timeout so that the second timestamp in cacheBust
  tests will alwasy be different from the first.
Changing more comparisons to use deepEqual.
@@ -1,3 +1,6 @@
/// <reference path="intern/intern.d.ts" />
/// <reference path="benchmark/benchmark.d.ts" />
/// <reference path="sinon/sinon.d.ts" />
/// <reference path="formidable/formidable.d.ts" />
/// <reference path="http-proxy/http-proxy.d.ts" />
/// <reference path="services/echo.d.ts" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we still doing typings in a tsd, or should they just be defined in the tsconfig.json?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, I removed the tsd file and everything is still working.

@@ -67,8 +69,15 @@ export default function xhr<T>(url: string, options: XhrRequestOptions = {}): Re

response.statusCode = request.status;
response.statusText = request.statusText;

resolve(response);
if (response.statusCode >= 200 && response.statusCode < 400) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be better as just response.statusCode < 400 since the 100 codes aren't errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ties into your comment on the 'timeout' test that's failing. When the request times out, prior to the ontimeout callback getting fired, this code gets fired with a status code of 0. I looked into it and apparently 0 is a valid value for XMLHttpRequest's statusCode property, indicating an error. I could change this to response.statusCode < 400 && response.statusCode !== 0, but I'm still not sure why this is getting called with a statusCode of 0, and how we want to handle that with regards to the 'timeout' test.

const dfd = this.async();
xhrRequest(getRequestUrl('foo.json'))
'default'() {
if (!echoServerAvailable) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test isn't using the echo server.

* Placed single callbacks on the same line as then.
* Made all tests in xhr.ts use the echo server.
* Used more appropriate propertyVal assertion.
* Called server.close in a callback function to preserve
  context.
* Added a leading slash to '/runner/end' in intern.ts
* Passed server to resolve in the callback for the listening
  event in echo.ts.
@maier49
Copy link
Contributor Author

maier49 commented Jul 27, 2015

With the exception of the issue regarding status codes and the timeout test I mentioned in a comment above, all the issues @jason0x43 commented on should be resolved now.

const parser = new formidable.IncomingForm();
parser.parse(request, function (err: any, fields: formidable.Fields, files: formidable.Files) {
if (err) {
reject(err);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should probably return, currently it will flow through

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a return after reject.

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

Successfully merging this pull request may close these issues.

6 participants