- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Fri, 6 Sep 2013 14:58:04 +0200
- To: <public-linked-json@w3.org>
On Thursday, September 05, 2013 4:48 PM, Dave Longley wrote: > > I think the whole purpose of these tests is to test that an > > implementation is capable of making real network requests. > > I think it's perfectly fine for there to be an abstraction layer between > the network and what remote documents are returned. I don't think we're > trying to test the network stack here, rather we're trying to ensure Well not the network stack per se but the whole end-to-end scenario. Most algorithmic tests could be described as unit tests whereas these here are really functional tests or even integration tests IMO. It's similar to testing a browser. You can test it's rendering engine but you certainly also wanna be sure that it can issue the right network requests to fetch data from a remote server. > that remote documents that are loaded with particular parameters produce > appropriate output. Think of it as if a different "HTTP adapter" is used > for testing. The test is not for the adapter, it's for what it returns. Right, we are not testing the adapter in isolation but the whole system including the adapter. Every conformant JSON-LD processor must include an adapter that is able to make real network requests in order to be called conformant. Of course there may be some restrictions (CORS) but at least under optimal conditions it must work. > > As such, I think mocking them > > wouldn't be a good idea. In practice, you probably run the code in an > > environment where it doesn't have network access, but nevertheless it MUST > > be able to perform those requests. > > I don't think that we should say that a processor with no access to > json-ld.org is incapable of being considered compliant. It certainly > wouldn't be able to prove its compliance if such access were required. > The processor might do everything just fine w/respect to loading remote > documents, but be unable to access *particular* remote documents. Well, we could also test against localhost if you prefer but that doesn't mean that it should be allowed to replace the complete HTTP stack with a simple mock for these tests. This test validate a very important aspect of the functionality of a JSON-LD processor and thus we need to test the HTTP stack as well IMO. -- Markus Lanthaler @markuslanthaler
Received on Friday, 6 September 2013 12:58:39 UTC