A NodeJS project that tests the MUST requirements of the xAPI Spec and is based on the ADL testing requirements repository. The test suite website can be found here: https://lrstest.adlnet.gov/. The adopters website can be found here: https://adopters.adlnet.gov/
Home Page: https://adlnet.gov/projects/xapi/
License: MIT License
Expected response status code to be 400 got 401
Since there is no valid authentication header in this test, it seems like it should be OK to respond with either 401 or 400 -- it's a question of which requirements the LRS applies first, and I don't think we have anything which specifies that order.
Alternatively, you could just include the authentication header as a header, in which case it's fine to require the 400 response.
FAILED: will fail PUT with content body which is not url encoded
Error: Expected response status code to be 400 got 401
at (/Users/benclark/Projects/ripformance/test/v1_0_3/H.Communication1.3-AlternateRequestSyntax.js:137:14)
REQUEST SUPERREQUEST
_______________________________________
POST /ScormEngineInterface/TCAPI/default/statements?method=PUT HTTP/1.1
content-type: application/x-www-form-urlencoded
host: localhost
content-length: 467
Connection: close
{"statementId":"b0b99357-c906-40a2-8fcd-aabdf070b390","content":"{\"actor\":{\"objectType\":\"Agent\",\"name\":\"xAPI mbox\",\"mbox\":\"mailto:[email protected]\"},\"verb\":{\"id\":\"http://adlnet.gov/expapi/verbs/attended\",\"display\":{\"en-GB\":\"attended\",\"en-US\":\"attended\"}},\"object\":{\"objectType\":\"Activity\",\"id\":\"http://www.example.com/meetings/occurances/34534\"}}","X-Experience-API-Version":"1.0.3","Authorization":"Basic cm9vdDpzY29ybTIwMDQ="}
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 401 Unauthorized
date: Thu, 02 Feb 2017 21:05:20 GMT
server: Apache/2.4.18 (Unix)
x-experience-api-version: 0.9
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version
www-authenticate: Basic realm="SCORM Engine TCAPI"
content-length: 30
connection: close
Missing authentication header.
=======================================
The "nyan" reporter is fine when tests pass, but not particularly useful when they don't and gets messed up when you add logs to the tests. Mocha has the -R and --reporter options for this.
I've noticed that on some of the tests in the suite, requests sometimes come in at the same time that should be dependent on one another. In all cases, these appear to be based on tests with .wait(helper.genDelay(...) calls in them. To demonstrate, a normal request/response cycle looks like (the number after stderr is the request counter number, to indicate each request in the flow):
2016/12/12 06:10:02 stderr: 1 START POST /statements
2016/12/12 06:10:02 stderr: 1 COMPLETED status=200
2016/12/12 06:10:02 stderr: 2 START GET /statements?statementId=f7ffa34c-acdd-48c4-abd3-ca8b11fa0227
2016/12/12 06:10:02 stderr: 2 COMPLETED status=200
But for some tests, I get instead:
2016/12/12 06:10:02 stderr: 3 START POST /statements
2016/12/12 06:10:02 stderr: 4 START GET /statements?statementId=0de68aa5-560e-4ae8-80c1-0243973a3fc1
2016/12/12 06:10:02 stderr: 4 COMPLETED status=404
2016/12/12 06:10:02 stderr: 3 COMPLETED status=200
This of course 404s because the GET finishes before the POST has completed.
One such example is Data2.4.6-ContextProperty.js, both tests in this file are structured the same way, and we see this behavior on every instance of that test. If I comment out the .wait(...) and run the tests in there, the requests all run in order one after the other.
I'm running NodeJS 4.6.2 on OSX Sierra.
There should be a Statement with id=http://www.example.com/activityId/hashset already in the system before the HEAD/GET retrieves it.
The test:
should only return statements stored after designated "since" timestamp when using "since" parameter
Appears to ignore the X-Experience-API-Consistent-Through header.
Note that both of the responses have a X-Experience-API-Consistent-Through earlier than specified since (since=2017-01-31T22:13:06.508Z), the later response has : x-experience-api-consistent-through: 2017-01-31T22:13:03.055Z
That's over 3 seconds off, which makes me think that the "sync up the clocks" step is going wrong, rather than the LRS reporting a real 3+ second consistency delay. Regardless, the test shouldn't be able to say "success" or "fail" for this test, because the LRS hasn't caught up yet. It should fall back and wait longer.
Looking at this again, note:
date: Tue, 31 Jan 2017 22:13:03 GMT
So as far as the LRS is concerned, the test wants statements from the future. So, there are probably two issues here -- the clock sync phase may not be reliable, and the test needs to back off more to handle X-Experience-API-Consistent-Through. Though what's really odd, is I'm running the tests on the same VM as the LRS being tested, so the clock shouldn't have any difference at all.
I'll leave that stream of consciousness up there in case someone else can make something of it, but the main point is: this test shouldn't have been marked a failure, it should have backed off about 3.5 seconds and retried.
FAILED: should only return statements stored after designated "since" timestamp when using "since" parameter
AssertionError: expected [] to include '0988a37a-c9b9-4da0-af64-d49d6d79629e'
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/statements?verb=http://adlnet.gov/expapi/test/voided/target/26b64e5f-b4e5-4387-9cf8-5a960a86696e&since=2017-01-31T22:13:06.508Z HTTP/1.1
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Tue, 31 Jan 2017 22:13:03 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
x-experience-api-consistent-through: 2017-01-31T22:13:03.043Z
transfer-encoding: chunked
cache-control: private
content-type: application/json
connection: Close
{"statements":[],"more":""}
=======================================
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/statements?verb=http://adlnet.gov/expapi/test/voided/target/26b64e5f-b4e5-4387-9cf8-5a960a86696e&since=2017-01-31T22:13:06.508Z HTTP/1.1
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Tue, 31 Jan 2017 22:13:03 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
x-experience-api-consistent-through: 2017-01-31T22:13:03.055Z
transfer-encoding: chunked
cache-control: private
content-type: application/json
connection: Close
{"statements":[],"more":""}
=======================================
The test "should return 409 or 204 when statement ID already exists on PUT"
Does both a PUT and a POST. We respond 204 to the PUT, and then 200 to the POST, at which point we get the error: Error: Received status code: 200
However, I see nothing in the spec to indicate that 200 is wrong for POST (409 would presumably also be OK).
{
"name": "console",
"owner": null,
"flags": {
"endpoint": "http://localhost:64619/ScormEngineInterface/TCAPI/default",
"basicAuth": true,
"authUser": "scorm",
"grep": "should return 409 or 204 when statement ID already exists on PUT"
},
"options": {},
"rollupRule": "mustPassAll",
"uuid": "3c92bb86-8651-43ea-8cd6-2352a13bb723",
"startTime": 1485627716075,
"endTime": 1485627716325,
"duration": 250,
"state": "finished",
"summary": {
"total": 1,
"passed": 0,
"failed": 1,
"version": "1.0.3.7"
},
"log": {
"title": "",
"name": "",
"requirement": "",
"log": "REQUEST SUPERREQUEST\n_______________________________________\nPOST /ScormEngineInterface/TCAPI/default/statements HTTP/1.1\r\nX-Experience-API-Version: 1.0.3\r\nAuthorization: Basic c2Nvcm06c2Nvcm0yMDA0\r\nhost: localhost:64619\r\naccept: application/json\r\ncontent-type: application/json\r\ncontent-length: 324\r\nConnection: close\r\n\r\n{\"actor\":{\"objectType\":\"Agent\",\"name\":\"xAPI mbox\",\"mbox\":\"mailto:[email protected]\"},\"verb\":{\"id\":\"http://adlnet.gov/expapi/verbs/attended\",\"display\":{\"en-GB\":\"attended\",\"en-US\":\"attended\"}},\"object\":{\"objectType\":\"Activity\",\"id\":\"http://www.example.com/meetings/occurances/34534\"},\"id\":\"3b1b670b-f46a-402e-97bb-5a9550365038\"}\n\nRESPONSE SUPERREQUEST\n_______________________________________\nHTTP/1.1 200 OK\nserver: ASP.NET Development Server/11.0.0.0\ndate: Sat, 28 Jan 2017 18:21:56 GMT\nx-aspnet-version: 4.0.30319\nx-experience-api-version: 1.0.3\naccess-control-allow-origin: *\naccess-control-allow-methods: HEAD,GET,POST,PUT,DELETE\naccess-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through\naccess-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through\ntransfer-encoding: chunked\ncache-control: private\ncontent-type: application/json; charset=UTF-8\nconnection: Close\n\n3b1b670b-f46a-402e-97bb-5a9550365038\n=======================================\nREQUEST SUPERREQUEST\n_______________________________________\nGET /ScormEngineInterface/TCAPI/default/statements?statementId=3b1b670b-f46a-402e-97bb-5a9550365038 HTTP/1.1\r\nX-Experience-API-Version: 1.0.3\r\nAuthorization: Basic c2Nvcm06c2Nvcm0yMDA0\r\nhost: localhost:64619\r\nConnection: close\r\n\r\nRESPONSE SUPERREQUEST\n_______________________________________\nHTTP/1.1 200 OK\nserver: ASP.NET Development Server/11.0.0.0\ndate: Sat, 28 Jan 2017 18:21:56 GMT\nx-aspnet-version: 4.0.30319\nx-experience-api-version: 1.0.3\naccess-control-allow-origin: *\naccess-control-allow-methods: HEAD,GET,POST,PUT,DELETE\naccess-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through\naccess-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through\nx-experience-api-consistent-through: 2017-01-28T18:21:55.986Z\ntransfer-encoding: chunked\ncache-control: private\ncontent-type: application/json; charset=UTF-8\nconnection: Close\n\n{\"version\":\"1.0.0\",\"id\":\"3b1b670b-f46a-402e-97bb-5a9550365038\",\"actor\":{\"objectType\":\"Agent\",\"name\":\"xAPI mbox\",\"mbox\":\"mailto:[email protected]\"},\"verb\":{\"id\":\"http://adlnet.gov/expapi/verbs/attended\",\"display\":{\"en-GB\":\"attended\",\"en-US\":\"attended\"}},\"object\":{\"objectType\":\"Activity\",\"id\":\"http://www.example.com/meetings/occurances/34534\"},\"timestamp\":\"2017-01-28T18:21:56.123Z\",\"stored\":\"2017-01-28T18:21:56.123Z\",\"authority\":{\"objectType\":\"Agent\",\"account\":{\"homePage\":\"http://example.org/bsc/\",\"name\":\"scorm\"}}}\n=======================================\n",
"status": "failed",
"tests": [
{
"title": "Statement Resource Requirements (Communication 2.1)",
"name": "Statement Resource Requirements",
"requirement": [
"Communication.md#2.1"
],
"log": "",
"status": "failed",
"tests": [
{
"title": "An LRS's Statement Resource rejects with error code 409 Conflict any Statement with the \"statementID\" parameter equal to a Statement in the LRS already **Implicit** (Communication 2.1.1.s2.b2)",
"name": "An LRS's Statement Resource rejects with error code 409 Conflict any Statement with the \"statementID\" parameter equal to a Statement in the LRS already **Implicit**",
"requirement": [
"Communication.md#2.1.1.s2.b2"
],
"log": "",
"status": "failed",
"tests": [
{
"title": "should return 409 or 204 when statement ID already exists on PUT",
"name": "should return 409 or 204 when statement ID already exists on PUT",
"requirement": "",
"log": "REQUEST SUPERREQUEST\n_______________________________________\nPUT /ScormEngineInterface/TCAPI/default/statements?statementId=76a7f886-4e97-4163-a47c-00b265a65d0f HTTP/1.1\r\nX-Experience-API-Version: 1.0.3\r\nAuthorization: Basic c2Nvcm06c2Nvcm0yMDA0\r\nhost: localhost:64619\r\naccept: application/json\r\ncontent-type: application/json\r\ncontent-length: 324\r\nConnection: close\r\n\r\n{\"actor\":{\"objectType\":\"Agent\",\"name\":\"xAPI mbox\",\"mbox\":\"mailto:[email protected]\"},\"verb\":{\"id\":\"http://adlnet.gov/expapi/verbs/attended\",\"display\":{\"en-GB\":\"attended\",\"en-US\":\"attended\"}},\"object\":{\"objectType\":\"Activity\",\"id\":\"http://www.example.com/meetings/occurances/34534\"},\"id\":\"76a7f886-4e97-4163-a47c-00b265a65d0f\"}\n\nRESPONSE SUPERREQUEST\n_______________________________________\nHTTP/1.1 204 No Content\nserver: ASP.NET Development Server/11.0.0.0\ndate: Sat, 28 Jan 2017 18:21:56 GMT\nx-aspnet-version: 4.0.30319\nx-experience-api-version: 1.0.3\naccess-control-allow-origin: *\naccess-control-allow-methods: HEAD,GET,POST,PUT,DELETE\naccess-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through\naccess-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through\ncache-control: private\nconnection: Close\n\nundefined\n=======================================\nREQUEST SUPERREQUEST\n_______________________________________\nPOST /ScormEngineInterface/TCAPI/default/statements HTTP/1.1\r\nX-Experience-API-Version: 1.0.3\r\nAuthorization: Basic c2Nvcm06c2Nvcm0yMDA0\r\nhost: localhost:64619\r\naccept: application/json\r\ncontent-type: application/json\r\ncontent-length: 324\r\nConnection: close\r\n\r\n{\"actor\":{\"objectType\":\"Agent\",\"name\":\"xAPI mbox\",\"mbox\":\"mailto:[email protected]\"},\"verb\":{\"id\":\"http://adlnet.gov/expapi/verbs/attended\",\"display\":{\"en-GB\":\"attended\",\"en-US\":\"attended\"}},\"object\":{\"objectType\":\"Activity\",\"id\":\"http://www.example.com/meetings/occurances/34534\"},\"id\":\"76a7f886-4e97-4163-a47c-00b265a65d0f\"}\n\nRESPONSE SUPERREQUEST\n_______________________________________\nHTTP/1.1 200 OK\nserver: ASP.NET Development Server/11.0.0.0\ndate: Sat, 28 Jan 2017 18:21:56 GMT\nx-aspnet-version: 4.0.30319\nx-experience-api-version: 1.0.3\naccess-control-allow-origin: *\naccess-control-allow-methods: HEAD,GET,POST,PUT,DELETE\naccess-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through\naccess-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through\ntransfer-encoding: chunked\ncache-control: private\ncontent-type: application/json; charset=UTF-8\nconnection: Close\n\n76a7f886-4e97-4163-a47c-00b265a65d0f\n=======================================\n",
"status": "failed",
"error": "Error: Received status code: 200",
"tests": []
}
]
}
]
}
]
}
}
LRSs are allowed to fall back to version 0.9, but the three using Activities .* Endpoint tests are not sending the 1.x version header, and then rejecting valid 0.9 behavior:
For example, here is "using Activities Endpoint"
{
"title": "using Activities Endpoint",
"name": "using Activities Endpoint",
"requirement": "",
"log": "REQUEST SUPERREQUEST\n_______________________________________\nGET /ScormEngineInterface/TCAPI/default/activities HTTP/1.1\r\nAuthorization: Basic c2Nvcm06c2Nvcm0yMDA0\r\nhost: localhost:64619\r\nConnection: close\r\n\r\nRESPONSE SUPERREQUEST\n_______________________________________\nHTTP/1.1 400 Bad Request\nserver: ASP.NET Development Server/11.0.0.0\ndate: Fri, 27 Jan 2017 22:18:26 GMT\nx-aspnet-version: 4.0.30319\nx-experience-api-version: 0.9\naccess-control-allow-origin: *\naccess-control-allow-methods: HEAD,GET,POST,PUT,DELETE\naccess-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version\naccess-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version\ncache-control: private\ncontent-type: text/html\nconnection: Close\n\nMissing required argument: activityId\n=======================================\n",
"status": "failed",
"error": "AssertionError: expected '0.9' to match /^1\\.0\\.\\d+$/",
"tests": []
}
And cleaned up a bit:
FAILED: using Activities Endpoint
AssertionError: expected '0.9' to match /^1\.0\.\d+$/
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/activities HTTP/1.1
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 400 Bad Request
server: ASP.NET Development Server/11.0.0.0
date: Fri, 27 Jan 2017 21:25:36 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 0.9
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version
cache-control: private
content-type: text/html
connection: Close
Missing required argument: activityId
sha2 value isn't in the X-Experience-Hash header and needs to match the sha2 property - it is very possible I didn't have a requirement around this one.
I see that there was an npm module registered for these tests, but it's out of date: https://www.npmjs.com/package/lrs-conformance-tests
I'd like to integrate the tests into our automated test process, and it would be preferable to just pull the module down from the npm repo (as we do with other tools for our tests) than to pull it down from github.
Setup tests that use environment file to add basic authentication headers to requests.
"If the existing document does not have a Content-Type of application/json but the document being posted to the State Resource does the LRS MUST respond with HTTP status code 400 Bad Request, and MUST NOT update the target document as a result of the request."
Error: Expected response status code to be 204 got 400
Is it possible to add parameters to command line utility that point to a specific test?
In H.Communication2.1-StatementResource.js, there is a test for: A GET request is defined as either a GET request or a POST request containing a GET request (Communication 2.1.2.s2.b3)
This test sends a POST to do a GET operation, but does not follow the Alternate Request Syntax rules about the method parameter. Per the spec: The intended xAPI method MUST be included as the value of themethodquery string parameter.
I've read through Communication 2.1.2, and don't see anything that invalidates this rule otherwise. Is there another part of the spec that allows this POST to surrogate as a GET without the method parameter? Otherwise, I think this particular test is broken. I'm happy to submit a pull request if someone can confirm there's an issue with this behavior.
It looks like the test is sending matching_no_target.json ( which is a matching activity that (incorrectly) does not include a target) in a statement and expects the LRS to respond with 200
statement activity "source" uses matching is an array of interaction components
Expected response status code to be 200 got 400
Since:
An LRS, upon consuming a valid interactionType, MAY validate the remaining properties as specified for Interaction Activities and MAY return 400 Bad Request if the remaining properties are not valid for the Interaction Activity.
The test needs to allow either 200 or 400 when sending statements that include a valid interactionType, but do not strictly adhere to the remaining documentation for that interactionType. Alternatively, the test could avoid sending such statements.
Note: the details for each interactionType are a little under-specified, which should give LRSs room to validate strictly or not if desired, based on the MAY above, and deference should be given to LRSs validating to ensure the interactions "make sense". So in this example, "target" is in a table listing "supported properties", it's not clear that "target" is required, but it's also not listed as optional. And the interaction activity doesn't make sense without it.
It seems that an LRS may be able to reject a voiding Statement because it doesn't have a Statement Id in the system. The tests following that may have to adjust. In other words, this test is only a SHOULD (or SHOULD NOT reject, if you will), even for 1.0.3.
In test/v1_0_3/configs/durations.js, the following test exists:
{
name: 'statement result "duration" property is valid with "P4W1D"',
templates: [
{statement: '{{statements.result}}'},
{result: '{{results.default}}'},
{duration: 'P4W1D'}
],
expect: [400]
}
However, my reading of ISO8601 4.4.3.2 says that this isn't a valid duration. Taken from here: http://www.uai.cl/images/sitio/biblioteca/citas/ISO_8601_2004en.pdf
In both basic and extended format the complete representation of the expression for duration shall be [PnnW] or [PnnYnnMnnDTnnHnnMnnS].
From that reading, P4W1D isn't valid. Later parts of 4.4 offer a similar view of the "week" parameter being a standalone option. Given that, I would say that this test should be removed from the suite. I can provide a pull request if I've interpreted the standard correctly.
Through some holes in testing (again, may be related to the requirements document), authority is allowed to be a normal group, but it MUST be an agent or an OAuth group
The test which tests for
A "contextActivities" property contains one or more key/value pairs
lists the rationale of:Data.md#2.4.6.2.s4.b2
but that appears to be:
Every value in the contextActivities Object MUST be either a single Activity Object or an array of Activity Objects.
Which is a requirement about the values that do exist, but does not appear to indicate that values in fact must exist.
At minimum it seems the rationale for the test needs to be updated.
Ex, A Statement uses the "authority" property at most one time (Multiplicity, 4.1.a)
The javascript JSON parser does not throw any exceptions when parsing strings with multiple values for the same key. The last value for that key is the value that is saved.
The test:
An LRS's About Resource's version property contains at least one string of "1.0.0" (Communication 2.8.s5.b1.b1, XAPI-00317)
Expects the about resource to include 1.0.0, but it should expect 1.0.3
This is based on the requirements:
An LRS MUST return the JSON document described above, with a "version" property that includes the latest minor and patch version the LRS conforms to, for each major version.
This is a bit of a confusing requirement, but note that it says: "For version 1.0.0 of this specification, this means that 1.0.0 MUST be included". Some important things to consider about this statement:
found on: 653096a
Should reject DELETE with "agent" with type not JSON
2 tests are:
var invalidTypes = [1, true, 'not JSON', undefined];
invalidTypes.forEach(function (type) {
it('Should reject DELETE with "agent" with type ' + type, function () {
var parameters = helper.buildState();
parameters.activityId = type; // this must be agent
return helper.sendRequest('delete', helper.getEndpointActivitiesState(), parameters, undefined, 400);
});
});The test here:
https://github.com/adlnet/lrs-conformance-test-suite/blob/master/test/v1_0_3/H.Communication3.1-Concurrency.js#L154
(When responding to a PUT request, handle the If-None-Match header as described in RFC 2616, HTTP/1.1 if it contains an tag)
is not testing anything in the spec, as far as i can tell.
The relevant part of the spec (https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Communication.md#31-concurrency) only claims An LRS responding to a PUT request MUST handle the "If-None-Match" header as described in RFC2616, HTTP 1.1 if it contains "*", in order to to detect when there is a resource present that the Client is not aware of..
This scenario is tested by the test directly below the one linked.
Maybe there was confusion with the requirement for If-Match which states An LRS responding to a PUT request MUST handle the "If-Match" header as described in RFC2616, HTTP 1.1 if it contains an ETag, in order to detect modifications made after the Client last fetched the document..
This scenario is tested by the test directly above the one linked.
The test:
should process using GET with "attachments"
Seems to be complaining because it's expecting an array of statements back, but we're using the single statement syntax (as is generally allowed when statementId is specified). We do talk about statement batches a bit in the attachment language, so I can see some implication that what comes back would be a "batch", presumably an array, but I haven't been able to find the specific requirement I can point to and say the single-statement syntax is wrong.
So I'm putting this out there to see if we should change the test or someone can clear up the requirement.
AssertionError: expected { Object (version, attachments, ...) } to have a property 'statements'
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/statements?statementId=4732882c-bca8-418c-8611-042671e3fefa HTTP/1.1
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Mon, 06 Feb 2017 21:59:44 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
x-experience-api-consistent-through: 2017-02-06T21:59:44.249Z
transfer-encoding: chunked
cache-control: private
content-type: application/json; charset=UTF-8
connection: Close
{"version":"1.0.0","attachments":[{"usageType":"http://example.com/attachment-usage/test","display":{"en-US":"A test attachment"},"description":{"en-US":"A test attachment (description)"},"contentType":"text/plain","length":27,"sha2":"495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a"},{"usageType":"http://example.com/attachment-usage/test","display":{"en-US":"A test attachment"},"description":{"en-US":"A test attachment (description)"},"contentType":"text/plain","length":33,"sha2":"7063d0a4cfa93373753ad2f5a6ffcf684559fb1df3c2f0473a14ece7d4edb06a"}],"id":"4732882c-bca8-418c-8611-042671e3fefa","actor":{"objectType":"Agent","name":"Sample Agent","mbox":"mailto:[email protected]"},"verb":{"id":"http://adlnet.gov/expapi/verbs/answered","display":{"en-US":"answered"}},"object":{"objectType":"Activity","id":"http://www.example.com/tincan/activities/multipart","definition":{"name":{"en-US":"Multi Part Activity"},"description":{"en-US":"Multi Part Activity Description"}}},"timestamp":"2014-07-11T13:51:03.971Z","stored":"2017-02-06T21:59:44.417Z","authority":{"objectType":"Agent","account":{"homePage":"http://example.org/bsc/","name":"scorm"}}}
=======================================
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/statements?attachments=true&statementId=4732882c-bca8-418c-8611-042671e3fefa HTTP/1.1
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Mon, 06 Feb 2017 21:59:44 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
x-experience-api-consistent-through: 2017-02-06T21:59:44.259Z
cache-control: private
content-type: multipart/mixed; boundary=c04a7aacb02d46149b8d490695e5b1ee
content-length: 1792
connection: Close
--c04a7aacb02d46149b8d490695e5b1ee
Content-Type:application/json; charset=UTF-8
Content-Length:1175
{"version":"1.0.0","attachments":[{"usageType":"http://example.com/attachment-usage/test","display":{"en-US":"A test attachment"},"description":{"en-US":"A test attachment (description)"},"contentType":"text/plain","length":27,"sha2":"495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a"},{"usageType":"http://example.com/attachment-usage/test","display":{"en-US":"A test attachment"},"description":{"en-US":"A test attachment (description)"},"contentType":"text/plain","length":33,"sha2":"7063d0a4cfa93373753ad2f5a6ffcf684559fb1df3c2f0473a14ece7d4edb06a"}],"id":"4732882c-bca8-418c-8611-042671e3fefa","actor":{"objectType":"Agent","name":"Sample Agent","mbox":"mailto:[email protected]"},"verb":{"id":"http://adlnet.gov/expapi/verbs/answered","display":{"en-US":"answered"}},"object":{"objectType":"Activity","id":"http://www.example.com/tincan/activities/multipart","definition":{"name":{"en-US":"Multi Part Activity"},"description":{"en-US":"Multi Part Activity Description"}}},"timestamp":"2014-07-11T13:51:03.971Z","stored":"2017-02-06T21:59:44.417Z","authority":{"objectType":"Agent","account":{"homePage":"http://example.org/bsc/","name":"scorm"}}}
--c04a7aacb02d46149b8d490695e5b1ee
Content-Type:text/plain
Content-Length:27
X-Experience-API-Hash:495395e777cd98da653df9615d09c0fd6bb2f8d4788394cd53c56a3bfdcd848a
Content-Transfer-Encoding:binary
here is a simple attachment
--c04a7aacb02d46149b8d490695e5b1ee
Content-Type:text/plain
Content-Length:33
X-Experience-API-Hash:7063d0a4cfa93373753ad2f5a6ffcf684559fb1df3c2f0473a14ece7d4edb06a
Content-Transfer-Encoding:binary
here is another simple attachment
--c04a7aacb02d46149b8d490695e5b1ee--
=======================================
Passes activityId instead of agent
The test:
rejects a signed statement with a malformed signature - bad usage type
Appears to expect the LRS to detect that this is a signature, and reject it as a malformed signature due to a bad "usage type". However, because this is not using the signature usage type it's perfectly valid (and I'd say probably better) behavior for the LRS to simply treat this as a valid, non-signature attachment.
found on: 653096a
Error: Expected response status code to be 400 got 200
REQUEST SUPERREQUEST
_______________________________________
POST /ScormEngineInterface/TCAPI/default/statements HTTP/1.1
Content-Type: multipart/mixed; boundary=-------------902419285
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
content-length: 1695
Connection: close
---------------902419285
Content-Type:application/json
{"actor":{"objectType":"Agent","name":"xAPI mbox","mbox":"mailto:[email protected]"},"verb":{"id":"http://adlnet.gov/expapi/verbs/attended","display":{"en-GB":"attended","en-US":"attended"}},"object":{"objectType":"Activity","id":"http://www.example.com/meetings/occurances/34534"},"id":"1b6090b7-29fb-414d-84c7-a01e14cfe018","attachments":[{"usageType":"http://adlnet.gov/expapi/attachments","display":{"en-US":"Signed by the Test Suite"},"description":{"en-US":"Signed by the Test Suite"},"contentType":"application/octet-stream","length":796,"sha2":"00a8d279c2ecc1dbbbb02d3ab2b30c1ed709daa4381a9297f93c454ebb8873ae"}]}
---------------902419285
Content-Type:application/octet-stream
Content-Transfer-Encoding:binary
X-Experience-API-Hash:00a8d279c2ecc1dbbbb02d3ab2b30c1ed709daa4381a9297f93c454ebb8873ae
eyJhbGciOiJSUzI1NiJ9.eyJhY3RvciI6eyJvYmplY3RUeXBlIjoiQWdlbnQiLCJuYW1lIjoieEFQSSBtYm94IiwibWJveCI6Im1haWx0bzp4YXBpQGFkbG5ldC5nb3YifSwidmVyYiI6eyJpZCI6Imh0dHA6Ly9hZGxuZXQuZ292L2V4cGFwaS92ZXJicy9hdHRlbmRlZCIsImRpc3BsYXkiOnsiZW4tR0IiOiJhdHRlbmRlZCIsImVuLVVTIjoiYXR0ZW5kZWQifX0sIm9iamVjdCI6eyJvYmplY3RUeXBlIjoiQWN0aXZpdHkiLCJpZCI6Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20vbWVldGluZ3Mvb2NjdXJhbmNlcy8zNDUzNCJ9LCJpZCI6IjFiNjA5MGI3LTI5ZmItNDE0ZC04NGM3LWEwMWUxNGNmZTAxOCJ9.cJPTQIe3Ia3p4Bv1129T-ahBDBd_wJKJpNHtU8yj5daZkSZ87W1w3PyBorB-DYFF9_rzkZpOrVtpCEuTXYUiawV-lWw04IzUnrRVTu2XeBpyG-DGy0F1Adfrxy2eqG3szq1uMX5qNzhpD_d5slz1cC_naNS9N43M_1W5NVr2n5pFcw66fSuLA-1NdbwjBuxMg99fPKIFvTxyvPtzP8m8HJfi5E9X13n-nPlocoSQfewdd5aJMtxsyCRS0VZcFVY6sjfwDBA_Pf8JR_ngOVScdXFrw7jifp-H8Zzzf25LhDB-muMPsIbhueqvweyCT0x6MfL3ZSZ8um_WWsARnwYGiQ
---------------902419285--
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Mon, 06 Feb 2017 22:11:27 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
transfer-encoding: chunked
cache-control: private
content-type: application/json; charset=UTF-8
connection: Close
["1b6090b7-29fb-414d-84c7-a01e14cfe018"]
There are several instances where the tests are performing a GET /statements with query parameters but the only check run is that the response is a 200 OK and that the results have the structure: {statements: [...]} .
This type of check is not validating that the LRS is actually returning what the request is expecting to receive. The same response could be sent back for each of these queries and these tests would not catch the flaw in the LRS.
Here are the tests:
Query for Agent -- should check that the agent requested appears in each of the statements in the response
Query for Verb -- should check that no statements in the response contain a verb other than the requested verb
Query for Activity -- should check that all statements in the response contain an object.id which matches the requested activityId
Query for Registration -- should check that all statements in the response contain object.id to the requested activityId
Query for Related Activities -- should check that all statements in the response contain the the requested activityId in at least one of the: "object, any of the context Activities, or any of those properties in a contained SubStatement" (from here)
Query for Related Agents -- should check that all statements in the response contain the the requested agent in at least one of the: "Actor, Object, Authority, Instructor, Team, or any of these properties in a contained SubStatement" (from here)
Query for Since -- should check that all statements in the response contain timestamps more recent than the requested time
Query for Until -- should check that all statements in the response contain timestamps prior to the requested time
Query for Limit -- should check the appropriate number of statements were sent in the response
Query for Ascending -- should check that all statements in the response are ordered according to their stored times
Query for Format -- should check that all statements in the response are formatted according to the spec's formatting rules. Could also check that a single statement's structure is different when requested using format ids vs canonical vs exact.
the test:
//Type "String" tests likely to be reworded or removed
describe('An LRS\'s Activity Profile Resource rejects a GET request without "profileId" as a parameter if it is not type "String" with error code 400 Bad Request (format, Communication 2.7.s3.table1.row2)', function () {
var document = helper.buildDocument(),
invalidTypes = [1, true, { key: 'value'}];
invalidTypes.forEach(function (type) {
it('Should reject GET with "profileId" with type ' + type, function () {
var parameters = helper.buildActivityProfile();
parameters.agent = type;
return helper.sendRequest('get', helper.getEndpointActivitiesProfile(), parameters, document, 400);
});
});
});set agent instead profileId.
Thanks!!!
Test asserts on body content being a specific error message, but spec only says return 400 status.
Mocha provides the -b and --bail options so I think you could also provide them. I want this because I'm only interested in the first exception when I'm trying to fix issues.
Hi, first I want to say that this is an excellent designed suite.
On first run the app exits Error: Cannot find module 'colors', thrown by bin/console_runner.js:5:14
This can be easy worked around by running npm install colors --save however it would be great to include it into the repo package.json
It looks to me like the test is doing a case sensitive check for the header "X-Experience-API-Consistent-Through", but the tests are also converting all the headers to lower case so the header is not found.
The LRS is actually sending the header with the proper case (confirmed with curl), but it's showing up in the log here as lower case. Since HTTP headers are case insensitive, I suspect the tests are forcing them to lowercase for comparison in general, but lowercasing the string being checked for was missed on this particular test.
FAILED: should return "X-Experience-API-Consistent-Through" when using GET for statements
AssertionError: expected false to be true
REQUEST SUPERREQUEST
_______________________________________
GET /ScormEngineInterface/TCAPI/default/statements HTTP/1.1
X-Experience-API-Version: 1.0.3
Authorization: Basic c2Nvcm06c2Nvcm0yMDA0
host: localhost:64619
Connection: close
RESPONSE SUPERREQUEST
_______________________________________
HTTP/1.1 200 OK
server: ASP.NET Development Server/11.0.0.0
date: Sun, 29 Jan 2017 14:59:23 GMT
x-aspnet-version: 4.0.30319
x-experience-api-version: 1.0.3
access-control-allow-origin: *
access-control-allow-methods: HEAD,GET,POST,PUT,DELETE
access-control-allow-headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,X-Experience-API-Version,X-Experience-API-Consistent-Through
access-control-expose-headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate,X-Experience-API-Version,X-Experience-API-Consistent-Through
x-experience-api-consistent-through: 2017-01-29T14:59:22.778Z
transfer-encoding: chunked
cache-control: private
content-type: application/json
connection: Close
There is a section of tests based on:
A Language Map is defined as an array of language tag/String pairs has at least 1 entry
However, there is no requirement listed with this assertion, nor could I find justification in the spec for the "at least 1 entry" assertion.
I think suggest we either drop these tests or provide a reference to why {} is not a valid language map.
Version
Master branch at a7859c5
Steps to reproduce
console.log(reqUrl); after line 27 in "test/v1_0_2/templates/document.js".lrs-test with the following -g 'Document API Requirements An LRS has an Agents API with endpoint "base IRI" + /agents" (7.6) **Implicit** (in that it is not named this by the spec)'Expected behaviour
Step 2 should log the snippet below because it correctly provides the agent and profileId parameters with their values URL encoded.
/agents?agent=%7b%22objectType%22%3a%22Agent%22%2c%22account%22%3a%7b%22homePage%22%3a%22http%3a%2f%2fwww.example.com%2fagentId%2f1%22%2c%22name%22%3a%22Rick+James%22%7d%7d&profileId=602022bc-11df-4eef-9604-dcdf0141704d
Actual behaviour
Step 2 actually logs the snippet below. Note firstly, that an = should follow ?agent but doesn't. Secondly the agent parameter value is incorrectly encoded (see additional information).
/agents?agent%5BobjectType%5D=Agent&agent%5Baccount%5D%5BhomePage%5D=http%3A%2F%2Fwww.example.com%2FagentId%2F1&agent%5Baccount%5D%5Bname%5D=Rick%20James&profileId=602022bc-11df-4eef-9604-dcdf0141704d
Additional information
If you URL decode everything after the "?" in the actual behaviour snippet you get the snippet below.
agent[objectType]=Agent&agent[account][homePage]=http://www.example.com/agentId/1&agent[account][name]=Rick James&profileId=602022bc-11df-4eef-9604-dcdf0141704d
It should be possible to specify a particular test to run. This makes it practical to attach a debugger to the LRS and watch how it handles a particular test, which is completely impractical for the entire suite or a directory.
Version
master branch at cde7dce
Steps to reproduce
git clone https://github.com/TryxAPI/lrs-conformance-tests.git lrs-conformance-tests.cd lrs-conformance-tests.npm install.npm link.authUser, authPass, basicAuth, and endpoint.Expected behaviour
Step 5 should run the tests successfully.
Actual behaaviour
Step 5 actually displays an error (see below).
module.js:340
throw err;
^
Error: Cannot find module 'valid-url'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object.<anonymous> (c:\Program Files (x86)\Ampps\www\ll\tests2\test\v1_0_2\non_templating.js:3732:156)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
Additional information
Required by test/v1_0_2/non_templating.js:3732:156
The following test:
should NOT return the attachment if "attachments" is missing
Expects a content-type header of:
application/json
and therefore rejects:
application/json; charset=utf-8
The spec is clear that the content-type MUST be application/json, however the content-type header in HTTP is defined as including both the content-type (before the ;) and parameters (after the ;), so the test should probably just check that the content-type header either is application/json or starts with application/json;
abc://should.fail.com is supposed to fail Statement validation according to the test. However, this is a valid IRI via https://www.ietf.org/rfc/rfc2396.txt (Appendix B)
In a variety of tests, the parameters are coming back with:
{'agent[account][homePage]':'http://www.example.com/agentId/1','agent[objectType]': 'Agent', 'profileId': '6712492e-7802-485c-a839-9a10dbad670e', 'agent[account][name]': 'Rick James'}
The variable types seem to actually be in the parameters and shouldn't be. This is not specific to HEAD requests.
Referencing an expect on a test here, I believe this test may be better suited to use a regular expression to match the content-type header, maybe something along the lines of:
expect(res.headers["content-type"]).to.match(/application\/json/)
I know of a few frameworks that will automatically format application/json responses as application/json; charset=utf-8. I think it would still be in spec to do something similar to the above, as well as help accommodate a few different frameworks.
Test queries for a custom verb and expects the voiding statement to come back, but the voiding statement uses a voiding verb, so it should not actually be returned.
Test adjusts "until" time with helper.getTimeMargin(), but this still leaves room for minor variations in latency, causing test to be flakey.
It appears that the series of tests:
Should reject DELETE with "activityId" with type ...
Expect the LRS to reject a profileId that could be parsed as something other than a string. Eg: 1, or true.
That doesn't make sense because even though it's true we expect and require a string there, due to the nature of the query string it's not possible to pass something that's not a string. So even though 1 can be parsed as an integer, the LRS reasonably interprets it as the string "1".
From "Interaction Activities" in xAPI-Data:
An LRS, upon consuming a valid interactionType, MAY validate the remaining properties as specified for Interaction Activities and MAY return 400 Bad Request if the remaining properties are not valid for the Interaction Activity.
This is a more specific requirement than the formatting requirements in section 2.2 which indicate that an LRS MUST reject statements where .... https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#lrs-requirements
Since the MAY requirement is more specific (limited to interaction activities), and because is has no meaning if it doesn't take precedence, it should be read as taking precedence over the general MUST reject statements in 2.2
Therefore, tests relating to interactiontype (eg: "when interactionType is something then _something") and relying on Data#2.2.x as rationale should either only be run when requested, or should be noted as some sort of warning only, not failures.
In a test here. A request is made to store a statement, then get information about the activity stored with that statement via the activities resource.
Looking at the documentation for the activities resource, there is no specification that activity details from posted statements should be available through the route.
I could be missing the link between these two resources in the documentation, or it could be missing itself. Also, option 3, I could be completely misinterpreting the test. Could anyone shed some light on this for me?
The test:
"An Activity Definition contains at least one of the following properties: name, description, type, moreInfo, interactionType, or extensions"
"statement activity "definition" missing all properties"
"statement substatement activity "definition" missing all properties"
{ ... "definition":{}}
"Error: Expected response status code to be 200 got 400
The state code of the response must be 400
Per my reading of the 1.0.3 standard, "stored" is documented as:
The "stored" property MUST be set by the LRS; An LRS SHOULD validate and then MUST overwrite any value currently in the "stored" property of a Statement it receives.
However, there are several tests in test/v1_0_3/configs/timestamps.js of the form:
{
name: 'statement "template" invalid string in stored',
templates: [
{statement: '{{statements.default}}'},
{stored: INVALID_STRING}
],
expect: [400]
},
This test suite only tests MUST behavior, not SHOULD behavior, correct? If so, this test and a few others in this same block should be removed, and the rule above is only for the LRS should validate, not must validate.
I'm happy to provide a pull request if I've interpreted the standard correctly.
See this issue for context.
I wonder if it's worth including a link at the top of the readme to https://github.com/adlnet/xAPI_LRS_Test so that users of this test suite know to use that one too?
The spec requires the more link to be a relative URL, however this test suite requires an absolute URL.
See the comments on this issue: RusticiSoftware/TinCanStatementViewer#16 (comment)
After doing an npm install got the below error trying to run the test suite:
module.js:327
throw err;
^
Error: Cannot find module 'express'
- module.js:325 Function.Module._resolveFilename
module.js:325:15
- module.js:276 Function.Module._load
module.js:276:25
- module.js:353 Module.require
module.js:353:17
- module.js:12 require
internal/module.js:12:17
- OAuth.js:3 Object.<anonymous>
/Users/sam.cayford/GitHub/lrs-conformance-test-suite/bin/OAuth.js:3:15
- module.js:409 Module._compile
module.js:409:26
- module.js:416 Object.Module._extensions..js
module.js:416:10
- module.js:343 Module.load
module.js:343:32
- module.js:300 Function.Module._load
module.js:300:12
- module.js:353 Module.require
module.js:353:17
I had to do a subsequent npm install express to get them to work.
npm --version
3.10.3
node --version
v4.4.4
OSX 10.11.5
MIME RFC says line endings should be CRLF, but the samples don't appear to be using CRLF, maybe an issue with git line normalization since the escaping isn't being explicitly disabled via .gitattributes.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.