Library unit testing against SharePoint (can we create a web, list, etc) about pnp-js-core

[alex-randall]

While I love PowerShell, it only works with windows.
Wonder if there is a NPM only way to do this that would work on all platforms, not just ours...

I know the pnp library (or other supporting libraries) "might" solve this in the future (working from NPM directly to deploy thing directly to SharePoint sites through REST), but we need something "now".

Short term would be PowerShell
Longer term would be a gulp/NPM solution perhaps?
I know the https://www.npmjs.com/package/gulp-spsave gulp plugin you found is cool (the underlying https://www.npmjs.com/package/spsave module works with both O365 and on prem actually!).

I just did a search https://www.npmjs.com/search?q=sharepoint and found lots of NPM libraries that people have made that deal with SharePoint. Who knows the state of each of them, but very interesting and maybe worth investigating in the future...

Regarding the tests in the browser, (after deploying all assets) would be cool if they would just auto run on the default welcome page of the SharePoint site you are deploying the unit tests to. So, all you have to do is deploy there, and then open a browser, refresh and see the tests execute and see the results (if there's a visual test runner for mocha. I know qunit and jasmine have them).

[mike-morr]

@patrick-rodgers @alex-randall I had an idea for testing. A local node proxy listening on localhost:9010 that intercepts the request and passes this request on to a dev tenant just replacing "localhost:9010" with "devtenant.sharepoint.com" in the url and passing the rest of the url exactly as it came in.<-- that is my actual dev tenant btw. :)

Then intercept the results and serialize to disk, and then passes the results back to the caller. This would work equally well with error responses.

We would have a flag or env variable for sp_pnp_cachemode = true or whatever. Which if set, will deserialize the cached content and serve it immediately without making the request to sharepoint. So tests would need to be executed once without cached mode to build the cache, but after that it would just play back the same request every time like it was coming straight from SharePoint. Should be < 1ms response time in cached mode for tests. We could also introduce delays and handle error conditions the same way as normal rest requests.

We would also serialize a location to file mapping object that maps the url to a cache file.

[s-KaiNet]

Hi guys, just found out you are using my spsave module for build process :). Glad to know that. Recently I made an update to 2.x version (all are written in TypeScript from ground, with unit testing and integration testing, new options\features, more robust and stable version). I will make a PR to update dependency to 2.x version.
Regarding browser testing I have some thoughts. In the past I solved this problem by creating module gulp-jasmine-inject. The idea:
We run phantomjs from node, open sharepoint site with phantomjs, using phantomjs api (injectJs, etc.) we are injecting our custom scripts into the page, run jasmine tests, collect results. Take a look at this gulpfile (tests task):

gulp.task("tests", ["ts-tests"], function(){
    return gulp.src("tests/js/spec.js")
        .pipe($.jasmineInject({
            siteUrl: sett.siteUrl,
            username: sett.username,
            password: sett.password,
            phantomInitCallbacks: [path.resolve("./tests/lib/sharepoint.callback.js")],
            additionalJS: ["./tests/lib/jquery.js", 
                            "./tests/lib/camljs.js",
                            "./build/sp.list.repository.js",
                            "./tests/js/TestCategories.js",
                            "./tests/js/TestLib.js"],
            verbose: false
        }))
        .pipe(gulp.dest("tests/test_results"));
});

It tests sp.list.repository.js module in browser, by running site in phantomjs. It also includes additional .js files right into the page (jquery.js, camljs.js, etc.). This gulp-jasmine-inject is a bit old and I'm not sure if it's working right now, but we can try to implement similar approach.
For creating initial site (or any other tasks that can be done using REST API) we can use my another module sp-request (it's actually result of refactoring of spsave, I simply decided that it will be good to have a separate module to work with SharePoint REST from node with support for both on-prem and online). With sp-request it's possible to create a site and then upload some files with spsave, if required. And all cross-platform because of node.
Thoughts?

[patrick-rodgers]

Well, this is for us to use when testing the library, so I am OK with it being PowerShell. Another alternative would be to have a provider hosted application to do it via CSOM. Not something I am necessarily worried about being distributed (though folks would be welcome to use it) but more of a tool for us internally on the project.

[pbjorklund]

Like vcr.js?

[mike-morr]

yeah, exactly like that

Thanks a lot @pbjorklund !! You just crushed my dream for a multi-million dollar proxy startup I was about to start. :)

[biste5]

Instead of a PowerShell script, could be a console application that uses PnP Provisioning Engine or CSOM an alternative?
Some basic 'hello SP' test on Mac (with Mono and Xamarin Studio), using CSOM NuGet package are positive.

Same on Linux (Debian 8) isn't positive at the moment due to some missing implementation in Mono with SSL or WebClient to investigate further, but I don't think Linux is really interesting to support right now

[patrick-rodgers]

Sure, could be - there is also the PowerShell commands authored by Erwin that use the same provisioning engine. So there already exist the commends to apply templates and many other things. I'm open to any path that makes testing/debugging easier and allows us to add in-browser tests to run against SharePoint, that is the one area where we are really deficient.

[biste5]

yes, I know because I've used the PnP PowerShell command lets, but that would constraint anyway the usage to Windows machines only. Many frontend (JS / CSS) developers in my company are using non MS platform, and appreciating don't have to run VMs anymore now they can work with VSCode for instance

[patrick-rodgers]

Great point - perhaps we can package things in the form of a SharePoint add-in to run the tests?

Welcome @s-KaiNet! Sounds like a compelling idea, using phantomjs to run the tests sounds like a big step forward, think this should be explored in more details, wonder if it's a good idea to put together an example which simply connects to the top level site collection and queries the web for instance as a basic proof-of-concept.

In terms of creating the site & content, I imagine we'd want to use PnP-JS-Core itself, as the library itself is a wrapper for (and extends) the REST endpoints. Although that does create a testing paradox, using the library itself to test the library......

[s-KaiNet]

If you approve I will do a small POC with phantomjs (or casperjs).

[s-KaiNet]

For creating web using PnP JS - is it possible to use it from node?

[patrick-rodgers]

Thanks @s-KaiNet, definitely seems interesting. Currently we don't handle the authentication to full use the library from node - but has been discussed. Certainly something we can see about adding to the roadmap for the next release. Our focus was getting it working in the browser first.

I am not familiar with phantomjs, perhaps a small sample to show what it can do would be helpful? Or would it be better/smoother to decide if we want to support auth from node and run the tests directly? Open to any and all ideas on this topic!

[s-KaiNet]

To be clear on topic, what do you mean under browser testing? Is that integration testing (not unit), right?
In that case of course it will be much much simpler to run tests from node directly (especially if you have a plan to add support for node).

[patrick-rodgers]

Yes, the title of this could be better. What I mean really is "we need to test things against actual SharePoint". If we can do that from node, awesome. @mike-morrison may also be working on something along these lines as well.

[s-KaiNet]

I have an idea to use sp-request for testing on nodejs. The idea is to replace global.fetch(url, options) inside FetchClient.ts with sp-request, which has exactly the same syntax and in addition takes care about authentication.
will try to do a some kind of POC later this week or next week. If that work we may have consistent tests for both on-premise and online.

[patrick-rodgers]

I just submitted PR #152 which adds the ability to make requests from node -> SharePoint. This should enable us to begin writing tests for the library that execute calls against SP and validate the results.

[patrick-rodgers]

I'll take lists.ts and write the tests against SharePoint using the same pattern as in #156.

[patrick-rodgers]

I'm going to cover content types for tests.